Palm GCS Continued

I'm using a baud rate of 38400 for all serial ports; xbee's, Arduino to Palm, ArduIMU to Arduino Mega etc. I found that the higher baud rates increased latency on xbee's but didn't troubleshoot further to really explain the issue. With the packet size and baud rate as they are, the largest packet still allow a long enough time between packets for easy decoding and processing before the next packet arrives, at either end. On the GCS side I'm simply passing every byte as it arrives to the Palm. The Arduino manages the thumb sticks processing, I don't do any control yet using the Palm. I have a landing screen with a simple ILS indicator but have yet to perfect the GPS processing to make it work.

My ultimate goal with this project is a fully autonomous vehicle, able to launch, fly, and land under its own control. So I'm working it up in stages, manual control, fly-by-wire, autonomous flight, autonomous landing, etc...

I'll start posting some code, schematics and documentation as I get it organized but none of it is out of the ordinary for here. Hopefully the following will answer any questions:

Important hardware bits:

To interface with a Palm you'll need a level shifter to get the Palm side to read standard RS-232 signals, 5V won't work. I use one of these and it works well.

The thumb sticks are not very good compared to RC sticks. The range of motion on them is really small. To get reasonable controlability out of them I use exponential throw for them and this works well. The push-button feature of them is however nice. I'll eventually use it on both sticks to change flight modes and other functions. If I ever move this design into a real enclosure I'll probably switch to RC sticks.

So far everything I'm using is common off-the-shelf stuff with the exception of the airborne ArduPilot Mega Beta, I thought it a good recycling project for it, but a regular Arduino Mega will do, or as an alternative , use a Arduino Pro Mini with serial port used for Xbee and I2C for IMU (if you use it).

I use a UBEC on the airborne side for the servo's and a separate one for all the electronics. Ground testing showed voltage drops from heavy servo use so I want to make sure the electronics have thier own clean power. I fly heli's and voltage drops are typical when running servos off the ESC's BEC, so all my heli's have servo UBECs.

The thumb sticks and enclosure layout is very comfortable as-is. I power the GCS off a 750mah 3S and get over an 2 hours of use out of it.

Edit: I forgot to mention the throttle control using the thumb stick: You can open up the stick and remove the spring, but I managed to wreck 2 trying this. After removing the spring, you need to reassemble it and to do so means bending the little metal tabs back over the plastic, press to hard and you can crush the whole thing so be careful if you try this.


Important software bits:

So far I've avoided using any timer or interrupts to keep the code simple for the Arduino side of things.

Servo control:
I originally used 2 bytes for the channel data in order to get the microsecond resolution on the servo's but after comparing that to single digit degree resolution I couldn't tell the difference so dropped to 1 byte channel positions. Micro second resolution would be needed for a quad rotor.

Palm:
The Palm software I'm using (Handheld Basic HH++) is free for non-commercial use. It runs on most any Palm going back to version 3.5. I've got a box full of Vx's I bought of ebay for $15 and a couple m500. The m500 is better since it has a SD Card slot for data logging. I just got a spare serial cable for mine and have yet to modify it for the GCS. The Palm processor in these older models can handle the graphics needs for simple UAV displays, and at the baud rate I'm using easily keeps up with the data refresh rate. The rate I get allows me to fly looking at the display if needed.
Since the display on the palm is limited, I use a small area in the lower left corner as a simple 'master caution' panel. When ever an alert occurs (low fuel, signal loss, etc) a click-able message is displayed along with a unique frequency beep. The alerts are prioritized and the message remains until it is cleared. Any lower priority messages will then display for clearing. There are only 5 or so alerts so the sound alone tells me whats up without having to look down.


Gotta get to work....







E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • If that Android can be read in sunlight, or maybe use a black and white color scheme, one of these would be just the thing. Separating the controller from the radio equipment may be a good idea too.
  • I'm using the standard Servo.h library. The control packets use 1 byte for each channel to represent the servo position in degrees. The workable range is 180 degrees but I'm only using 120 as per most RC systems. It is hard to physically connect the servo actuation beyond plus/minus 60 degrees.
  • Just curious, what method are you using for actually having the arduino control the servos? I think I've seen a few different servo libraries, some more efficient than others.
  • Developer
    Great work! Now please redo the project using this.. http://www.dealextreme.com/details.dx/sku.39169
    A $100 7" Ipad "clone" running Android. :)
  • I would love to hear more about the ILS look-alike feature! Are you computing and outputting a lateral and vertical deviation?
  • Regarding the channel change protocol, it works well even when rapidly moving the sticks for a few seconds, no latency results. Channel changes are sent at 50hz, the same rate as the analogReads are done on the stick potentiometers. To duplicate a 50hz constant RC signal you need to move the sticks really fast and constantly before latency starts to show up, not something typical of a UAV flyer. I haven't tried turning on encryption on the Xbee, I'll bet that would slow things down a bit. I'm also flying with a rubber ducky antenna on the airbone xbee, and just got a high power rubber ducky from Digikey yesterday. Not sure why, so far the range on the XBee Pro has been excellent. I'll be camping in the desert this weekend so might try some longer distance flights.
  • GREAT project !
    The $19 RC simulator trainers are a good source for parts, enclosure.
    Earl
  • Great info, thanks! Using xbees for control as well as telemetry has been on my todo list for a while now. This should eliminate quite a bit of guess work, and I like your protocol for only sending channel changes, and then verifying that they're correct.
This reply was deleted.