@davecrawley You know I’m a fan of being able to position control as well, however, as has also been said by others, different control types are appropriate for different situations. Completely replacing velocity control is not likely to be appropriate.
@athackst @tfoote @smac It appears we’re in agreement that some way of expressing the constraints is important, and I think that @smac’s suggestion of adding a type field and @tfoote’s suggestion of adding constraints are both useful, in that they address different parts of the problem. A constraint model would obviously be very powerful help for controllers, while a type field can be useful for tools as well, to know which fields to work on, without having to understand a full constraint model.
A constraint model would also solve an issue I had with type fields: You need to take care to check the field, and individual driver writers can easily forget that, or make mistakes. If you have an explicit constraint model, you can have a general library that checks the constraints, which everybody just uses as a filter in their code (or even as an explicit filter node in the architecture). This also makes checking more advanced constraints feasible.
Just from the top of my head, I would say it would be useful to have:
- velocity constraints, of course
- acceleration constraints, maybe as a set of “preferred” and “possible” (the latter could be useful to communicate what kind of deceleration would be possible for a crash stop, for example, whereas the former would be what we should use in normal situations)
- binary motion constraints (can move in the direction of some axis or not)
- control rate, maybe?
- control delay (how long it takes for the robot to react to a command, once received)
I’ve had a look at REP147, and it’s confusing me a bit. In the section “Rate Interface”, they first write “The message to send a velocity command is geometry_msgs/TwistStamped”, and then they say “The command is a body relative set of accelerations in linear and angular space” (my emphasis). In general, I would advise against calling a message that communicates accelerations “Twist”, because AFAIK the term is generally defined for velocities in screw theory.
btw, I do know that at least in some autonomous driving applications, the low-level interface is in terms of accelerations, but in others it is in velocities. I would suggest we stick with velocities for now, since that seems to what most people are using. We can always have a second discussion later on (or in parallel) about other interfaces.
As a final note, I also like @tfoote’s architectural sketch, and agree that it would be useful to have more concrete messages for the mixer step. This would be at least level below what we’re currently discussing, right?