36 replies to this topic

[Brian]

I finally have a working version of my UAVTalk transmitter interface.  The original intent of this project was to see if it would be possible to only have one radio link to a UAV and still have reasonable manual control. The long term goal is to build a transmitter that has a full GCS with telementy, and still supports manual control.  What I ultimately envision is a combination of a transmitter and a (probably Android based) GCS in a small tablet.

I've found others that have built similar devices, but not for OpenPilot.  Fortunately others have tried similar experiments with sending receiver commands over UAVTalk, which means that I didn't have to build  in support for the underlying mechanism, which is the GCSReceiver UAVObject.

The reason that I didn't just use the existing manual control via the GCS is that I don't want to be required to have a GCS, and I also think there will be less latency using a real-time OS and dedicated hardware, and less possibility of loosing control from a system hangup/crash.

So that's enough of the background, now to what I have so far...

I wanted to build something initially that would be relatively easy and cheap to build, so I built a prototype box out of a cheap ($10) STM32 board, a standard receiver, an Xbee, and some glue hardware:

 IMG_20111215_203713.jpg   669.64K   82 downloads

This box contains the processor, Xbee, 72Mhz PWM (converted to PPM) receiver, a USB interface to the GCS, JTAG for programming, and even a header for connecting another serial port for debugging.  This is all wrapped up in a Radio Shack project box.  Currently it's powered by USB, but I plan to add a battery connector to the secondary board to power off of a standard 2S battery.  I used 2 boards because the processor and Xbee have 2mm pin spacing, so I have 2mm board connected to a standard 0.1" board via some 2mm connectors that I had lying around.

The software was the harder part.  It runs on a stripped down CopterControl firmware, with all of the standard modules removed, and a single new (TransmitterControls) module that (currently) reads the PPM receiver port and handles the message relay, and sending out the GCSReceiver packets.  The board initialization simply configures all 3 USARTS and the PPM receiver.  Fortunately it is requires less than 64kB blash, which is all that the STM32 CPU that I chose has on it.

I'm using PPM for the receiver interface, but one could easily configure it to use any of the standard receiver types.

As I said, the TransmitterControls module monitors 2 USARTS using UAVTalk, and relays messages between them, so it's acting as a passthrough between the GCS, which is on the USB port side, and the flight computer, which is on the Xbee side.  It also has a thread that reads the PPM receiver periodically and sends out GCSReceiver updates to the flight computer.  The GCSReceiver messages have priority over the other GCS messages, so the latency sending out a GCSReceiver packet should be at most a single packet time.

In order to implement this I had to make some changes to UAVTalk.  I added a status return from the receive function so that the receiver thread can know when a packet is complete, and I added a function to copy the packet out of the receive buffer so that it can be relayed.  I also added support for additional transmit buffers to lessen the chance of packets being dropped.  I plan to try to get these updated included in next when I've cleaned them up a bit.

In order to test this, I purposely did not include a receiver in my latest mini-quad build.  I plan to use that to test this, and I have already flown it a few time without a problem.  This is what it looks like:

 IMG_20111215_203439.jpg   974.67K   99 downloads

Thanks braindead4554 for sending me a motor to finish it with!

I've already started laying out version 2 of the transmitter hardware that is intended to replace the logic board in an old transmitter that I have:

 IMG_20111217_084835.jpg   819.95K   74 downloads

This version will go inside the transmitter, and will be attached directly to the sticks and switches, and will not need a receiver.  It will also include another Xbee slot that will be used to talk to the GCS.  It could contain an Xbee, a BluetoothBee, or WiFiBee.

I still need to do some more testing on the packet relay.  Normally it works very well, but I have had the GCS loose connection a couple of time, but I've never lost connection with the quad.  I want to add some debug to quantify latency and to track dropped packets.  I also want to test range, and add RSSI monitoring so that the GCS can warn if the signal strength is getting low.

Oh, and I think all this hardware could all be replaced by a PipX!

[Kenn Sebesta]

This looks really phenomenal, Brian. Job well done!

Have you thought about a timeout for properly formatted UAVTalk commands, where if it goes too long without receiving a properly formatted command, the model goes into failsafe mode?

[Brian]

Kenn Sebesta, on 17 December 2011 - 04:51 PM, said:

This looks really phenomenal, Brian. Job well done!

Have you thought about a timeout for properly formatted UAVTalk commands, where if it goes too long without receiving a properly formatted command, the model goes into failsafe mode?

Thanks!

If you're talking about on the flight computer, there is a failsafe on loosing connection to the receiver, but I'm not sure if that get's triggered when GCSReceiver messages are not arriving.  I'll have to look into that.

If you're talking about the GCS, the connection is not critical, so I don't think we need failsafes.  I do need to add a timer to reset the link if too many packets get dropped.  Currently, if the sender stops sending for some reason, or gets out of sync, everything stops.  That shouldn't happen unless there's a bug, but it would probably help to check for that condition.

[Kenn Sebesta]

Brian, on 17 December 2011 - 05:04 PM, said:

If you're talking about on the flight computer, there is a failsafe on loosing connection to the receiver, but I'm not sure if that get's triggered when GCSReceiver messages are not arriving.  I'll have to look into that.

If you're talking about the GCS, the connection is not critical, so I don't think we need failsafes.  I do need to add a timer to reset the link if too many packets get dropped.  Currently, if the sender stops sending for some reason, or gets out of sync, everything stops.  That shouldn't happen unless there's a bug, but it would probably help to check for that condition.

The former is the more interesting case. I am very, very interested by what you've done here, and am already pondering how to integrate it into my research. I just worry that in the event of a system/hardware crash, the vehicle might just keep going up, up, and away!

[Brian]

Kenn Sebesta, on 17 December 2011 - 05:11 PM, said:

The former is the more interesting case. I am very, very interested by what you've done here, and am already pondering how to integrate it into my research. I just worry that in the event of a system/hardware crash, the vehicle might just keep going up, up, and away!

I agree that that's a problem, and I'll look into how to add it.  I think the best way to add that would be to add a timer that is reset every time a GCSReceiver message is received.  Unfortunately, I don't think it could be added to the gcsrcvr code, because that's just a set of functions, there isn't currently a thread.  It could be added to the ManualControl module, but that's not as clean as I would like.

The other way of adding it would be to track the time of the last packet received in the gcsrcvr code, but then you have to worry about the timer wrapping around, etc.

[Brian]

I pushed my transmitter branch to Brian-UAVTalk-Transmitter.  It has some extra stuff in it that I'll cleanup later.

[Kenn Sebesta]

Brian, on 17 December 2011 - 05:21 PM, said:

It could be added to the ManualControl module, but that's not as clean as I would like.

I'm sure peabody124 will chime in on this, but it seems to me that this is the most practical place to put this, regardless of how you stream the commands. It allows for configurable timeout settings, so that for instance the vehicle can have a "go home" functionality in case of comm loss.

So the way that would look is that a timer would be triggered if a new command wasn't received sufficiently early, and then the module would either clamp the outputs to 0, or would commute to an automatic control mode.

[dankers]

This. is. awesome!

The flexibility and the new cool things this enables is fantastic.

[Reddog]

This is fantastic!

Brian are you able to explain how your transmitter is communicating with the quad. You seem to be using Xbees but you are also using a PPM receiver. It seems from your Quad photo you are using an Xbee but I was under the impression you could not get real time control using an Xbee. Maybe I am completely missing the point of this brilliant piece of hardware and software.

[Brian]

Reddog, on 18 December 2011 - 04:50 AM, said:

Brian are you able to explain how your transmitter is communicating with the quad. You seem to be using Xbees but you are also using a PPM receiver. It seems from your Quad photo you are using an Xbee but I was under the impression you could not get real time control using an Xbee. Maybe I am completely missing the point of this brilliant piece of hardware and software.

In my current setup, the transmitter communicates with my box via a PPM receiver in the box.  The PPM signal is read by the STM32 and converted into a GCSReceiver UAVObject, which is then sent over the Xbee telemetry link to the quad.

As for whether this is real-time control depends on the definition of real-time.  There surely is some additional latency going over the Xbee link, but I've tried to minimize it.  My next step is try to quantify what the latency is.  It shouldn't be more than a few 10s of miliseconds, but I need to test it to know for sure.  Whether that is too long likely depends on the pilot.  I haven't noticed any problem in the testing that I've done, but I'm not the best pilot.  Maybe a more advanced pilot would notice it more.

[peabody124]

Yeah this is really cool.  As for timeouts this should be fairly straighforward to deal with.  I would extend PIOS_GCSRCVR to register against the RTC periodic callbacks like the other drivers.  Then it should also record the times of updates when gcsreceiver_updated is called.  If the difference when you call get exceeds a timeout value then return PIOS_RCVR_TIMEOUT.

As for control via GCS I think that too should be equally possible.  However, it will require some work on the GCS telemetry to allow prioritized data transmission as right now the latency is unacceptable.

[Kenn Sebesta]

Brian, on 18 December 2011 - 04:13 PM, said:

As for whether this is real-time control depends on the definition of real-time.  There surely is some additional latency going over the Xbee link, but I've tried to minimize it.  My next step is try to quantify what the latency is.  It shouldn't be more than a few 10s of miliseconds, but I need to test it to know for sure.  Whether that is too long likely depends on the pilot.  I haven't noticed any problem in the testing that I've done, but I'm not the best pilot.  Maybe a more advanced pilot would notice it more.

Do you have an oscilloscope or logic analyzer handy? You could try to quantify the control delay by 1) using only a direct TX-->RX-->CC path and measuring the delay between an input and output and 2) performing the same experiment with the TX-->STM32-->Xbee-->Xbee-->CC. The easiest trigger to set up is probably on the flight-mode switch, as going from stabilized to manual will cause all the control outputs to catastrophically change.

[Kenn Sebesta]

Reddog, on 18 December 2011 - 04:50 AM, said:

It seems from your Quad photo you are using an Xbee but I was under the impression you could not get real time control using an Xbee.

This is not an XBee problem, but a greater problem with 802.15.4 in general: http://www.digi.com/...etl.jsp?id=3065

Basically, there's an inherent latency due to the way it tries to clear the channel, so you can indeed get some very delayed packets.

[Brian]

peabody124, on 18 December 2011 - 04:44 PM, said:

Yeah this is really cool.  As for timeouts this should be fairly straighforward to deal with.  I would extend PIOS_GCSRCVR to register against the RTC periodic callbacks like the other drivers.  Then it should also record the times of updates when gcsreceiver_updated is called.  If the difference when you call get exceeds a timeout value then return PIOS_RCVR_TIMEOUT.

Do you think we should go ahead and make this an optional module?  I believe the initialization routine always gets called for the CC, and we don't want to add periodic callbacks if it's not being used.

[Brian]

Kenn Sebesta, on 18 December 2011 - 04:54 PM, said:

Do you have an oscilloscope or logic analyzer handy? You could try to quantify the control delay by 1) using only a direct TX-->RX-->CC path and measuring the delay between an input and output and 2) performing the same experiment with the TX-->STM32-->Xbee-->Xbee-->CC. The easiest trigger to set up is probably on the flight-mode switch, as going from stabilized to manual will cause all the control outputs to catastrophically change.

I have an oscilloscope, but it's pretty much junk!   I have access to one at work, and might try what you suggest.  I had planned on adding a debug ID and time field to the packets, and record the packet ID/times to see if packets are being dropped and latency in real life scenarios.  the only problem with that idea is synchronizing timers.

[Brian]

Kenn Sebesta, on 18 December 2011 - 05:31 PM, said:

This is not an XBee problem, but a greater problem with 802.15.4 in general: http://www.digi.com/...etl.jsp?id=3065

Basically, there's an inherent latency due to the way it tries to clear the channel, so you can indeed get some very delayed packets.

Thanks for the link.  That's a very detailed analysis.  Unfortunately, I think our worst case will be when a long lower-priority packet just started being transmitter when a receiver packet is ready to send.  At 56k baud, this could take several ms to clear.  One way to solve this would be to synchronize the reading of the receiver with the transmit thread, so the transmit thread doesn't start sending a packet if it is almost time to read the receiver.

Now that I think about it, the transmit thread could read the receiver.  Then it would be explicitly synchronized.

On the other hand, the ManualControl module on the CC only reads the receiver every 20ms, which would imply that a few ms of latency is probably not too great.

It would be great if we could do a blind test using an experienced pilot to see at what latency they start noticing it.  That would be easy to do by adding an artificial latency in the ManualControl module.  Sound like a good research project!

[D-Lite]

Brian, on 17 December 2011 - 04:42 PM, said:

I finally have a working version of my UAVTalk transmitter interface.  

Wow, that great news! I'd really like to replace my 35Mhz transmitter with something like this, but with two BT modules, a class 1 for the connection to the quad and a class 2 for the GCS connection. I never liked that ultra-long 35Mhz antennas, makes you look so nerdy  

[Brian]

D-Lite, on 18 December 2011 - 09:36 PM, said:

Wow, that great news! I'd really like to replace my 35Mhz transmitter with something like this, but with two BT modules, a class 1 for the connection to the quad and a class 2 for the GCS connection. I never liked that ultra-long 35Mhz antennas, makes you look so nerdy  

You know, if you can settle for a USB interface to the GCS and PPM receiver interface, I think you can implement this on a move controller.  I thought about doing that, but I already had the other hardware, so I decided to use it.  It would be especially nice, though, if the battery charger could be enabled.

[Reddog]

Kenn Sebesta, on 18 December 2011 - 05:31 PM, said:

This is not an XBee problem, but a greater problem with 802.15.4 in general: http://www.digi.com/...etl.jsp?id=3065

Basically, there's an inherent latency due to the way it tries to clear the channel, so you can indeed get some very delayed packets.

So its more based on the software digi uses than a problem with RF transmission rates? If digis software was setup for low latency and nothing more then we would not have this problem?

[Kenn Sebesta]

Reddog, on 18 December 2011 - 10:52 PM, said:

So its more based on the software digi uses than a problem with RF transmission rates? If digis software was setup for low latency and nothing more then we would not have this problem?

This is by design. 802.15.4 networks are called PANs (Personal Area Networks), so they're designed to work to some extent, no matter the interference. They're for things like sending an e-business card, or telling you "your front door is open", or communicating between the thermostat and the hot water heater. We're really pushing their limits hard by asking them to do wireless telemetry of fast-moving dynamic systems. I'm guessing this was some of the motivation for creating the PipExtreme in the first place.