Is "Twist" (still) a good velocity command interface

Next Generation ROS
22

@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?

2 Likes
23

I also like having a constraint model as opposed to a type field.

I imagine there are two main types of constraints that any planner cares about:

  1. kinematic and other hardware-related constraints (max possible accel, axis of possible actuation, max curvature, etc)

  2. behavior constraints/costs (ie software limiting of max velocity, acceleration, jerk, etc) which may change over time like when in different modes or domains.

Since we are discussing the interface between a “higher” level controller and the “lower” level actuation, I’m going to assume that it’s only the kinematic/hardware constraints that are relevant. In your example, I would say that a “preferred” acceleration belongs in a behavior constraint list.

So a couple of questions that pop out are:

  1. Should all constraints be together?
  2. Should constraints be set through a configuration file or a message?

It appears the REP sets these in a goal message? My initial reaction was “the URDF sounds like a good place to put kinematic constraints” but I can see use-cases where a separate configuration would be desired. The URDF would also only work for kinematic/hardware constraints and a separate message would be needed to describe desired behavior constraints.

1 Like
24

Hi Everybody,

sorry for the late reply – I’ve been on forced vacation the last 10 days, due to the Corona situation.

I agree in principle, but it has to be said that handling a URDF is quite a lot of overhead, particularly for simple cases. Moreover, not out of necessity but in current practice, URDF is often parsed at run-time, whereas planners for mobile bases are usually configured during node start-up.

Now that I think of it, this would be even more of be a limitation when using topics. With URDF you could at least in principle parse it before run-time.

Anyway, I would argue that as long as we can make it easy to use, it doesn’t matter much where we put the information. I surmise that handling all sorts of kinematic chains just to figure out whether we have a differential drive or an omnidirectional drive might be much harder than just configuring that somewhere, but then, I don’t know very much about kinematics, so this is really just a hunch.

In general, if we have to introduce new information that is not already possible to represent in URDF, I would argue for creating a separate configuration file rather than changing the URDF.

25

+1

(+18 more characters)