ROS MAV SIG Call for Participation

[Meier Lorenz]

Hi All,

Thanks for joining ros-sig-mav. From the call for participation below our goal is to develop a standard set of messages which can form the basis for interoperability between different MAV projects. To the end our current proposal is to start with some existing messages widely used in MAVLink and review them for potentially more use cases.

Markus and I have started with the MAVLink messages and have put together a proposed set of messages. A link to the message set draft is available on the ROS SIG wiki page or here directly.  Please take a look at these messages and give feedback. Are there other messages you’d like to see, changes you’d like to see? We intentionally only added the messages we felt most relevant, and we’re looking forward for others to contribute what they feel should be in there as well.

Our goal is to develop a consensus on what the messages should be. Along the way it maybe be useful to work up a rubric of use cases expected to be supported. There are already many different SIGs and they all have their own personallity. For more information and an overview of other SIGs see the SIG landing page.

Looking forward to your contributions, and please feel free to directly post into this thread!

Lorenz Meier (ETHZ / CVG, PX4), Markus Achtelik (ETHZ / ASL), Tully Foote (OSRF).

-----

CALL FOR PARTICIPATION

Drone Developers,

As drones are entering more complex applications and topics like flight in GPS denied environments, the complexity of the involved systems is literally exploding. Aerial robotics has been a very active field in academia in the last decade, and the academic community has converged on using ROS, the Robot Operating System, as its base platform. ROS is not a classic operating system, but a layer of middleware and tools that typically sits on top of Linux. It provides facilities like multi-process message passing, logging, visualization (RVis), simulation (Gazebo) and other core infrastructure that is hard to build and and maintain, but essential for any robotics problem.

While ROS is the de-facto standard in aerial robotics, the individually contributed stacks do not always use the same interface definitions in how they exchange data like desired trajectories or current sensor values.

We’d like to invite you to participate in an effort to develop a standard set of messages for communicating with and between MicroAirVehicles (MAVs). At the IROS workshop on MAV’s (proceedings) this fall it was identified that the MAV community has many different implementations of the same capabilities. They are often all closely related and are almost compatible but rarely is it easy to switch between different implementations, or use different implementations together. From that discussion it was proposed to work toward building up a common way to communicate and enable the MAV community to collaborate most effectively.

To make this happen we have setup a mailinglist and wiki pages to be a place to coordinate this effort (MAV SIG, mailing list). If you are interested in this topic we ask that you join, listen and participate so that we can get as broad a spectrum of voices as possible.

We have chosen the ROS SIG format as it has proven effective at developing standard messages which are used by many people every day. ROS SIG’s are relatively unstructured and allow adaptation for differences in each community and process.

Having common datatypes will allow us to have better modularity and interoperability. As an example from the ROS ecosystem, there are 10+ different laser scanner drivers in the ROS ecosystem and 18+ different camera drivers (ROS sensors). Because these drivers all use a standard set of messages a user of those sensors can switch which sensor they are using on their system.

If you would like to know more please check out the MAV SIG. If you’re at all interested please join the process. We’ve started a thread at HERE to kick off the process.

[Jasper Pons]

I think this is great, two years ago we considered building our indoor robot on ROS and/or MAV but decided that those infrastructures only provided 50% of what we needed: not worth it for the burden of overhead they added, so we built our own lean protocol and platform.

 

I think someone to pull it all together, and drive the technology in a certain direction is definitely needed and we will support in whatever way possible. We are even open to changing our platform completely if we can find a partner to provide the technical expertise.

 

Our system is designed with the philosophy of "B.Y.O.D." (Bring your own drone), not being dependant on any drone platform , rather integrating into existing platforms and it would be very attractive to to us to see support for  this scenario  weaved into the proposed protocols. That way we can hand over navigation, sensors and obstacle avoidance to the device that is purpose built to do that, we can concentrate on our specific data collection tasks , not worrying about the finer points of motion control.

 Adopting a BYOD approach would allow us to keep using our existing Arduino based hardware and the effort we have put into our own software and protocols to the base station, just by using the agreed protocol.

The communications protocol would be the interface between our controller and the robot.  From what we could see, MAV  is designed around GPS and waypoint navigation . The time is ready for a new type of navigation designed for indoor use and the protocols to support it.

Regarding your approach , we would recommend having a clearly defined goal of what you are trying to accomplish, or else you are going to  get sidetracked like so many other protocols. "To develop a ROS protocol" is not really a goal, it is how you are going to accomplish your goal. A goal would be something like : "to provide a means to control a robotic device in an indoor environment through the use of commands, data gathering, ..."  etc etc  . if you say it like that then we all know what you are trying to accomplish and we are more likely to want to be involved.

We think that having "Linux" as part of your mission statement detracts from what you are doing and initially put us off any involvement. We think that what you are attempting to do is so much bigger than any one operating system and shouldn't limit itself in that way.

King Regards

Jasper

[Meier Lorenz]

Jasper,

Thanks for posting. I'm not sure what I should draw from your post - you seem to reference a different discussion (inline comments?), nor does your reply seem to comment in any fashion on the message spec itself. Could you clarify the point you were trying to make?

-Lorenz

[Jasper Pons]

Hello Lorenz, I am responding to an article titled "Call for Participation on ROS MAV SIG" that was posted on the PX4 users forum, there were links in that article inviting people to participate in the discussion and to subscribe to the mailing list. I presumed this was the correct forum to participate in the discussion at a high level.

Appologies if this post is out of place, not relevant or misleading, if so please delete it.

--
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG Micro Air Vehicle" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-sig-mav/Mbjm_wZM9WE/unsubscribe.
To unsubscribe from this group and all its topics, 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/b24ae97f-5cbd-45af-a1e5-d47eabd8c5e2%40googlegroups.com.

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

[Tully Foote]

Hi Jasper, 

This is the right place to for the discussion. 

I agree that the goal of this project is bigger than any specific OS or framework. From the announcement I'd take the key mission of the effort as "We’d like to invite you to participate in an effort to develop a standard set of messages for communicating with and between MicroAirVehicles (MAVs). " 

Although Lorenz did mention linux as the most common way to use ROS in his Call for participation on the px4 users post (https://groups.google.com/forum/#!topic/px4users/mt-fxqaMZ2M) our main goal of this effort is to develop standard messages for which different systems can communicate. If we have shared datatypes modules from different implementations can be made to work together much more easily. 

I'll also point out that that ROS is not tied to linux. If you would like to integrate ROS with an arduino you can use rosserial (http://wiki.ros.org/rosserial) And our efforts here are not tied to ROS, we just plan to use the ROS representation as it provides a convenient representation which is commonly used and has interfaces in many languages including (C++, Python, Lisp, C, Matlab, Ruby, ...)  and has lots of tools and infrastructure which are already in use and can provide connection to other automated/robotic systems. 

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/CAHx4p96pKmDndyciKyk_MixU9kFnvL%3DXS3HYV%3DfzhqGhhA3-JQ%40mail.gmail.com.

[George ZP]

Having built a full-fledged simulation environment for fixed-wing UAVs in ROS/rviz, I needed to come up with .msg formats to let my various nodes communicate with each other.
Here are a few examples:

#UAV States
Header header
Geoid geoid
geometry_msgs/Pose pose #NED
geometry_msgs/Twist velocity #body
Accelerations acceleration #body
float64[] rotorspeed #in rad/s

# Geoid - Describe position/velocity on the geoid
float64 EARTH_radius = 6378137.0
float64 EARTH_flattening = 0.003352811
float64 EARTH_Omega = 7.292115e-5
float64 EARTH_grav = 9.7803267714
float64 latitude
float64 longitude
float64 altitude
geometry_msgs/Vector3 velocity #in m/s

# Accelerations
geometry_msgs/Vector3 linear #in m/s
geometry_msgs/Vector3 angular #in rad/s

# Environment
Header header
geometry_msgs/Vector3 wind #body in m/s
float64 density #in kg/m^3
float64 pressure #in mBar
float64 temperature #in Kelvin
float64 gravity #in m/s^2

These .msg formats where initially built for use between the simulator nodes, but if sensors or observers are available, they can populate these messages and post them to autopilot or visualizer nodes. I know that they are bloated as of now, they are for internal/personal use so far.

I bet a closer integration with MAVLINK would be beneficial, but I just started dabbling with mavros, so I can't say much about it yet.

Thanks for starting this discussion!