Tbh: I don't think you necessarily need to use transmissions for this.
Transmissions can be useful, but I'm not sure how useful if you have a simple position controlled manipulator that you wish to make ROS-compatible.
The level at which most control nodes / ros_control controllers interact with hardware of this kind is at the (abstract) joint level, where the specifics about how that joint is finally controlled (and through which mechanism) isn't necessarily available / important. As long as the set of joints you model in your URDF (and thus 'expose' to the rest of ROS (ie: MoveIt, etc)) can be controlled in some way to execute the planned motion, things should just worktm.
Things to check / take care of (off the top of my head):
- make sure all
axis definitions in joints correspond to your hardware (ie: 1 for "positive angle increase maps to positive rotation of frame" and -1 for the inverse) - have a controller capable of consuming
JointTrajectory messages that is able to map between URDF joint names and your hardware / lower level controller (either something custom or using any one of the available abstractions (ros_control fi)) - make sure origins of URDF
joints correspond with their locations in your real system (don't just assume things are ok because your EEF frame ends up in the right Cartesian location) - define position, velocity, acceleration and effort limits correctly: MoveIt fi uses those to not only avoid planning invalid paths, but also when populating the
velocity, acceleration and effort members of JointTrajectoryPoint messages
