Support for asynchronous motion

[jimmy-mcelwain]

This is already mentioned on the roadmap but there is no issue tracking it yet. We've gotten a few customer questions recently, though, so I thought I'd create the issue now.

I looked into this briefly just to see how mpExRcsIncrementMove would work with asynchronous motion. Implementing asynchronous motion will complicate the job setup.

Asynchronous motion cannot be done with our current INIT_ROS job. I think that we will need a second job, INIT_ROS_ASYNC or something like that. INIT_ROS_ASYNC will need to be a non-group concurrent job that calls PSTART on several jobs, each one being a group job.

For example, for an R1 + R2 system with asynchronous motion, you would need

INIT_ROS_ASYNC
ROS_R1
ROS_R2

For R1 + R2 + B1 + B2, you would need

INIT_ROS_ASYNC
ROS_R1
ROS_R2
ROS_B1
ROS_B2

I believe that you could theoretically have some control groups synchronize and others not, e.g.

INIT_ROS_ASYNC
ROS_R1_B1
ROS_R2_B2

But this would make things more complicated in terms of configuration, inform generation, request parsing, and motion control.

After submitting trajectories, a call to mpExRcsIncrementMove would be done for each job whose group has data in the incremental motion queue. So in a fully asynchronous R1 + R2 + B1 system where there is data in the queue for both R1 and B1, there would be 2 calls to mpExRcsIncrementMove every 4ms until one of the groups has no data left.

I am not really sure how to handle some of this. Should we change our FJT action server to have one goal handle for each group? Or do we want 2 action servers, one for synchronous motion and one for asynchronous motion? Do we just want to expose only one FJT action server and have users to pick synchronous or asynchronous through the config file? Or we could have a new service /start_traj_mode_async, or start passing arguments specifying the traj mode into /start_traj_mode. We could also assume that all joints sent in a given FJT message should be synchronized (this probably isn't feasible given the job constraints). It seems like there are several ways to do this, and I don't know what the standard is.

Everything I've mentioned here is about FJT, but it is mostly true for point queue mode too.

There are a couple of other motion related ones like #51 and especially #29 that would be helpful for asynchronous motion, and could maybe be done at the same time as this.

[gavanderhoorn]

Thanks for your analysis. You raise some good questions/points.

An alternative approach which I don't believe you've considered here: internally (ie: internal to MotoROS2) merge incoming overlapping goals for different groups and feed it all as a 'single' trajectory to the task processing / handling the increment queue in the current implementation.

Groups without an active trajectory would then 'just not move', similar to how it works now.

It would essentially mean supporting partial goals -- so goals wouldn't have to include trajectories for groups / joints that don't need to move -- which was discussed in #218.

Should we continue the discussion there?

[gavanderhoorn]

Continued in #218.