G.A. vd. Hoorn

But this is still taken from the `hardware_interface`, right? If so, we're looking at JTC output, which is influenced by TOTG/IPTP, but does not have a 1-to-1 relationship with it....

Also: I'm assuming you're using a real-time kernel and that the driver/`hardware_interface` has real-time priority. If not, then scheduling could be an issue here.

@RhysMcK wrote: > i just did a quick-and-dirty print out of the position commands just a note: both `printf(..)` as well as `std` stream output are two of the worst...

@hartmanndennis wrote: > Related: Should the call to controller manager update be changed to use a fixed duration and increment the time with fixed 4ms/12ms, since the robot expects points...

If possible, I would vote for using `IPOC_(t_n+1) - IPOC_(t_n)`. That would seem to keep things in sync with the controller.

> I'm particularly interested in supporting the ability to use the robot arm as a subset of a kinematic chain It's interesting that you post this, as ~#247~ #248 is...

To structure this a bit: can you point to some of the things that you see missing in the IKFast wrappers that `ur_kinematics` has?

This is still an issue (but I haven't seen any issues with the `mh5` package that could be traced to this).

@jwhendy: just wanted to let you know that we're not ignoring you. Reviewing this should be done carefully, and so takes a bit of time. I will get to it...

I know we're not always the fastest to respond @jwhendy, so I/we can't (and won't) complain (:)) but what is the status here?