XBee control inputs, replace PPM/PWM inputs

[Chris]

In order to get real time telemetry from Gluonpilot, you need a wireless serial link, which for most people will be an XBee radio link. Since this link is 2-way, I would like to use it for pilot control inputs as well and eliminate the RC receiver.

In order to do this I plan to:
1) Use a USB transmitter (like used in RC flight simulators http://www.hobbypartz.com/60p-dyu-1002.html) for pilot input

a) Could connect it to a laptop
b) Could connect it to a microcontroller (it was pretty easy to do that with a USB joystick using : http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=66&title=VDIP2 )

2) On the Gluonpilot, implement some sort of branching on the UART1 to select whether the input is a control signal or a configuration update. Maybe the control input could be prefixed by '$' or some character and then the next n characters would be treated as controls. Or something.

This would also make it easier to input precise controls on the fly such as go 50 knots, or maintain 5 degrees pitch, or go to 145m altitude, or go back to (lat, lon), or any number of things. These types of inputs could be numerical inputs on a ground station. But you could also fly the vehicle with your sticks if you wanted to.

If anyone else has ideas or is interested in trying this as well, I'm going to try and code something up. I'm not the best coder though, so help is hereby solicited!

-Chris

[Chris]

Here's where I am on the coding side:

uart1_queue.c is where the interrupt is for uart1. The actual parsing function for uart1 is uart1.c
I'm also looking at how uart2 works for the GPS, since that is parsed in real time during flight.

One difference between uart1 and uart2 interrupts as they are in the Gluonpilot code is uart1 uses "auto_psv" and uart2 uses "__shadow__", which have something to do with interrupt priority :

Code: Select all

void __attribute__((__interrupt__, auto_psv)) _U1RXInterrupt( void )
void __attribute__((__interrupt__, __shadow__)) _U2RXInterrupt(void)

Can anyone explain what the difference is? Does it matter for this?

[Mitch]

The shadow specifies fast context save - here are the examples from the c30 guide

/* No fast context save, and no variables stacked */
void __attribute__((interrupt, auto_psv)) _ADCInterrupt(void)

/* Fast context save (using push.s and pop.s) */
void __attribute__((interrupt, shadow, auto_psv)) _T1Interrupt(void)

/* Save and restore variables var1, var2, etc. */
void __attribute__((interrupt(save(variable1,variable2)), auto_psv))
_INT0Interrupt(void)

It will matter if you interrupt a lot, spend a lot of time in the interrupt routine, or change globals. Best to do as little processing in the interrupt routine as possible to avoid conflicts. I think the newer compilers (and chips) handle this a bit better but this used to cause nightmares that were very difficult to debug.

[Tom]

Hi Chris,

To get started, it best to leave them as they are If you wish to change any global variable in these routines, make sure they are "volatile".

If you only want stabilized control and not full manual, an update rate of something like 4Hz should be enough. Even though a lot of ESC's or digital servos praise their precision (10, 12 bit), it's not that important (10 to 6 bit is hardly noticable with servos). I'd stick with one byte or character. You'll need 4 channels I guess, so maybe it can fit into the normal gluonpilot "protocol": something like MC;ABCD which would be 7 (+2 line feeds) bytes per update.
Don't forget that the gluon firmware put's the uart1 parsing on a low priority thread. I'm not sure how this could affect performace.

Anyhow, for fast results I'd integrate it into the existing commands, and start optimizing from there on.

[Chris]

Thanks guys, I appreciate the help.

@Tom,
I like the idea of not messing with the interrupts, especially cuz my experieince with them is small.

For the number of bytes per channel, I was originally thinking 2 bytes per channel. However I doubt I can differentiate between 255 distinct points on the control sticks, so then 1 byte would be fine.

As for the low priority, I don't think that should be a problem if the updates are only coming at ~4Hz and the program is executing at >400Hz.

So then I'd write something like this in "communication_csv.c" in the function "void communication_input_task( void *parameters )"

Code: Select all

            ///////////////////////////////////////////////////////////////
            //                     SET PILOT INPUTS                      //
            ///////////////////////////////////////////////////////////////
            if (buffer[token[0]] == 'P' && buffer[token[0] + 1] == 'I')    // Set Pilot Inputs
            {
               config.control.pilot_inputs.desired_pitch = atoi(&(buffer[token[1]]));
               config.control.pilot_inputs.desired_roll = atoi(&(buffer[token[2]]));
               config.control.pilot_inputs.desired_yaw_rate = atoi(&(buffer[token[3]]));
               config.control.pilot_inputs.desired_throttle = atoi(&(buffer[token[4]]));
            }

with a new data structure config.control.pilot_inputs

That doesn't sound too hard. I'm sure it will take some time integrating the new data structure and replacing the PPM inputs with the new inputs form UART. I'll probably just comment all the PPM stuff out for now or do a bunch of #ifdef ENABLE_PPM_INPUT, #else, #endif like Tom did with the ENABLE_QUADCOPTER stuff.

Sound about right? I'll keep posting as progress occurs.

[Tom]

Hi Chris,

Yes that's about what I had in line. You can easily debug this using some printf's.

For a more streamlined protocol:

Code: Select all

            ///////////////////////////////////////////////////////////////
            //                     SET PILOT INPUTS                      //
            ///////////////////////////////////////////////////////////////
            if (buffer[token[0]] == 'P' && buffer[token[0] + 1] == 'I')    // Set Pilot Inputs
            {
               config.control.pilot_inputs.desired_pitch = buffer[token[1]+0] - 'A';
               config.control.pilot_inputs.desired_roll = buffer[token[1]+1] - 'A';
               config.control.pilot_inputs.desired_yaw_rate = buffer[token[1]+2] - 'A';
               config.control.pilot_inputs.desired_throttle = buffer[token[1]+3] - 'A';
            }

You could output PI;AAAA for all zero outputs or PI;ZZZZ for the highest value (or similar).

To make it work like PPM, you can input the data into the ppm_info struct, and set the appropriate ppm channel to "stabilized mode". Set connection_alive flag and maybe implement ppm_in_close() to stop the interrupt and prevent the function from setting connection_alive to false again.

I hope I wasn't too chaotic in this post

Tom

[Chris]

Yea that sounds perfect! At least this part I understand, sounds really simple:

-kill the PPM module by calling ppm_in_close()
-but set the connection_alive = 1 so I can use the ppm_info struct;

But, forgive my ignorance, how does the token[] work? What does it mean to subtract 'A'?

And just a thought, are there plans to release documentation for the code? That would be really really helpful, even though you are definitely quick to respond to questions on this forum, which I appreciate a lot!

[Tom]

I'm sorry for the lack of code documentation. It's always a hard decision: putting a lot of comments in your code and making it twice as long, or only document the really hard parts and hope everything else is understandable

if: input = PI;ABCD then
buffer[token[1]] = A
buffer[token[1] + 1] = B

and

buffer[token[1]] - 'A' = 0
buffer[token[1] + 1] - 'B' = 1
buffer[token[1] + 2] - 'C' = 2
buffer[token[1] + 3] - 'D' = 3

Hopefully I make more sense now

[Chris]

Great successes so far mixed with minor setbacks, lol.

The code was successfully modified to accept a new packet type and that data goes into the PPM struct.
We're using a gamepad controller right now as the pilot input. Might switch to a USB RC transmitter if the gamepad doesn't work well for piloting.

We're using LabView for the base station and found that we had to eliminate the '\n' before the command to make it work (as in PI;1;2;3;4\n instead of \nPI;1;2;3;4\n)

The XBee modules we're using won't work with the 5V FTDI USB-TTL cable (they are powered at 3.3V), what a rip! We can talk to the XBee via a level shifter to RS-232, but the laptop we need only has USB ports, haha. WTF mate?! So that means we're just using the cable direct to the Gluonpilot for now and we'll test the wireless link when our Sparkfun XBee dongle gets here.

I'll post again once the servos are moving via wireless comms!

[Tom]

Hi Chris,

Great progress, can't wait to include it in the main code tree

For the XBee module: I had the same problem. After som searching online, it turns out the the Xbee Regulated module switched RX and TX compared to the FTDI cable (so switch those 2 wires in the FTDI cable), AND it has a diode on the board (to lower voltage from 5V to 3V3), which is not needed!

So: switch RX and TX of your ftdi cable, and remove & short the diode on the board.

Tom