ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I suggest taking a look at ros_control, in particular the diff_drive_controller plugin in ros_controllers. That would closely resemble the one you used in Gazebo.

The 'only' thing you need to do is -- if one doesn't already exist -- write a hardware_interface sub class that knows how to communicate with your Tiva controllers. After that, you can 'layer' the diff_drive_controller on top of that and everything should start working.

Take look at ros_control_boilerplate by Dave Coleman for an example implementation.

I suggest taking a look at ros_control, in particular the diff_drive_controller plugin in ros_controllers. That would closely resemble the one you used in Gazebo.

The 'only' thing you need to do is -- if one doesn't already exist -- write a hardware_interface sub class that knows how to communicate with your Tiva controllers. After that, you can 'layer' the diff_drive_controller on top of that and everything should start working.

Take look at ros_control_boilerplate by Dave Coleman for an example implementation.


Edit:

...What exactly do you mean by saying: "The 'only' thing you need to do...should start working"

ros_control provides everything you would need, except a way to interface with your specific piece of hardware (how can it: there is almost infinite variety). It does provide you with a suitable abstraction that you can use to implement such an interface. That is the hardware_interface.

So the 'only' (and I place 'only' between quotes because it can of course still be quite some work) you need to do is implement such an interface. All the rest (controllers, action servers, etc) is provided to you by ros_control.

Isn't the hardware_interface a package that implements the ROS interface for any microcontroller someone might use for the driving of actuators or I am understanding something wrong?

Well, if with "that implements the ROS interface for any microcontroller" you mean that hardware_interface already has an interface for 'any microcontroller', then no, that is not the case (see my earlier comment).

In the example you presented, I don't really understand how I could use it for the Tiva microcontrollers. What I mean is that I will probably send PWM to the motors and get their condition from the encoders to close the control loop. I cannot find this logic somewhere in the code.

re: cannot find that logic anywhere: no, you won't find logic for dealing with PWM, motors or encoder counts. The ros_control_boilerplate provides you with everything else: setting up the loop, initialising datastructures (such as those that map URDFs to joints, etc), calling methods in the right order for you, etc. The 'only' thing you need to do is implement some code that can communicate with your Tiva controllers: here when new actuation comments should be written to the controllers, and here when the current state (ie: encoder counts) need to be read back from the controllers. How you do that is up to you (rosserial, some custom protocol?).

I suggest taking a look at ros_control, in particular the diff_drive_controller plugin in ros_controllers. That would closely resemble the one you used in Gazebo.

The 'only' thing you need to do is -- if one doesn't already exist -- write a hardware_interface sub class that knows how to communicate with your Tiva controllers. After that, you can 'layer' the diff_drive_controller on top of that and everything should start working.

Take look at ros_control_boilerplate by Dave Coleman for an example implementation.


Edit:

...What exactly do you mean by saying: "The 'only' thing you need to do...should start working"

ros_control provides everything you would need, except a way to interface with your specific piece of hardware (how can it: there is almost infinite variety). It does provide you with a suitable abstraction that you can use to implement such an interface. That is the hardware_interface.

So the 'only' (and I place 'only' between quotes because it can of course still be quite some work) you need to do is implement such an interface. All the rest (controllers, action servers, etc) is provided to you by ros_control.

Isn't the hardware_interface a package that implements the ROS interface for any microcontroller someone might use for the driving of actuators or I am understanding something wrong?

Well, if with "that implements the ROS interface for any microcontroller" you mean that hardware_interface already has an interface for 'any microcontroller', then no, that is not the case (see my earlier comment).

In the example you presented, I don't really understand how I could use it for the Tiva microcontrollers. What I mean is that I will probably send PWM to the motors and get their condition from the encoders to close the control loop. I cannot find this logic somewhere in the code.

re: cannot find that logic anywhere: no, you won't find logic for dealing with PWM, motors or encoder counts. The ros_control_boilerplate provides you with everything else: setting up the loop, initialising datastructures (such as those that map URDFs to joints, etc), calling methods in the right order for you, etc. The 'only' thing you need to do is implement some code that can communicate with your Tiva controllers: here when new actuation comments should be written to the controllers, and here when the current state (ie: encoder counts) need to be read back from the controllers. How you do that is up to you (rosserial, some custom protocol?).


Edit2: clarifying something that might not be apparent: the hardware_interface implementation that you write does not run on your Tiva controllers (it's a ROS node). Unless of course you can run ROS on your microcontroller.