Hi,
Well what I don’t want to do is get defensive about this but I think we have starkly opposing thoughts on this topic. I’ll outline my thoughts in respect to your comments, but this seems like a discussion to be had with a wider and engaged audience from across the mobile robotics community.
So something as the “host machine” interface to the hardware (the program which takes ROS commands and sends them over the wire to some microcontroller driving the base or something). Ok, not what I think of as low-level, but good to have a common definition to work with.
In this case, this is typically running on the host machine (main CPU) which probably has some power behind it. Even in the case of limited-resource processors, if its running ROS and able to fuse sensors and output some message for a command, its going to be powerful enough that the extra few bytes of a Twist message aren’t important. I thought the argument you were trying to make was if you had ROS messages going over the wire itself, which extra fields could be not ideal.
Even in that case, your example is oversimplified. While some applications can get away with just velocity commands, in practice, you probably need other fields like torque characteristics and time-out durations, etc for an industrial application. So dropping Twist to 2 numbers as the rationale for professional applications that require this level of optimization to create a new message seems tongue in cheek to make a point.
Lets say that a different way then. For instance you have a controller, lets say a DWA, Lattice, sampling, etc controller. Many types of controllers exist, but these are common ones to analyze. Many of these controller require some profile of motion (how much can it turn, how fast, etc). These controllers can be trivially reconfigured to support differential and omni-directional platforms with about 3 parameter changes running the same code. In some cases, like TEB, they can even generalize to car-like robots. So what you propose if a controller were to publish at TRV message is that controllers which algorithmically can support 2-3 different robot base types should have unique and different messages for each? That doesn’t seem right.
Having multiple message types, TRV, TAV, TOV, makes now these controllers no longer swappable to other applications easily. A big, big reason the ROS ecosystem is so active is that we give people the ability to trivially swap out capabilities using common interfaces like geometry_msgs/Twist and plugin interfaces. You don’t like this controller, use that controller. And there are plenty of controllers to choose from, though once you get super-serious on an industrial setting, you may choose to create your own. However, I can say from first-hand experience consulting and third-hand experience from robotics companies, that many robotics companies do use controllers like TEB in production, today. Including large heavy machinery outdoors, in warehouses, and in human-centric environments.
I think that comes from your anecdotal experience as a professional ROS user and developer. I agree for people like us that’s not prohibitively hard, but if every controller, in every package, across the ecosystem used a different message format and these weren’t able to be cross-used easily, where would we be today? If as a user, nothing worked well out of the box and I had to made adapters on top of adapters to get a basic demo working, I wouldn’t bother. We have these conventions of how we represent types of data so that we can built toolchains that are hardware invariant to process or work with data. If you think Twist is insufficient, I can probably come up with 20 other places outside the controller and hardware driver that you would need to fork and modify to support your specific message format to have work including things like:
- robot_localization
- some of the SLAM libraries
- Gazebo/Ignition
- RVIZ (with certain plugins), etc.
So now, you don’t just own your custom message, you’re now forking gazebo_ros_pkgs, slam_karto, robot_localization, maybe some rviz stuff, just off the top of my head. If we didn’t have a convention around pointcloud data, where would we be in depth processing capabilities? Is it a perfect message? Absolutely not. But its the inperfection we agreed upon to build capabilities on top of that are as flexible as possible to enable the design intent of ROS for highly configurable systems.
In reality, if you need a 3D perception system because you’re working with a large mobile or mobile-manipulator task (with an omnidirectional base), there’s not a huge reason that your local trajectory following methods can’t also be run on a drone. This isn’t a strong argument I want to focus on though, that’s was just illustrative.
I agree that this is not ideal. However, it is the current minimum-viable solution for standardizing the way we build systems and toolsets to support them. I would argue though, that if you know that this message is used, it would be part of a designer creating a fault-tolerant system to make sure it handles it in the ideal way for your application. Throw exceptions, log, ignore, etc. I’d assert that you should be able to handle faults in a clean way in a robotics application and this is no different, though self-imposed vs something you can’t help like sensor data being messy or issues with connectivity. Having some standard REP about what to do in this situation would have value. My personal suggestion would be to throw exceptions because if that’s happening, there’s clearly something terribly wrong.
I think you’re taking their words out of context. See block of text copy-pasted from that link below:
Some command interfaces (such as the stage simulator in car-like mode) require a geometry_msgs/Twist, but with changed semantics. The angular velocity ( z -axis) is interpreted as steering angle. Note, changing the semantics of a message is not preferred in general, better switch to the ackermann_msgs interface if possible.
Its clear to me that this is in discussion about Ackermann robot support, not the general representation of Twist for most types of robots that run TEB. The author of this system doesn’t use Ackermann type robots so its not a shocker that there’s not been more work to try to support it natively because it doesn’t have utility and the conversion process is a trivial mathematical operation based on robot characteristics.
That may be part of your issue - there are plenty of robotics companies using ROS that have car-like vehicles. And more are coming to market daily with delivery robots and other robots that require to break out of the 2D-planar clean environment differential and omnidirectional robots shine. They may be using Ackermann messages, but I would put money on it that alot of them are using TEB or some MPC that gives out a body-frame 3DOF target state and they’re being converted into Ackermann steering messages no differently than the script above.
I don’t think too many folks (though there are some) that use move_base out of the box. But there are a variety of move_base-like projects such as Move Base Flex and Robot Navigation that are used in production by thousands of robots globally by the likes of Magazino and Locus Robotics. I’d also put money on it they use Twist for the reasons mentioned above unless they’d like to create a ton of existing infrastructure in-house for little if any value add to their customers. Keeping in mind ROS2 is around, the Navigation2 stack is targeted at production robotics applications. I want to see the mobile and manipulation ecosystems in ROS2 mature to a point that they are viable commercial solutions. There have been great strides to that end and we’re not too far off from it.
Phew that was alot. Now here’s my thoughts that aren’t just counter-points. I’m all for having a discussion about a new message format to describe control efforts to a base Twist2 or whatever, but that should be then a discussion and not an assertion by making use of a custom message in one corner of the community without consulting the others that this directly impacts. If there’s a legitimate concern, we should have a proper discussion about it, weighing trade offs, and coming to some resolution in the form of an REP. I’m all for a new format, especially in ROS2 where we have more ability to change things since we’re not EOLing it in a few years. But that should be a larger and informed decision.
Maybe we do something like in the Image or Pointcloud2 message where we have some data embedded field and some metadata around what is supplied in it. That way you get fewer bytes and we don’t break compatibility, though requiring a whole-lot of rework across the ecosystem.