/status Vehicle status (msg type not specifiied or exist yet)
Flight mode (not specified, maybe in combo with a set-flightmode)
And ofcourse there is also the MAVros package as well that have been ported to ROS2, however, I am assuming that those have specified msgs for MAVlink that will need to be converted before integrating it with other packages. The goal eventually is to have some form of standardization somewhere.
So my questions are:
From the proposed REP 147, last updated in 2018, is there any messages you feel that are missing?
What is the role in MAVlink in this, would it make sense to expose all message like that in ROS?
Is there any message interfaces from other staple packages that we can reuse for better integration?
@KimMcG IMHO, REP-0147 is quite outdated and was defined when drones were starting to fly. A lot of it comes from the mav_msgs defined by the Autonomous Systems Lab at ETH Zurich. Therefore, I am not sure if I feel comfortable moving forward with “what we have”, where “now” would be a good opportunity for us to identify what the requirements are and what we want to achieve for the standardization.
I have a few comments from the top of my head regarding the messages mentioned above
What would be the goal/scope of the message interface standard? The messages that are defined are message types, and do not necessarily specify the outcome of the message(or topic names). Do we want systems to be compatible by defining these messages? If so, we need to also specify behavior of the vehicle from these messages.
There is no discussion regarding coordinate frames. We do have a frame_id here and there at different places of messages, but I think there is a need to have at least some convention of coordinate frames.
A lot of aerial robots that fly outside of the lab make use of geospatial coordinates. However, this doesn’t seem to be taken into account in the messaging stack. For example, it is quite common for the local origin to be reset depending on the state of the state estimate of the vehicle. However most of the standards in REP-0147 assumes you are on a static local cartesian coordinate which is quite unrealistic for real vehicles.
You have absolutely some good points. Mind that many in the REP-0147 proposed messages weren’t implemented even or in a different form. and the mav_msgs has not yet been ported to ROS2 so we definitely have freedom to ‘start again’ and redefine all from a more logical starting position.
In terms of coordinate frames, is that what we can use TF transforms for? That is the standard for other ROS vehicles.
And I don’t think the local cartesian coordinates are completely unrealistic as there are quite some labs fly indoors with a mocap system (perhaps with smaller aircrafts), and perhaps for the intention to fly outside, but you are absolutely right that it needs to support geospatial coordinates. So there needs to be support for both indoor and outdoor drones.
Thanks for your insights! I’ll incorperate this in the discussion prep for and I hope you are able to join the meeting
Hi @KimMcG@Jaeyoung-Lim We have been struggling a lot with the different control modes that can be used to control an MAV and the different coordinate systems that are used for each mode. For example, we can have velocity commands in the global frame (ENU) or in the local frame (FLU) or a mixed control mode where we command velocity in the x and y coordinates and give a set point for height (z coordinate).
Having a comprehensive way to handle all these possibilities in an “easy” way is something we find very difficult and REP-0147 does not cover anything related to this.
I think that this more a case using transforms and transition in that like @tfoote mentioned in the meeting. Is that something you’d be able to use in Aerostack2 in the way that you’d like as described in REP 105?
Yes, we take advantage of the transformations of the TF tree for handling the conversions, but I was refering more to the different modes that can be handled and some services or topics maybe for changing it or for knowing in which mode the UAV is operating. In Aerostack2 we have our topics and messages regarding this because there is nothing related on the REP.
Ah like that. Yeah that seems to be a bit more complicated especially with mixed setpoints like absolute height and body fixed horizontal commands… that is a very good point!
I don’t know myself about this either except for making a separate service/msg for each of them… that is not ideal indeed.
An update - I’ve been working in NAV2 to get it optionally to support ROS REP-147’s recommended TwistStamped for velocity control, which would replace the current Twist implementation.
I have a related pull request in NAV2 to start the transition to allow using TwistStamped, and it will be backward-compatible for humble through the use of a parameter.
I guess that there will be some compatibility issues with other people integrating with the NAV2 packages but I’m sure that you and Steve can figure that one out. The ability to turn it on or off with a parameter seems like a proper choice, although I guess the question of when to change ‘the default value’ of that switching parameter are perhaps design questions. About the message itself It seems like the logical choice to have those timestamped for sure so in terms of that I would most definitely agree.
This is the pull request you are referring to right? It seems to be in draft, do you need any help with this or is it still in process?
Thanks Kim. My initial plan, assuming I can get PR’s in to gazebo, rviz and the other tools, is to switch the default for J-turtle. Humble and Iron need to stay the same, at least from what I’ve heard about not having breaking changes within the release.
As far as the draft PR, everything is going well! Pedro and I are getting through all the changes and have been iterating on some backports to Humble to test it with ArduPilot. We’ll likely need help getting PR’s in to the rest of the ecosystem. If you are interested in helping, let me know!
Yes of course. Ofcourse that depends on the expertise I can offer
I was also thinking about the meetings itself, to have a special notice of the work done in this area, and perhaps that we can already start some kind of sub-comity or sub-working group on these message standards. Such that we can already start coordinating on this? What do you think?
What about establishing minimal standards for aerial platform interfaces? In the case of Aerostack2, we work with multiple platforms (PX4, DJI, Crazyflie), and we have observed the necessity to develop our own drivers to create a common interface across all platforms. A positive initiative could involve defining a minimal set of topics and services that can be shared among different platforms, simplifying the process of transitioning between them. While it is acknowledged that each platform may have additional capabilities not covered in this set, I believe this presents an excellent opportunity for developers to explore different platforms with minimal overhead in their current systems.
This interface is designed to promote interoperability and reusability of core functionality between diverse aerial vehicles. By leveraging the interfaces defined in this REP we both tools and libraries can be designed to be reusable between different frameworks and vehicles. It is expected that aerial vehicles can and will implement additional interfaces in addition to these core interfaces.
It’s likely if a few of the commonly used aerial frameworks adopt the REP and use the message recommendations, it could be changed from DRAFT to APPROVED state.
If there are specific changes to REP-147 you think are needed, I’m happy to discuss them here or in a pull request. I have already gotten some minimal changes into the REP. Since the waypoint missions are quite out of date, I know that needs to be updated, but the low level controls and sensor data reporting are working great in ArduPilot.
either everyone agrees with the proposed interfaces, or its difficult to wrap your head around it
