By Shubham Sharma
One of the challenges while developing any robotic hardware is to handle the communications with the motors along with sending commands to them as per the generated trajectory in real time. Since the motor accepting trajectories should respect the time limits, it becomes important that the communication between the motor driver and the controller is seamless. Furthermore, the controller should also receive the latest joint state (position, velocity, effort) information from the motor so that the trajectory execution can be verified. The final challenge that remains afterward is to actually generate the trajectory and send it to the motor driver.
To achieve these requirements ROS framework provides us with the several tools such as ROS-control and ROS-Moveit. ROS (Robot Operating System) is a software framework that implement state-of-the-art algorithms and tools to simplify the development of robotic hardware and software with minimal efforts.
To control any joint actuator there can be multiple methods, such as, commanding joint positions, joint velocity, or, joint efforts. It completely depend on the application that, what level of control is required. Things become easier if the joint positions are directly used to command the actuator since all the low level processing such as velocity and torque control loop are executed within the drive hardware. However, if the joint velocities or joint efforts are used to command the actuator then the position interface has to be generated by running control loops on the commanding device i.e. in our case a linux machine running an instance of ROS control.
ROS-control
ROS-control is a ROS package capable of interfacing with multiple hardware instances mentioned above. To do so, it provides abstraction over the implementation of control loops such that any motor or actuator can be controlled irrespective of its hardware interface.
As per the official documentation, there can be four types of hardware interfaces that ROS-control can natively support:
- Joint Command Interface
- Effort Joint Interface
- Velocity Joint Interface
- Position Joint Interface
- Joint State Interface
The Interfaces can be best understood by the following image,
ROS hardware interface memory concepts, source : ros_control
As evident from the image, ROS control communicate with the actuators and the motors using the memory locations. For example, if the motor has to be commanded using the position interface, ROS control would simply write the position demand value at “pos_cmd_” memory location which would be then transmitted to the motor via the the communication interface of the motor. In case of TMC4671 eval kit with Landungsbrücke, these interfaces can be RS232, USB serial, or RN171XV/RN42XV wireless modules. Similarly, for velocity and effort interfaces the demand values get written to these memory locations which are pre-defined. Now, the question that remains is, how does the joint states are read from the motor. It is also anologous to the joint command interface where the joint values are read into the “pos_”, “vel_” and “eff_” memory locations.
Now its just matter of updating these memory locations at certain interval to command and read the joint interfaces. This process can be easily explained using following code snippet,
class trinamic: public hardware_interface::RobotHW
{
public:
trinamic();
void read();
void write();
};Here, the constructor can be used to initialize for example, communication interfaces (Serial in case of our implementation with Landungsbrücke). Moving further, both trinamic::read() and trinamic::write() functions are called periodically in a loop so that the memory locations are updated at a fixed interval.
ROS controllers
Once the hardware Interfaces are up and running, we can spawn one of the many controllers such as position_controllers, velocity_controllers, joint_state_controller, joint_trajectory_controller. These controllers are nothing but an abstraction of hardware interfaces as ROS topics. Here, as mentioned above, position_controller can be started with velocity joint interface such that the control loop is running on the host machine. Furthermore, joint_trajectory_controller is compatible with all types of joint command interfaces. One thing to note is that we should always check for conficts such that no two controllers are accessing the same hardware interfaces.
Establishing communication between ROS control and TMC4671
Thanks to TMCL API, establishing communication between ROS and TMC4671 via Landungsbrücke become effortless. As mentioned previously, the communication is established using USB serial communication that accepts command position (since we are creating hardware interface) and transmits joint position. Once Landungsbrücke receive this command position, it writes this value in register 0x68, PID_POSITION_TARGET via SPI. Furthermore, the current position value is taken from register 0x6B, PID_POSITION_ACTUAL and transmitted via USB serial. Since all these values are 32 bit signed integers, the data is marshalled into 4 single byte unsigned integers for both sending and receiving.
How to setup everything
Initially setup TMC4671 according to the motor using TMCL-IDE, the process is nicely explained here. Update the Register settings received from IDE in init_motor() function of ROS_control.c. Now download the ROS package in any workspace and start the hardware interface using launch file. Any compatible ROS controller can be spawned along with the ROS control node in the launch file. The controller can be configured in the controller.yaml.
The most important part while using position control with TMC4671 is to tune PI gains for velocity and position control loops. These loops can be manually tuned using 0x58 and 0x5A registers. However, it is strongly not advised.
References
- S. Chitta, E. Marder-Eppstein, W. Meeussen, V. Pradeep, A. Rodríguez Tsouroukdissian, J. Bohren, D. Coleman, B. Magyar, G. Raiola, M. Lüdtke and E. Fernandez Perdomo
- “ros_control: A generic and simple control framework for ROS”