Blogs

We're a small startup working on a project for tracking and sharing the location of UAVs and drones in real time via the web. Flights are tracked by attaching a smartphone to a drone and distributing a URL which lets your friends follow your flights in realtime on a map in a web browser.

We've been focused on building and solidifying a backend system and API to support our iPhone application. (an Android app is in the works) We're interested in feedback from the community on what we got right / wrong and where we should take the project.

Take a look at http://droneos.com and sign up for the beta if you are interested in trying it out. We are at SXSW this week if you are interested in meeting up or DM us at @droneos via Twitter.

As part of my plans to make a balloon-launched, return-to-launch UAV glider, I was looking out for a HD video camera that I could use in a typical fuselage installation.  I chose to invest my hard-earned into the Drift HD170 mostly because I figured the rotating lens meant that it was probably separate from the main processor board.  Only purchase and disassembly would find out...!

So, here's the full teardown and inspection of the device

The basic unit weighs 138g according the Drift, but stripped to this level it comes in at 58-60g, SD card included. The standard battery weighs 26g, but I intend to power the device from a central on-board battery pack, noise notwithstanding.

I plan on using the Skyfun as my airframe, so keeping the centre-of-gravity under control is my main priority.  This will be mounted in the nose of the airframe, so losing every possible gram is important to me, but damn that lens is still pretty weighty! (about 30g of the 58g total!)

Finally, you can now use ArduPilot Mega without ever having to touch Arduino! Michael Oborne's terrific Mission Planner will now check for the latest code online and load the firmware directly, with no Arduino compilation process required. I've updated the APM 2.0 beta instructions to show how to use it.

You can still use Arduino if you want to fiddle with the code, but most people won't need it at all. No need to even have it running on your machine!

Right now it only supports the default configuration, but in the next day or two it will allow you to choose other common configurations, such as Xplane simulation mode.

The Buran spacecraft (Russian: Бура́н, IPA: [bʊˈran], Snowstorm or Blizzard), GRAU index 11F35 K1 is a Russian (Soviet) orbital vehicle (in Russian terminology: "орбитальный самолет", - "orbital airplane") analogous in function to the U.S. Space Shuttle and developed by Chief Designer Gleb Lozino-Lozinsky of Energia rocket corporation. To this day Buran remains the only space shuttle vehicle from the Soviet Buran program that was launched in space before the program closure. The Buran completed one unmanned spaceflight in 1988 before the cancellation of the program in 1993 and was later stored in a hangar at Baykonur cosmodrome before a hangar collapse accident in 2002 destroyed both the hangar and the orbital vehicle. ^[2]

Flight into space
The only orbital launch of Buran occurred at 3:00 UTC on 15 November 1988 from Baikonur Cosmodrome Site 110/37. It was lifted into orbit unmanned by the specially designed Energia rocket, which to this day remains the heaviest rocket running on liquid fuel. Unlike the Space Shuttle, which is propelled by a combination of solid boosters and the Shuttle's own liquid-fuel engines sourcing fuel from a large fuel tank, the Energia-Buran system used only thrust from the rocket's four RD liquid-fuel engines developed by Valentin Glushko. From the very beginning Buran was intended to be used in both fully automatic and manual mode. Although the program accumulated a several-years delay, to this day Buran remains the only space shuttle to ever perform an unmanned flight in fully automatic mode. The automated launch sequence performed as specified, and the Energia rocket lifted the vehicle into a temporary orbit before the orbiter separated as programmed. After boosting itself to a higher orbit and completing two revolutions around the Earth, ODU (engine control system) engines fired automatically to begin the descent into the atmosphere. Exactly 206 minutes into the mission, the Buran orbiter landed, having lost only five of its 38,000 thermal tiles over the course of the flight.[4] The automated landing took place on a runway at Baikonur Cosmodrome where, despite a lateral wind speed of 61.2 kilometres per hour (38.0 mph), it landed only 3 metres (9.8 ft) laterally and 10 metres (33 ft) longitudinally from the target mark.[4] The unmanned flight was the first time that a spacecraft of this size and complexity had been launched, completed maneuvers in orbit, re-entered the atmosphere, and landed under automatic guidance.- 

wiki source:Buran (spacecraft)

I'm delighted to announce the release of the first public beta of ArduPilot Mega 2.0. This is a significant upgrade to APM 1.02, and now delivers on full 2-way in-air communications, including real-time mission planning and autopilot control.

[UPDATE:Arduino-free code uploading added to features]

New features/changes include:

• --Full support for the MAVlink protocol, which is now APM's default communications method.
• --Auto-detection of GPS modules. No more requirement to tell APM what GPS module you're using--it will figure it out and configure the module appropriately!
• --2-way telemetry.  Dozens of commands can now be sent from the Ground Station to the UAV while it's in the air. (see example from HK GCS at right)
• --2-way Mission Planning. You can script and change missions in real time while the UAV is flying!
• --Supports APM boards with the ATMega2560 chip, which has twice as much memory as the current board. The DIY Drones store will begin selling these new boards when the final version of APM 2.0 is released.
• --Mission Planner now uploads firmware and checks for new versions online. No need for Arduino (unless you want it)!
  
• --Magnetometer fully supported.
• --Current sensor fully supported
• --Support for the latest HK Ground Control Station and QGroundControl ground stations.
• --Mission Planning and configuration can now be done wirelessly. No need to use USB if you don't want to.
• --No more fiddling with a configuration file in Arduino! The software comes ready to go, right out of the box
• --New command-line tests allow you to check failsafe operation, Xbees, radio inputs and more.
• --New versions of HK GCS and the Mission Planner operate in MAVLink mode, allowing for wireless operation and compatibility with other MAVLink devices, including those running the Robot Operating System (ROS)

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

Huge props to the whole development team: Doug Weibel (project leader), Michael Smith, Jason Short, James Goppert, Michael Oborne (mission planner), Paul Mather (GCS), Lorenz Meier (MAVLink integration), Randy Mackay, Ryan Beall, Darren Corley, Joe Holdsworth, and countless others who have contributed with flight testing and bug catching!

Remember that this is an initial beta release, so there may be bugs and undocumented bits. After the beta-testing period (usually about six weeks) we'll release APM 2.0 final version, and retire APM 1.02.

Loading the code automatically:

Just download the Mission Planner and select "Upload Firmware" from the Tools section of the menu. Make sure APM is plugged into your USB port and you've selected the right port from the Mission Planner menu. Click on "Update Check" and the program will search online for the latest version of the code and load it to APM.

If you want to do a simulation with Xplane, follow the instructions below. That will soon be a firmware option with the Mission Planner, too.

Loading manually (Optional)

[UPDATE: Ignore this section if you don't want to fiddle with the code. Arduino is no longer required to load the code!]

Download the zip file, unzip it to your desktop. You will have two folders inside your APM 2.0 folder, as shown:

Make sure you're using the latest Arduino (0022). Set your Arduino Sketchbook location to the APM 2.0 folder, as shown below. You must exit Arduino and restart it for this to take effect. Within Arduino, open up the ArduPilotMega.pde file within the ArduPilotMega folder, and that will open all the other files. Before you compile, don't forget to select the right board (Arduino Mega 1280 or Arduino Mega 2560)

(Note: in the final version of APM 2.0, you will not have to use the Arduino IDE at all: the Mission Planner will load the firmware for you and check for more recent versions. The Arduino IDE will just be available in case you want to modify or inspect the code. UPDATE: this is now live)

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

Additional instructions:

--If you're doing flight simulation with Xplane, instructions for doing it with APM 2.0 are here.

--Make sure you're using the latest Mission Planner and HK GCS. In the Mission Planner, make sure you select APM 2.x modes (MAVLink), shown at right.

Known issues:

1) Mission Planner won't write waypoints on Port 0 in HIL mode. Instead, write the waypoints via your Xbee (port 3); remember to change the Mission Planner baud rate to 57k when using the Xbee port.
2) Uploading mission commands is still not fully documented. We'll get to that this week
3) There may be some issues with datalogs not recording. We're looking into it.

4) The manual still describes the 1.02 software. We'll change that to 2.0 during the beta test period, so by the time we release the final of 2.0 the manual is fully updated.

5) This has been mostly tested with 900 Mhz Xbee modules and the XstreamBee adapter, which work great. However, there is an issue with the 2.4 Ghz Xbee modules, which have a slightly different hardware configuration that conflicts with that adapter when sending data upstream. A short term workaround is to solder a jumper from the adapter's CTS to V+ pin. The next version of these adapter boards will include a more graceful fix.

If you find any bugs, please file a report in the Issue Tracker. The dev team will not be responding to bug reports filed in blog comments

Boards:
APM
Oilpan
Arduino Pro
Freewave Radio
Eflight ESC & Motor
H264 Video Server

Joysticks that work:

Logitech G940 (no yaw on foot pedals yet) - Working on getting trim math working in the code.

Logitech Attack 3 (Tested all control surfaces working)

Other:
2 Cameras, 1 foward facing, 1 PTZ

Using Laptop with UBUNTU and Logitech Joysticks.

Phase 1:

a. Working Joystick Controls all surfaces of Airframe, Various buttons on Joystick change APM flight mode.
a. Completed

Added:

b. Working on integrating Logitech G940 Flight System

no yaw on foot pedals as off yet, does n't seem to show in the PYGAME librarys.

work to be done.

Phase 2: Complete
a. General Test - Live video through radio and video server.

b. Need to test and measure various bandwidth requirements for H264, frame sizes etc...

Phase 3: Complete
a. 4 Mile Test - 74db signal level Great video quality control surfaces respond instantly.
b. 15 mile test coming shortly.

Phase 4:Working on it.
Test GCS with waypoints.

 

Phase 5: Drop everything neatly back into airframe.

Finally caved in & built a traditional rotating actuator.  Didn't like
the weight or complexity of these, but they're the only way to keep the
distance between coil & magnet constant throughout the motion.  Having a
minimal distance between coil & magnet is where the maximum force comes
from.

The test article was made from balsa.  Medical tape once again came in
to shield the mechanical shaft from the wire.  It has 3x more wire than
actuator #1.

It certainly caused a lot more motion, but yet again, not enough force
for a full wing actuator.  Forget about moving the entire wing in our
mass budget.  Variable pitch is out.  It can move a 1" x 13" x 1/16"
flap against gravity, for a short time.  It might work in a ducted fan
VTOL.









Next, another solenoid with the 1" flap.  Pretty good deflection with
this one.  Quite an alignment problem.  The permanent magnet needs to be
halfway down the solenoid to get the most thrust.  Any lower & it's
attracted downward.  Any higher & it's not deflected as far.  This leads
to a gnarly wing stand.

Really disappointing to not be able to move the entire wing, but that's
why we don't have variable pitch wings on airliners.

Thus begins another round of solenoid tests with 1" flaps & another $2
of magnets.  A vi ate ing does suck money even without any flying.



Efforts continue on improving radio weather resistance with
polyeurethane.



The 900Mhz Marcy 1 ground station sees daylight again.



Marcy 1 flight computer, covered in dust, insects, & polyeurethane.



New wing attachment required some fancy woodworking.



Didn't like this wing attachment, but it was the only way.



To fit the solenoid in.  We do not claim any crash resistence.









This one stayed up for 6 seconds at 3.3V before the TO-220 voltage
regulator fell over.  With this kind of Amp suckage, you're not likely
to get an increase in lift without a decrease in motor output.  Next
comes making a more efficient actuator.



Straight from RCGroups lore, it's CA glued pieces of plastic.







This 4ohm 4g monster held for 10 seconds at 3V.  It even actuates at
2V.  With BJT + magnets, it probably weighs over 6g.  BJT's serve us better than

MOSFETs because they can handle back EMF.

The smallest servo is the GWS Pico, weighing 5.4g.  That could move the
entire wing, but burns out quickly.  The only other redeeming quality of
actuators is the price.

The main drag on this operation is the fact that actuating the wing is going

to suck a lot of power.





Next, in the Marcy 1 weight reduction department, it's spray paint
stenciling.  That was real unpleasant to carve out.





It's very inconsistent.  We have many wings yet to crash.  Should have used
transparency instead of paper.  The lighter the spraying, the better.  1 pass is all it can handle

before it bleeds.

A new board for Vika 1 started.



This one's intended to minimize GPS interference.  It has a shielded
oscillator at 40Mhz.  40Mhz is the dead zone.  It was the 1st Vika 1
board we ever laid out.  It was laid out in 2009, before Major Marcy, & before

we were confident in crystals.



There's nothing new in it.  Once again, forgot to put the GPS voltage
converter on it, provide enough pins for everything, provide capacitor
pins.

It's exactly 1 year to the day since the 1 & only time Major Marcy said anything to
us in real life.

It's a dark anniversary.  Now that 1 year has passed, it really is
final.  There was a bet whether we'd ever be in a photo with Her.
Mathematically, it seemed likely, 1 year ago.  It never happened. 

While She was very reclusive, only associating with a handful of people in real life,

was really freaked out by men who didn't demonstrate traditional male dominance,

it was the laying of a very negative judgment on our work to have a heroine Air Force

Major want nothing to do with us.

From the video description:  "Northrop Grumman video showing its Proteus manned test aircraft (left) and a NASA Global Hawk unmanned aircraft (right) conducting the first simulated autonomous aerial refueling at high altitude. Proteus (acting the the tanker) and the Global Hawk (as the receiver - its the reverse of the normal way) flew as close as 40ft apart at an altitude of 45,000ft in a risk-reduction flight for the US Defense Advanced Research Projects Agency's KQ-X program. Wake turbulence between the aircraft as well as engine performance and flight control responsiveness in the stratosphere were evaluated."

{via Robots.net}

First bit of work: software setup.

Please take a look and let me know what you think!

http://code.google.com/p/ardupilot-mega/wiki/BeginnersSoftwareSetup

Hello Guys,
I am here for the latest update, I would say that many were waiting ... We are finally back to fly .. it starts from where I stopped with QuadFox V3, but now with much more power 'you can use to fly our beautiful quad.
What I posted and 'the first official flight after the failure of Sunday's pre-flight test due to malfunction of the GyroZ OilPan, promptly replaced by Jordi , thank you Chris and Jordi for your support ,Diydrones of which' was timely in sending, sent from the United States Sunday arrived today mounted and here is the first flight. Only preliminary tests. I used the firmware version published Sunday .I put new IMU and flies as I suggested no major problems except the ones I had already' seen in pre-flight test, but going to be solved improve some operations, particularly the libraries that I rewrote the management of the radio, the problem I have is' above them.
The test that I did use Arducopter NG 32, Multipilot32 as CPU, OilPan as IMU, ESC Chinese engines from 6 € robby recovered from my old mk, rx Graupner 12 ppm scan analog output sum .. 3S 20c Lipo Battery
I also remember that for those interested in doing another online seminar tomorrow on the product roadmap of Multipilot32. I predict that the stable version for standard users will be 'available within a month of work today. The actual and the 'pre alpha version only for Developer and Hard coder who know what they do when they hold a pre-review software.
I put online the RoadMap presentation , this is the link

http://www.virtualrobotix.com/profiles/blogs/arducopter-32-roadmap-webinar

Greetings
Roberto

I finally managed to fly with APM on Sunday. Here are some photos and a video of loitering. Well, it was flying a pattern which first looked like a figure 8 and then the olympic rings. Any idea why? Will check everything again and fly a real mission when I can.
Preliminary conclusions: Manual mode is good, stabilize is very convincing, FBWA and FBWB work, loitering must be checked. PID parameters appear to be reasonable, no sudden movements.

It was awesome to have the model fly with me hands off for the first time!

The setup:
Reichard Proxima II glider, 2,78 m wingspan.
HS82MG AIL and FLAPS, HS65HB ELE and 9g cheap servo for RUD.
Dymond AL3548 outrunner 630 watt, 900 Upm/V and 60A Dymond regulator.
11,1 V 3300mAh LiPo battery
13" x 6,5" folding propeller

Radio:

Futaba T8FG with RH6008HS RX
Ch1: AIL with Y-cable
Ch3: Motor
Ch4: ELE
Ch5: RUD
Ch6: Flight mode control
Ch7 and Ch8: Flaps, not connected to APM but directly to the RX.

APM:

APM, IMU, Mediatek GPS MT3329, XBee 900MHz wire. Powered by a separate 1000mAh LiPo at 7,4 V (solder jumper removed).

Portable PC ASUS Eee 1000H with XBee 900MHz&duck antenna and HappyKillmore's GCS (that I can't look at when I'm flying anyway).

FlycamOneIII

Next improvements to be done are:
Connect the airspeed sensor.
Find a better way to mount the APM and associates under the hood whilst maintaining access to buttons, connectors and view of LEDs (transparent hood, holes).
Sort out the chaos of servo-cables in the fuselage.
Variometer based on a high precision pressure sensor, I2C/SPI.

Other issues:
Flaps are controlled manually on two separate channels to slow down for landing. It would have been nice to have differential ailerons, but I understand it's a matter of priorities. None of the other mixes (e.g. butterfly) will work because of the y-cable so we might as well accept to live without them in the APM domain, for the time being.

The model is quite beaten up, it has 55 hours of flying on it and a few crashes too. A brand new copy sits in the basement and will be used to build a perfect Proxima with APM when all tests and trials are completed. I will come back to you to discuss particular technical issues in the appropriate sections of the forum.

Cheers from
Parapendioper, Italy.

Trimming is an important part of control design. By finding natural equilibrium points in a system, less control effort is required to keep the plane flying as desired. This software lets you compute trim points for aircraft ranging from the easystar and quadrotors to f16's and 737's. Anything that can be modelled with a JSBSim model will work.

There are many JSBSim models already developed for flight simulators like FlightGear that can be used as low fidelity models. For higher fidelity models, wind tunnel data can be used within the JSBSim file as done with the easystar model in mavsim. All of this software is open source and available for download.

download: https://github.com/openmav/mavsim
wiki: https://github.com/openmav/mavsim/wiki

If you find any bugs please post them here:
https://github.com/openmav/mavsim/issues

Here's a cool new product from the Maker Shed: Blink RC. It's a wifi-to-RC board, which can let you replace your RC gear with a smartphone or other wifi-enabled computer. From the announcement:

The BlinkRC from the Maker Shed replaces your standard remote control receiver in your car, plane, or boat, and allows you to control it with your smart phone. The more adventurous can try creating an application on your computer that takes advantage of the open messaging protocol and the BlinkRC’s (3) output channels and (2) analog input channels. Now you can control a variety of different servo’s and sensors from almost anywhere that has WiFi or Internet access.

A few thoughts:

1) Looks good! But...

2) $125!!!

3) Wifi range limitation makes it inappropriate for most aircraft applications

4) Not open source :-(

Here are the full specs:

• 802.11b/g/n connectivity
• Onboard low-profile WiFi chip antenna
• Onboard U.FL-R-SMT-1 external WiFi antenna connector
• Infrastructure or Ad-Hoc Modes
• Transmit range up to 330' depending on environmental / antenna considerations
• Requires 3.5vdc to 5.5vdc regulated input (typically from ESC)
• Three (3) Output Channels for Servo/ESC control
• Two (2) 0-20v analog input channels with 8-bit resolution
• Reverse Polarity Protection on Battery input
• Optional plastic enclosure
• FREE download of iPhone controller app
• FREE download of PC compatible controller app
• FREE download of Droid controller app (coming soon)
• FREE download of Blackberry controller app (coming soon)
• Dimensions: 2.8" (L) x 1.0" (W) x 0.25" (H)
• Weight: Approximately ~4oz
• Outputs: Three (3) Universal/Futaba J Style Connectors
• Inputs: Two (2) .1" Header Connectors w/ +5V and GND Available for Sensors

The MAVLink mailing list is currently very actively discussing which route to take to CAN-MAVLink integration. Especially engineers working in their day jobs on ARINC 825 or CANaerospace could bring important feedback to the table, so please share your knowledge.

Google Groups MAVLink CAN discussion

 Since this design will be very likely the reference design not only for the first 2-3 autopilots implementing it, but might also become the DIYDrones community standard, I'd like to invite all potential developers and adopter to join the discussion (on the mailing list please, not in the comments).

Further reading:
http://de.wikipedia.org/wiki/CANaerospace

http://en.wikipedia.org/wiki/ARINC_825

Hi Guys I have for some time been developing this flying camera, I say camera as this is a departure from the norm. Whereas most people make a copter that just happens to have a camera mount this is different. The operator fly's the camera and the uav follows the envelope that is required to stay within the shooting angles selected. I am new to arduino so any help is what I need most. It has a number of other features such as the ability to land on water.

Hello,

I'm still working on my Interception/Injection board for my Spektrum Dx6i, here is the news :

• the interception is working like a charm, I can monitor all of the 6 channels on the groundstation (the 9 gauge on the left), It can be plugged to usb or over bluetooth.
• the flying board is (for now) equipped with GPS an a 3 axis accelerometer (gyro is on the way)
• both boards have a rfm22 (the same used by OpenLrs), for now only the flying board is transmitting the GPS and the Acc data.
• First try developping a quick GroundStation as demonstrator, with horizon, altimeter and speed, Acc Data and even a google map ;) The GS is working on Win32 and Windows mobile, I'm planing on porting it on Android when I'll have an Android

Hi Guys!

If you have not seen this yet check it out!

It is the Devil Ray 2.4M flying wing  made by Chris McNair.

We asked him to make one for us to use in the Australian Outback UAV Challenge. And before you ask we have an ATTO IMU onboard!

The Devil Ray has the option of 3 different wing sets 1.8m, 2.4m and a 3.6m. (We have the 2.4m)
With all the extra gear needed for the OBC, PTZ camera, 500ml water bottle, failsafe systems, transmitters, modems etc..
We loaded it up to 6.75Kg total weight. With all this extra crap on board it still had a easy take off and climbed nicely.
I still remember being impressed that even in manual mode (just over half throttle) it was doing 90-100Kph and was only pulling 15 amps.
(This is better in Autonomous!) We have a 6S 10,000mAh pack on board.
It has a very large speed envelope and handles great in the air.
The marked CG point was perfect and there is heaps of room inside which made it easy to balance. Landing speed is a crawl and has proved to be easier than the 12’ Telemaster to land.
I have an attached a couple of photos below.
I know Chris has refined the design (since making ours) and is now selling them with multiple options ranging from marine application that is water proof to a retract landing gear option for clean smooth flight.
The fixed landing gear option is nice but does add a bit more weight due to the very large wheels for our flying fields.
The Devil Ray is definitely worth having a look at if you are in the market for a high efficiency flying wing with a very large payload bay.
It also brakes down into a nice size carrying case or box.

If you like what you see you can contact Chris at chris@attopilotinternational.com as they are now available.

Cheers

Scott (Melbourne UAV)

www.melbourneuav.com

www.twitter.com/melbourneuav

The Willow Garage team who are running the Robot Operating System (ROS) project posted today on the MAVLink integration with ROS that you've been reading about here for a while. What it means is that MAVLink-compatible autopilots (including ArduPilotMega now and the UAVDevBoard soon) can serve as ROS nodes, which will allow for easier multi-UAV mission control and coordination with other robot system.

From the post:

Users of Micro Air Vehicles (MAVs) will be happy to hear that the MAVLink developers have released software for ROS compatibility. MAVLink is a lightweight message transport used by more than five MAV autopilots and also offers support for two Ground Control Stations. This broad autopilot support allows ROS users to develop for multiple autopilot systems interchangeably. MAVLink also enables MAVs to be controlled from a distance: if you are out of wifi range, MAVLink can be used with radio modems to retain control up to 8 miles.

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.