Incredibly, I was able to purchase a very lightly used Staubli robotic arm and its controller for (relatively) cheap! The Staubli TX2-40 is their smallest offering, it’s payload is only a few kg, but it does have the best dynamics of their offerings (makes sense, it’s light). Not especially known for being spry, I’ve been curious about how to maximize the dynamic reponse of these arms in task space. To start with, I’d like to do some simple impedance control of the end-effector.

While the controller itself is incredibly basic, the bulk of the work will be integrating the arm into ROS (which I want for future extensibility). Setting up a driver node and the connection from that ROS node to the driver “firmware” running on the Staubli controller will be an interesting task.

The Staubli CS9 controller uses it’s own language to give integrators access to hardware registers, control modes, set destinations, and interact with the GUI on the user “pendant” for guided applications. The language, called VAL3, is vaguely C-like but without any indirection, and logical blocks sort of like Basic. It’s a little nerfed, I think to avoid programming errors that are a little more dangerous in this context than just on a computer. But very functional at the small overhead of more functions and variables than “optimal”.

There is an existing ROS integration for Staubli robotic arms, but it is very basic, exposing only point-to-point motion capabilities and relying on Staubli’s controller for all path-planning and lower-level performance. This is a nice abstraction for pick-and-place applications, but defeats my eventual goals for force control at the end-effector. Trajectories often take upwards of 200ms to clear even for sub-millimeter motions, since the controller has to plan, execute and verify the trajectory.

Instead, I’m going to take advantage of one of the advanced features in the controller (free for evaluation if you’re ok restarting the controller every once in a while), a function called alter. Originally designed for sanding/buffing/polishing applications, it allows applying an offset to the current trajectory. This allows “injecting” feedback into the controller from other sources, where otherwise it would operate rigidly on its own encoders and that’s it. The key twist is that the trajectory for the controller is not deemed complete until alter mode is exited. In this way, we can start a trajectory with a tiny epsilon and immediately enter alter mode, and from there control our position directly from ROS until we wish to exit. We can perform our own analysis of termination criteria, run our trajectory control live, and incorporate whatever sensing we want into the final control effort output. Perfect!