Standard aerial_msgs design proposal

[Tully Foote]

Hi Everyone,

Thanks for all your input so far. We've had many comments in the google doc. I'd like to bring the discussion back here to the mailing list for better visibility.

After some discussions with Lorenz, I've tried to put together the minimal API for which I think that can provide the basic functionality and let higher level functionality build from there.

To start out I'd like to propose an extension to REP 105 which will define an earth frame as a parent to the map frame: https://github.com/ros-infrastructure/rep/pull/103 This will build toward allowing multiple robots in outdoor environments to operate in cartesian spaces, yet also share data between their maps. This will provide a mechanism for vehicles to initialize without global localization and operate in their "map" frame. And like we do for localization in the map frame we can use global localization estimates to establish the offset from the map frame to the earth frame.

By using the standard REP 105 structure we can continue to use the standard base_link feedback of odometry via the /odom topic and Odometry message as well as broadcasting the /odom frame into tf.

It was flagged that for dynamic flying acceleration is important to have in odometry for feed forward so we may want to consider adding a parallel Odometry message with acceleration included. For backwards compatibility it should probably be a parallel message with extra info.

For sending low level commands /cmd_vel is not adequate for a dynamic system. However the interface of MultiDOFTrajectory covers the existing use cases and has already been developed for free space trajectory communications. This will use  MultiDOFTrajectory using MultiDOFTrajectoryPoint  This will provides local temporal authority as well as standard moveit compatible interface.

For feedback I think that there are several preexisting messages which we can also reuse:

Report NavSatFix and NavSatStatus

Report AttitudeandHeading (ongoing discussion on ROS Sig Drivers)

Report standard diagnostics

Battery promote mavros/Battery

• Add nominal voltage?

• Chemistry enum?

• internal resistance

• Newer batteries are smart we could also promote: linux_hardware/LaptopChargeStatus instead
  

SafteyFence use geographic_msgs/BoundingBox array

• Possibly add a spherical or cylindrical primitives?

The above provides a low level interface. For higher level behaviors we can have  modules which output the low level commands and take in the higher level commands. Examples:

• Loiter

• A basic trajectory generator which outputs a circle trajectory. Can be parametrized etc,

• RTL

• A controller which will produce climb, traverse and land trajectories. Possibly by composing/switching on other controllers for the specific flight regimes.

• Altitude Hold

• Take /cmd_vel or similar command, and produce trajectories which filter out the altitude changes

• Guided Mode

• Take in /cmd_vel from joystick, produce command trajectory to a moving set point.

• Direct Teleop

• Take in /cmd_vel from joystic, produce a trajectory following their commanded velocities.

• Land/Tackoff

• Take a parametrized land//takeoff command. Produce a trajectory following the parameters, using feedback on ground height etc if available to update/iterate.

There are a few more additional standard interfaces we should define. However I have not fully fleshed them out. But with some testing I think they should relatively easily define themselves and they are relatively specific to aerial vehicles so I don't think they are candidates for reuse.

A service to arm and disarm flight mode.

A service to check the status of flight mode.
For error recovery and recognition I propose to create a standard set of error messages for aerial vehicles similar to what's in sys.status. Probably a bitfield size 64 for now.

This is a very early draft and we are definitely going to need to try these things out and iterate many times to get to a good solution.

What are people's thoughts? Did I miss anything major in pulling together the notes in the document?

I realize that we covered a lot more in the document and I don't think that this should be the only messages used in aerial vehicles but I'm trying to focus on building the core API which can provide the baseline for other applications.

Tully

[Vladimir Ermakov]

Hello,

About battery status, now there also exist message with per cell monitoring (BATTERY_STATUS), but
widely used monitors only provide current and voltage data. Maybe smart batteries from new 3dr copter may provide detailed data.
Current BatteryStatus.msg is a just part of SYSTEM_STATUS message.

Split IMU and support for NED frame would be nice (REP145, but it should cover not just IMU).
Also now safety_area plugin is useless (no FCU support), so better fence are welcome.

And Mavlink.msg (whole packet data) should be in one place, now there copies in old ros node, mavros and others.

среда, 10 июня 2015 г., 20:39:07 UTC+3 пользователь Tully Foote написал:

[Hugo Boyer]

Hi Tully,

I think it would be nice to have a polyline with height (and maybe even a floor) for the geo fencing, in addition to primitives.

Hugo

[Tully Foote]

Hi Vladimir,

The multi-cell capability does sound like something that might be good for future batteries, with a form of fallback behavior for batteries which cannot support that level of detail.

Can youexplain a little bit more what you mean by splitting the IMU and NED frame means?

Hugo,

Your thought is a horizontally oriented prism with a polyline defining the perimeter and the floor and ceiling defined as flat surfaces?

Tully

--
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.
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/26001468-49fc-4fa3-90ea-bea7cdc2abf3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Vladimir Ermakov]

Hi Tully,

So for multi-cell monitoring there may be optional fields in message.

There two proposed changes i seen in ros lists and github:
1) splitting sensor_msgs/IMU: currently imu message constructed from two mavlink messages, and seems that split is similar that proposed somewhere in ros-sig-drivers

2) support for NED frames: now mavros does convertions for NED-ENU, but seems that sometime i wrong in suggestions and proposed conversion method are wrong (issue #49 haunts me :)). If i provide raw data, but with right frame information then user can setup needed message filter if they need it.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-mav/CAM7qi7WGFnGJ%3DwWN20wXoY5zKH%2B4BA_kZDjGa4YZmTwdsrA9OA%40mail.gmail.com.

[Víctor MV]

Thanks Tully for pushing this forward.

Agreeing with Vladimir, "mavlink.msg" should be placed in a single place. Having it in "aerial_msgs" would make sense for me. A few comments that pop into my mind:

• How about adding an "aerial vehicle type" message (e.g. mav_type.msg)? MAVLink compatible vehicles will get this from MAV_TYPE but i'm sure many other non-MAVLink vehicles will need this information.
  
• I probably need to do some reading about trajectory planning using ROS. From your changes in rep 105 I understand that the "earth" reference frame would allow MAVs with GPS to create trajectories. Would you mind walking me through this process and how would you create  MultiDOFTrajectory with the information from NavSatFix?
• In the higher level commands proposed above i'd highlight the importance of having a  "Guided" mode that is responsive to "/cmd_vel" from a joystick (already mentioned by Tully). APM's GUIDED mode does not allow this and it's really troublesome for outdoor testing when no GPS is used. We've hacked the mode to allow it but It'll be great to have a proper Guided considering this from the very beginning.

[Tully Foote]

On Mon, Jun 15, 2015 at 4:31 AM, Víctor MV <v.may...@gmail.com> wrote:

Thanks Tully for pushing this forward.

Agreeing with Vladimir, "mavlink.msg" should be placed in a single place. Having it in "aerial_msgs" would make sense for me. A few comments that pop into my mind:

• How about adding an "aerial vehicle type" message (e.g. mav_type.msg)? MAVLink compatible vehicles will get this from MAV_TYPE but i'm sure many other non-MAVLink vehicles will need this information.
  

A vehicle type is an interesting datatype. I think that just the vehicle type is not hugely useful, there are a lot of heuristics and other guesses which can be made from the vehicle type, but I'd like to see those enumerated and see if there's actually more concrete datatypes which might be useful such as characterizations of the flight envelope etc.

 

• I probably need to do some reading about trajectory planning using ROS. From your changes in rep 105 I understand that the "earth" reference frame would allow MAVs with GPS to create trajectories. Would you mind walking me through this process and how would you create  MultiDOFTrajectory with the information from NavSatFix?

 Typically a MultiDOFTrajectory will come as the output of a path planner. MoveIt is a framework which provides many planners which are compatible with this. If you just want to have a very simple "planner" which does straight lines between waypoints, the "planner" would take the points from NavSatFix, transform them into the cartesian space, and then interpolate along the line to produce a trajectory. Or even simpler have a 1 point trajectory which is the goal.

• In the higher level commands proposed above i'd highlight the importance of having a  "Guided" mode that is responsive to "/cmd_vel" from a joystick (already mentioned by Tully). APM's GUIDED mode does not allow this and it's really troublesome for outdoor testing when no GPS is used. We've hacked the mode to allow it but It'll be great to have a proper Guided considering this from the very beginning. 

There two proposed changes i seen in ros lists and github:

1) splitting sensor_msgs/IMU: currently imu message constructed from two mavlink messages, and seems that split is similar that proposed somewhere in ros-sig-drivers

Yes, we should follow up on REP 145's proposal and discussion here: https://groups.google.com/forum/?hl=en#!topic/ros-sig-drivers/2NvgNBOjcFQ

 

2) support for NED frames: now mavros does convertions for NED-ENU, but seems that sometime i wrong in suggestions and proposed conversion method are wrong (issue #49 haunts me :)). If i provide raw data, but with right frame information then user can setup needed message filter if they need it.

Yeah, I wrote the tf library back in the day, because I'd watched coordinate frames be one of the biggest pains on several of my previous projects. They are simple but are so very easy to screw up in important but often imperceptible ways.

 

--
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.
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/251433ff-30f3-428a-9bd0-93e6635dcfe5%40googlegroups.com.

[Shawn Schaerer]

Has there been any updates to this or a github repo with prototype code?

Thanks

[Tully Foote]

Hi Shawn, 

Thanks for the ping. 

Everyone,

I've just finished a draft of my slides to be presented at ELC on "Developing a Standard Interface for Drones" and I've tried to write the process up as well as a proposal. 

There are a few slides early on not filled out and the graphics could use some polish. But if you jump to the end you can see my suggested interface. It's an informed strawman but I want to use it to kickstart our discussions again.

I'd appreciate if anyone has comments to please add them to the document: https://docs.google.com/presentation/d/1hVZ2zm45ohjGl3NF0TSkGA4T7ytlW6XudbiwYip5Bws/edit?usp=sharing

I'll try to take them into account and evolve it based on feedback. 

Tully

--
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.
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/3d238f63-38ac-4422-a816-5e079d16e1b6%40googlegroups.com.

[Achtelik Markus]

Hi all, 

Thanks for the ping, too! And Tully, thanks a lot for preparing the presentation!

I made a few comments there directly. 

Best, Markus 

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