I was working on getting the SITL simulation up and running this weekend, and was able to modify MAVProxy.py to support real-time control via a joystick or gamepad, here is the updated file:

mavproxy_joy.py

It requires installation of pygame (http://www.pygame.org) It will probably require some modification to map the axes on your particular controller to the proper APM channels, in these lines:

cmd_rc(["1", str(int(j.get_axis(2)*400 + 1500))])
cmd_rc(["2", str(int(j.get_axis(3)*400 + 1500))])
cmd_rc(["3", str(int(-j.get_axis(1)*800 + 1100))])  #throttle
cmd_rc(["4", str(int(j.get_axis(0)*400 + 1500))])

pygame prints any control input changes to the terminal, which can be annoying because it scrolls away some of the normal mavproxy messages.

I tested it flying the ArduCopter, and it works well, hopefully it will be useful for testing modifications to manual control modes.

--------------------

Update:

I created a mavproxy module file that can be loaded into the normal version of mavproxy.py:

joystick.py

Copy this file into the /modules folder, and from within mavproxy, load the module by entering:

module load joystick

Axis mapping is still custom to the Logitech Dual Action, so modifications may be required for other devices.  One issue is that it still writes the state of the joystick axes to the console - I'm still looking into whether there is a way to suppress this.

For future work, I want to add support for some of the gamepad buttons to change rc channels 5-8 to be used for changing mode, dropping waypoints, etc,

Andrew

My AC2 is assembled, and I was able to do a couple indoor tethered test flights to make sure things are connected and setup properly.  Here is the first test:

This was somewhat of a success for the first flight, in that all of the electronics were basically working correctly, including wireless telemetry.  After re-checking all of the connections to determine why it was immediately pitching over, I found that the 4-wire connector from the APM to the PWB was plugged in backwards.  I switched it around, and re-ran the pre-flight test, paying closer attention to actually which motors were speeding up and slowing down at what time, and tried it again:

It's not immediately trying to pitch over, so I think the stabilization is basically working

A few other things are also going on here:
- There is probably a lot of weird air re-circulation going on in this small area that is causing it drift around, as well as dynamics from reaching the end of the tethers that are making it difficult to stay level.
- Toward the end, it seems to pitch to the back to the right. At this point, even after landing, the attitude showing on the laptop was far from level, I'm sure this is because the magnetometer was not getting a good reading inside, and also because the cords artificially held it at a nonzero pitch attitude without accelerating in that direction.
- I'm using a 20C 2200mah battery, which is too small for this since there are obviously 4 20amp speed controllers.

The next step is to take it outside to eliminate any re-circulation effect, make sure the magnetometer is getting a good reading, and get a GPS lock.  I will probably test it tethered again, maybe with longer tethers -  I think if I position the anchors further apart, the tendency might be to pitch back toward center when it reaches the end instead of pitch away.

So, I'd been having some trouble with my first APM board - I found the X and Y gyros were not working - I tested the connections, and found that the ADC was working correctly, but I was not getting a signal from the leads of the actual gyro chip.  It's been way more than 30 days since I ordered it, so I could not return it to the store, so I decided to bite the bullet and order a second APM.  After soldering it together, it appears to be fully functional.  Now I should be able to get on with some of the ROS stuff I mentioned in the last post.

Here is some more info on my blog, as well as a video of my pre-flight check of manual and FBW_A modes:

http://projects.electrictoast.net/2011/04/pre-flight-mode-test/

I've also been able to test it with a both QGroundcontrol, and the mission planner GCS successfully, so I'm hoping for a test flight later this week.

On a sidenote, I noticed that Sparkfun came out with a USB interface board for Andriod phones - which could be an excellent way to connect an XBee directly to an android for a phone or tablet-based ground station.

Recently I've been reading about the Robot Operating System (ROS) from Willow Garage and thinking about ways that it could interface with a UAV system to take advantage of many of the robot navigation and task planning routines that have already been developed for other platforms.  After going through some of the ROS tutorials, I started coding a publisher node for APM, it reads telemtry data via serial in the GCS Standard format, and publishes the data as ROS messages that can be subscribed to by any other ROS nodes.  My chosen language is Python:

#!/usr/bin/env python
import roslib; roslib.load_manifest('apm_talker')
import rospy
from std_msgs.msg import Int16MultiArray, MultiArrayDimension
import serial
import struct

def parsemessage(mtype, mdata):
 ddict = dict()
 if mtype=='\x01':
 ddict['SystemStatus'] = list()
 ddict['SystemStatus'].append(int(mdata[2].encode('hex'), 16))
 ddict['SystemStatus'].append(struct.unpack_from("h", mdata[5:7])[0])
 if mtype=='\x02':
 ddict['Attitude'] = list()
 ddict['Attitude'].append(struct.unpack_from("h", mdata[2:4])[0])
 ddict['Attitude'].append(struct.unpack_from("h", mdata[4:6])[0])
 ddict['Attitude'].append(struct.unpack_from("h", mdata[6:8])[0])

 if mtype=='\x04':
 ddict['PressureAlt'] = list()
 ddict['PressureAlt'].append(struct.unpack_from("I", mdata[2:6]))
 #if mtype=='\x05':
 #    ddict['StatusText'] = list()
 #    ddict['StatusText'].append(str(mdata[2:len(mdata)-2]))
 return ddict

def talker():
 pub = rospy.Publisher('apm_data', Int16MultiArray)
 rospy.init_node('talker')
 ser = serial.Serial("/dev/ttyUSB0", 57600)
 while not rospy.is_shutdown():
 f = ser.read(size=1)
 if f=='\x34':
 f = ser.read(size=1)
 if f=='\x44':
 f = ser.read(size=1)
 data = ser.read(size=int(f.encode('hex'), 16)+4)
 datadict = parsemessage(data[0], data)
 for signal in datadict:
 msg = Int16MultiArray()
 msg.layout.dim = [MultiArrayDimension(signal, 1, 1)]
 msg.data = datadict[signal]
 pub.publish(msg)
 #rospy.loginfo(msg)

if __name__ == '__main__':
 try:
 talker()
 except rospy.ROSInterruptException: pass

This is fairly basic, and it doesn't cover the entire APM message set.  There is still work to do to decide how the APM messages should be translated into ROS topics and messages to allow for the most flexibility when using it with other packages - for example, ROS seems to use quaternions when representing robot attitude, so it will be necessary to convert from the APM Euler angles.

More details on my projects blog including code for a subscriber node, and some details on how the whole thing is run.