Replies to This Discussion

Permalink Reply by Diarmuid Wrenne on September 1, 2009 at 7:38am

Hi James

Was that a single byte per servo? Have you any idea how much extra stuff the xbee adds to the packet for addressing, etc

Did you include a downlink for telemetry.

Diarmuid

• ▶ Reply

Permalink Reply by James Turner on September 1, 2009 at 11:44am

Hi Diarmuid,
yes it was single byte per servo, I'm not sure just how much extra is added to the packets but you can reduce it by switching off error checking and packet resends etc.. I do use telemetry which is sent every 400 or 500ms as long as nothing is being sent to the servo's (I started with an lprs radio so had to include this option). the Telemetry is 37 bytes long and includes stripped down gps, accelerometer and battery voltage.

• ▶ Reply

Permalink Reply by Diarmuid Wrenne on September 1, 2009 at 11:56am

Thanks
Did you always send all the values for all servos all the time or did you only send when a value changed.

For instance, the throttle servo, was that always sent as it would not change so much.

Diarmuid

• ▶ Reply

Permalink Reply by James Turner on September 1, 2009 at 12:00pm

Originally I thought only sending changed values would be a good idea then as I started testing it became a bad one because if a changed value wasn't received correctly then the servo would not be actioned until another change happened. For this reason I now send all 5 values.

• ▶ Reply

Permalink Reply by Andrew Dunlop on September 3, 2009 at 5:27am

It plugs into a Digi Xtend rather than an XBee, but it does have an 8 channel Pololu-compatible serial servo controller built-in. And a few other bits and pieces that might come in handy, such as a 2 amp switching power supply. You can disable the timeout completely and just use it as a telemetry platform.

You can send it serial garbage all day long and it wont crash.

http://www.millswoodeng.com.au/failsafe_device.html

Scroll to the bottom of the web page - there's a block diagram.

Andrew.

• ▶ Reply

Permalink Reply by Jeffrey Torella on March 7, 2010 at 5:22pm

Hey any way your drone design could.maybe possably go into a hover or short range glide mode while awaiting for the latency to catch up.or your not designed to hover like copter??

• ▶ Reply

Permalink Reply by Diarmuid Wrenne on March 18, 2010 at 4:02am

Hi Jeffery,

Generally I think some sort of graceful recovery from a comms failure (either permanent of intermittent) should be built into every UAV flightplan. Either a return to base and loiter or in the case of 'copter craft , a hover and descend mode. That said, If you think you are going to have significant latency, then an alternative coms method should be used. The idea of using zigbee was to save having to buy the radio hardware (and I bet that digital comms is the way forward anayway) . By using a zigbee for the comms, an onboard micro is needed in the UAV , so loads of different failure modes are possible.

In my development, the biggest latency was between the UI and the serial code, not the actual transmission stuff. But that was because I was trying to abstract the UI from the comms method and that didn't work for RT control.
Diarmuid

• ▶ Reply

Permalink Reply by Jeffrey Torella on March 25, 2010 at 8:51pm

yeah i got you completly now. thats was one thing i was considering also to completly cut out original rc transmitter/reciever . and just have a set of paired xbees or like devices to do complete control from my pc if needed. but as you mentioned the issues with falures that would come up are to many to think about..and i apologize for my random question im still new to all the electronics behind the autopilot..but i do agree your control layout should be further experimented with . good luck testing

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page