Maximum nr of joints supported?

[gavanderhoorn]

The current implementation seems to hardcode the maximum nr of joints (in JMOVEs fi) to 6.

Should the max nr be higher (say 10) to support robots with more than the standard 6? I'm primarily thinking about external axes here, such as rotary tables and linear tracks.

The JOINT_POSITION and JOINT_TRAJ_PT msg types could be extended to always include data for 10 joints, with the robot controller ignoring the joints it doesn't have for incoming JOINT_TRAJ_PTs and setting them to 0 in JOINT_POSITION.

[G-Paris]

Yes, in the current implementation the amount of joints is hard-coded to six. The Kawasaki does support multiple(I think even "infinite") external axes, though I haven't looked in to how this is handled in AS script.

Depending on how external axis control is handled by Kawasaki I would suggest a variable amount of fields per robot type and optional external axis.

Determining the amount of message fields could be handled by initialization. This seems like a more flexible option than extending a hard-coding amount of fields.

Having 10 axis fields should be enough for any realistic setup I can think off. With exception to maybe an experimental setup with a Kawasaki DuAro. On the other hand it seems a bit redundant(though unimportant) to send six 0's when controlling a palatizing robot.

Do you see any drawbacks?

[gavanderhoorn]

Determining the amount of message fields could be handled by initialization. This seems like a more flexible option than extending a hard-coding amount of fields.

true, however: most industrial robot controllers limit the total nr of joints in a single motion group to 10. That's why I suggested hardcoding it. Dual-arm robots typically then have two motion groups.

Making it all dynamic would certainly be possible. We should then include a field in the JOINT_POSITION and JOINT_TRAJ_PT message types that encodes the nr of entries in the joint_state list.

On the other hand it seems a bit redundant(though unimportant) to send six 0's when controlling a palatizing robot.

A 0 would be a single character (== 1 byte). That doesn't seem like too much overhead. Using fixed size messages does have its advantages.

[G-Paris]

true, however: most industrial robot controllers limit the total nr of joints in a single motion group to 10. That's why I suggested hardcoding it. Dual-arm robots typically then have two motion groups.

Making it all dynamic would certainly be possible. We should then include a field in the JOINT_POSITION and JOINT_TRAJ_PT message types that encodes the nr of entries in the joint_state list.

A 0 would be a single character (== 1 byte). That doesn't seem like too much overhead. Using fixed size messages does have its advantages.

Hardcoding maximum amount of joints to 10 seems easier without serious downsides. Would actually have my preference right now. Will revisit this option and leave this comment open until I actually update the code and have to implement one or the other.