Blogs

ROS-ArduPilotMega Integration

Posted by Ralph Castain on May 25, 2011 at 7:30am
3689408423?profile=originalPer a suggestion from Chris, I'm working on integrating APM with ROS so that APM looks like an ROS node. I'm a newbie with APM and Arduino, but experienced with robotics in general.

I've done the basics, getting the various IDE's running and proving the concept of outputting APM sensor readings as ROS topics.

What I'm seeking now is input from the community as to what we want this integration to provide. Any suggestions and/or requests would be most welcome!
E-mail me when people leave their comments –
Follow

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

Join diydrones

Comments

  • Ralph Castain May 28, 2011 at 1:30pm
    Ken: no code posted yet. Need to get the board mismatch solved first, figure out where this MAVLink code sits (since I can't find anything obviously labeled that in APM).

    Once I do get going, I'll post the link to the code.
  • Ralph Castain May 28, 2011 at 1:28pm

    Well, I've hit a snag - maybe one of you folks can help with a suggestion. I have my Mega 2560 board, and just received my "ArduPilotMega IMU Shield/OilPan Rev-H" - and the pins don't come close to matching. Board sizes are different as well, so I don't see how these two can mate, even though the DIY store links them.

     

    Any suggestions? Is the store simply linking together the wrong two things?

     

  • ken May 26, 2011 at 8:50pm
    Very exciting. I look forward to seeing it evolve. Do you have current code posted anywhere?
  • I Heart Robotics May 26, 2011 at 7:50pm

    I'm pretty busy at the moment so I am not sure how much code I can contribute. Also, I don't currently have an APM and I don't know what state the MAVLink interface is at. The APM MAVLink interface should be able to use most of the same messages to communicate with both qgroundcontrol and with ROS.

     

    Here is a rough outline of what I think the ROS/APM interface should provide

    APM <-- MAVLink (over serial or XBee) --> ROS


    Waypoints vs Active Control

      There should be support for ROS to send waypoints to the APM and for some applications there needs to be support to allow ROS to set the commanded roll, pitch, yaw and throttle. It may also be worth supporting direct access to the control surfaces.

      Control Modes

        OFF - Motors should be powered off and control surfaces in their default positions

        RADIO - The aircraft is being flown by a human operator on the ground

        WAYPOINT - The APM is in control and flying based on waypoints

        COMMAND - ROS sends the commanded roll, pitch, yaw and throttle to the APM

        DIRECT - ROS Sends the aileron, elevator, rudder and throttle positions [-1, 1]

     

    ROS Topics

      /apm/control/mode

        This should enumerate the current control mode

      /apm/gps/fix

        http://www.ros.org/doc/api/sensor_msgs/html/msg/NavSatFix.html

    /apm/height

        http://www.ros.org/doc/api/mav_msgs/html/msg/Height.html

      /apm/imu/raw

        Raw IMU data from the APM

        http://www.ros.org/doc/api/sensor_msgs/html/msg/Imu.html

      /apm/imu/filtered

        Filtered IMU data

        http://www.ros.org/doc/api/sensor_msgs/html/msg/Imu.html

      /apm/airspeed

    http://www.ros.org/doc/api/geometry_msgs/html/msg/TwistWithCovarian...  (maybe)

      /apm/control/state

        The current state of the control surfaces

      /apm/rc

        Radio Control inputs, useful for testing and co-operative tasks

    /apm/status

        Status (Battery, Motor Current, etc)

        http://www.ros.org/doc/api/power_msgs/html/msg/PowerReading.html  (may be useful)

    ROS Services

      /apm/set_control_mode

        Set APM control mode

      /apm/get_control_mode

        Get APM control mode

      /apm/set_waypoint

        Sets a waypoint via MAVLink

      /apm/get_waypoints

        Returns a list of waypoints

     

    Here are some ideas and usage cases to consider for ROS/APM integration

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

    ROS + APM + Kinect = Autonomous Landing system

    For this you to want to use the Kinect with PCL to locate the ground plane of the runway/landing pad, and perhaps use computer vision to extract lines on the runway.  A state machine in ROS should determine when landing is complete and power down the motors.

    Radio control takeoff -> fly waypoints -> automatic landing -> shutdown

     

    Aerial Mapping

    In this case you want to have the IMU and GPS information synched with image data and sent to OpenCV for processing. Using ROS here can help not only improve the inverse perspective mapping for image stitching, but the image data can also help improve the GPS position estimate and help determine the current windspeed.

     

    APM Swarm

    Here each APM will communicate over a XBee link with a ground station running ROS. A seperate ROS node will control the flight formation and send commands back to each aircraft via MAVLink. The great thing about this is that the code could be reused to control an underwater swarm as easily as a flying swarm.

     

    Most of this code should be fairly portable to any autopilot that supports MAVLink. I am sure I have forgotten something but hopefully this can help as a starting point.

  • Ralph Castain May 26, 2011 at 5:54pm

    Ralph: I can't speak to the ubuntu board - sounds like Garry is familiar with options.

     

    I'm still puzzled why there isn't a uSD card socket on the system. A Class 10, 8GByte card would resolve most size issues and consume very little power. It's simple to write a driver that would allow people to "swap" functions into the main cache for speed. Is there some reason this isn't available - or did I miss the option somewhere?

  • Ralph Castain May 26, 2011 at 5:49pm
    I Heart Robotics: I've wandered thru those links before, plus some others that are relevant. I agree that ROS isn't really setup for UAVs, but the interface might provide access to some useful plug-ins.

    My only real concern has been to find the right integration point. Putting ROS interface code at the individual sensor level seemed icky. I'm not familiar enough with AMP to know, but I gather people generally agree that this MAVLink interface is the best place. I can certainly look at it to assess any issues.

    Or I can turn this topic over to you, if you want to do it. No issues with me...I'm still digging thru code to learn what's where.
  • 3D Robotics
    Chris Anderson May 26, 2011 at 4:07pm
    I Heart Robotics: Many thanks for an awesome comment--that's super helpful. Would you be interested in working with Ralph on this implementation? We can give you devteam maillist access SVN access when you've got working code.
  • I Heart Robotics May 26, 2011 at 1:34am

    First, I wouldn't bother with Player since most if not all of the functionality has been replaced by ROS.

    Second, I would suggest working on improving the MAVLink interface to connect the data to ROS. This provides a common interface for the various autopilots to connect to ROS and makes the code more reusable between flight hardware.

     

    Here are some useful links for ROS+APM Ideas

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

    Parts of ROS run native on windows (with some work)

    http://www.iheartrobotics.com/2011/03/ros-on-windows.html

     

    ROSJava / Android Integration

    http://www.ros.org/news/2011/05/google-io-2011-cloud-robotics-ros-f...

     

    ROS on MAVs

    http://www.ros.org/news/2011/03/ros-on-mavs-with-mavlink.html

     

    Documentation for running ROS on an AscTec Pelican Quadrotor

    http://www.ros.org/wiki/Robots/AscTec

     

    In this video the quadrotor is doing 2D SLAM to build a 3D map

    https://www.youtube.com/watch?v=2gz_W6R_Qpc

     

    Here are some 3D robotics demos for ROS

    http://www.iheartrobotics.com/2011/04/playback-3d-robotics.html

    Keep in mind that most of these 3D systems have significant CPU requirements to achieve real-time performance.

     

    The GPS and outdoor navigation infrastructure in ROS is a work in progress, I am certain that contributions are appreciated.

    http://www.ros.org/wiki/gps_common

     

    The path planning and navigation systems for ROS are mostly designed for 2D robots.

    The Gazebo simulator for ROS works well for 2D robots but it does not model aerodynamics in a useful way.

    http://www.ros.org/wiki/simulator_gazebo

     

    Overall, I would focus on improving the MAVLink interface to allow for ROS to better communicate with the APM. Specifically I would create a ROS service to view or set waypoints by sending through MAVLink. The avionics sensor data should also go through MAVLink to the computer onboard or at the ground station before being broadcast as a topic to other ROS nodes.

  • Garry Qualls May 26, 2011 at 12:40am
    Ralph, you might want to take a look at the Beagleboard for a way to fly Ubuntu on a UAV. As I remember, the regular Beagleboards are about 2 grams heavier than a regular Arduino Mega. If you need more performance, sometimes you can find the Beagleboard-xM or the Pandaboard in stock. People run ROS on Beagleboards, so there are tutorials and files available on different web sites that can get you started.

    Chris Anderson posted about ROS-MAVLink-ArduPilot Mega integration and linked to the ROS package back in March, so people might want to take a look at that:

    http://diydrones.com/profiles/blogs/willow-garage-announces-ros

    Ralph Castain, I am also interested in publishing new waypoints to an APM using ROS. I guess my full wish list for ROS integration would be a) read/write APM waypoints using ROS b) have APM publish current state, including next waypoint c) send data from another GPS to the APM through ROS and d) send heading+alt+airspeed from another source into the APM through ROS. I'm guessing (a) and (b) can already be handled through ROS<->MAVLink package?
  • Ralph S. May 25, 2011 at 11:05pm
    It might be interesting to identify a lightweight, small, ubunto-enabled board to install on the UAV. This way any high level computations (e.g. SLAM) could be done onboard and the UAV could gain a lot of autonomy. (I'm just looking into doing this for a ground vehicle but with an probably too heavy, too much power consuming Atom-based board...)
This reply was deleted.