I think what we’re discussing is to potentially create a new Twist message for use of what Twist is used for now. I don’t think the actual Twist message itself would be modified or directly removed, a new one would be made and replaced, to be clear. I don’t want to give off that impression.
To me, that’s the thing to be absolutely avoided. To go down the line of thinking: now someone has an omnidirectional base, and creates new messages and modifies their local planners to use it. Then someone else as a XYZ base and needs ABC new message for their awesome-local-planner. Now we have a fragmented ecosystem where nothing talks to each other properly without adapters everywhere or having loss of information. There’s no end of base configurations and its a slippery slope that could have unintended consequences. Most local planners in the mobile space can create permissible differential and omnidirectional velocity commands. A few can also make permissible ackermann commands. This is going to get real complex, real fast. I’d advocate for a new message, but I don’t want the creation of a series of messages from my viewpoint. Ackermann is not somehow particularly “special” over the other types of base commands that it requires something unique that separates it massively.
Publishing multiple topics for “whoever might be listening” seems more of a hack to me than sending the hardware interfaces rigid-body velocity commands. Not saying that’s not a viable alternative, it just feels “icky” to me.
The impression I had from control_msgs is that its more suited to sending actuator-level commands, not robot-level commands (where a robot might have 2-N actuators in concert). Do you think that that would be the appropriate place for this? It seems to me a new message, if we deem it necessary, would live in something like a trajectory_msgs or similar since that seems sufficiently robot-level abstracted.
@davecrawley I think we’re having a slightly different discussion. We’re discussing the representation of targets going into the client node of the robot (e.g. my autonomous stack says the target of my robot is to do X) for which the client node robot_base_node may transmit over its connection to the robot base/controller whatever it likes. That can be your position space if you choose, or some derivative of the velocity / torque space. I don’t know of any local or global planners where the output would be sensibly “go X forward” and be sufficiently smooth as to track your targets effectively.
Agreed- and I don’t know how typical that is. I can say from my experience I haven’t run across one. There’s been safety mechanisms that will convert and project velocity commands into the future to understand and stop collisions, but I’ve never sent commands to a motor like “go forward X cm”.
Below is off topic but related:
We have odometry and you should be aware of the acceleration characteristics of your robot. It is important to create a smooth acceleration space velocity command to ensure that you’re not grinding gears and having smooth motion. That’s part of the responsibility on your base_node or using a smoothing technique.
What you described is the canonical form of closed loop control. Which is critical for accurately tracking targets in the presence of disturbances, changes in friction, wheels not quite straight, new actors in the scene, etc. I don’t know that you could create a safe system without periodically checking sensors readings. The formulation I’m familiar with in academia work is cascade control systems which this aligns with.
