FCUs, ROS and standardising control of aerial systems

[Andrew Symington]

Dear All

So, I thought I'd try and kick off a thread on the tail-end of some good discussion at ROSCON, as well as last night's IROS reception. What I'm really interested in is loose standardisation of the way in which multicopters -- and maybe even other aerial platforms -- can be controlled from within a ROS context. In particular, I see aerial platforms as a combination of sensors, actuators and flight logic. The vision I have is to expose as much information as possible to the ROS world without compromising the stability / safety of the flight control unit.

Having never used MAVLink myself, I don't really know what kind of information flow or control topologies it supports. Perhaps somebody with greater experience may be able to comment on the proposal below, or suggest a better way of doing things. So, what I propose is the development of a ros_mavlink node, which binds to a MAVLink connection and interacts with the flight control unit to expose the platform as an abstract entity on a ROS backbone. In order to promote code reuse and allow new platforms to be efficiently added, by stadardising common sensors and actuators.

For example, a quadrotor running MAVLink may be exposed to the ROS world by ros_mavlink in the following way:

<formal interface>            : <message/service namespace>

hal_platform_quadrotor    : /hal/quadrotor/UAV0

- hal_actuator_motor        : /hal/quadrotor/UAV0/actuator/motor0/...

- hal_actuator_motor        : /hal/quadrotor/UAV0/actuator/motor1/...

- hal_actuator_motor        : /hal/quadrotor/UAV0/actuator/motor2/...

- hal_actuator_motor        : /hal/quadrotor/UAV0/actuator/motor3/...

- hal_sensor_imu              : /hal/quadrotor/UAV0/sensor/imu/...

- hal_sensor_barometric  : /hal/quadrotor/UAV0/sensor/barometric/...

- hal_sensor_gnss            : /hal/quadrotor/UAV0/sensor/gnss/...

- hal_sensor_magnetic     : /hal/quadrotor/UAV0/sensor/magnetic/...

Importantly, I'm not suggesting that any low-level control happens in the ROS-world, but rather the raw low level measurements get timestamped and forwarded up to the application layer in order to be used in more complex SLAM-type systems. This would avoid us having to nitpick through low-level code to awkwardly stream measurements up the control hierarchy, creating a world of timing issues to deal with.

The advantage with this approach is that we could have simulated entities expose themselves in a similar fashion, masking the complexity of the underlying implementation. This would mean that the high-level controlling code can interact with real or simulated AscTec, Mikrocopter and 3DR platforms in a similar way, assuming of course that they support MAVLink. This would allow us to create interesting hardware in the loop simulations.

I did a similar thing for the CRATES simulator and the AscTec Pelican platform. Feel free to have a look.

https://bitbucket.org/asymingt/crates/src/ae976a3786cdf5a16cd30c663a7ac3d40b21b841/src/?at=master

Anyway, this may be a pipe dream. Feel free to hijack this thread with your thoughts.

Cheers

Andrew

[Meier Lorenz]

Hi Andrew,

Great to talk here! We’re currently wrapping up the slides and some additional notes / proposals and will post here. We will likely need an interesting debate on exactly the topics you bring up (in an ideal world you would want to have each sensor separate, but it makes the number of topics explode to do just some very simple things, so I’m sure there will be controversy).

Cheers,
Lorenz

--
You received this message because you are subscribed to the Google Groups "ROS SIG Micro Air Vehicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mav...@googlegroups.com<mailto:ros-sig-mav...@googlegroups.com>.
To post to this group, send email to ros-s...@googlegroups.com<mailto:ros-s...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-mav/78b2476b-a765-44ab-8714-040bf150f160%40googlegroups.com<https://groups.google.com/d/msgid/ros-sig-mav/78b2476b-a765-44ab-8714-040bf150f160%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

[Tully Foote]

Hi Andrew and Lorenz, 

As we're getting started, I suggest that we collect static material on the wiki page for the sig: http://wiki.ros.org/sig/MicroAirVehicle  I've put up my slides there as well as started some structure. I'm sure it will evolve as we progress. 

Also it's great we've already got several people on the sig already. as we got cut off at the end of the IROS workshop. But we should think about where to advertise this to get people from as many relevant communities as possible. 

Tully

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mav...@googlegroups.com.
To post to this group, send email to ros-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-mav/19BAFE21-03C0-4125-AD50-A72E43267D38%40inf.ethz.ch.

[Hyon Lim]

Hi,

Is this group for generally discussing about MAV or specifically ROS with MAV?

Anyway, discussions on this forum might be useful in many aspects. 

-Hyon

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-mav/CAM7qi7ViMdR-STgfe8c-chicnO3wQKcq9uM8y1Yges1dOGWXBA%40mail.gmail.com.

[Víctor MV]

Hi everyone,

Thanks for pushing forward this initiative.

I collected some useful material in this GitBook over the last month. Also, we will soon release a publication on Linux autopilots that includes an analysis on the available ROS-ardupilot integration solutions.

To the best of my knowledge i'd say that the most promising package is mavros. 

Cheers,

Víctor.

[Tully Foote]

Hi Hyon, 

I think that the scope of this can be larger than just ROS integration. We should focus on working toward understanding how to abstract the systems as a whole and a way to integrate with ROS can fall out of that larger discussion. This is the design pattern we've followed with other ROS interfaces and I expect it can play out well in this domain too. 

I certainly hope that discussions here can be helpful for anyone working to interface with flying vehicles. And I encourage anyone with an interest in the interfaces to aerial vehicles to listen in and contribute even if they don't have ROS experience or plan to use ROS in their projects. Their contributions are still valuable for understanding the more general aspects required of the interfaces. 

Tully

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-mav/CAF9XkjA0yYK3F2YoxPdsmu9rPAR276ox-dDP%3DR1K4FFSGZwmKg%40mail.gmail.com.