# ros_control questions

I have been studying ros_control and how to use it for a while now, but I still have a few questions. I have made a list of the questions I have been unable to answer, and I would appreciate it someone could help me find answers.

1. The velocity and position controllers are listed twice here: http://wiki.ros.org/ros_control#Contr... . (Both are under "effort_controllers", and then each is under their own section.) Is that just a typo, or am I missing something?

2. I was not planning to have sensors that could feed a JointStateInterface implementation. (My robot is car-like, and I believe that higher-level feedback from IMU and GPS sensors will be sufficient.) I'm thinking that I will write my hardware interface implementation to just echo the set point back as the current state. Should that work? Has anyone else done that before?

3. I have had a difficult time understanding the role of transmissions with regards to Gazebo. The Gazebo documentation seems to suggest that a transmission is required for each joint. I think it's because the Gazebo plugin is unable to read the YAML file used by ROS controller manager to determine whether to use a velocity, effort, or position controller. Do I have that right?

Thanks, Sam

edit retag close merge delete

Sort by » oldest newest most voted

Q1

effort_controllers implements simple controllers for effort-controlled joints. These controllers are joint_effort_controller, joint_velocity_controller and joint_position_controller. They take as input effort, velocity and position references, respectively, and transform them into effort commands. The same line of thought applies to the velocity_controllers and position_controllers packages. This is why you are seeing multiple instances of joint_position_controller, for instance. There are two versions, one targeting effort-controlled joints, and another targeting position-controlled joints.

Q2

You can echo your commands as state if you want. This would give you a 'perfect control' plant. It's up to you to determine if that's OK for your usecase.

Q3

In real hardware, transmissions serve the purpose of mapping actuator state readings to joint space, and joint commands to actuator space. In simulation, transmissions are used to determine which joints to expose to your hardware interface, and which interfaces should be supported. There is currently no notion of actuators in gazebo_ros_control.

more

It's not a real answer but a bit too long to be a comment sorry.
I don't know for the two first ones, I asked myself the same question about the first one and I would be interested to know what I missed.
Regarding the last one about transmissions, I think you're right about the fact that it is used to specify the kind of controller used.
I my opinion the main point of this tag is giving a true physical meaning to how a motor can actuate a joint. As far as I understand, this is the purpose of the actuator tag. This allows you to specify the reduction ratio that is indeed applied on the output of the motor. This way if at some point you can define exactly the characteristics of your motor (that you cannot really do yet), this tag will allow you to have reliable torque estimation applied on your solid (links). This way you should be able to have finer simulation regarding the behaviour of your joints according to the mechanics and electronics interations at the lower level.

On many robots, the same motor model is used to actuate different joints and the only difference is the reductor putted between the motor and the actual moving part. This tag should allow you to make the difference between a given motor model and its real action over a given joint.

more