Ask Your Question

Custom robot hardware_interface implementation

asked 2021-01-26 11:09:11 -0500

MaximN74 gravatar image

Hi, colleagues!

Regarding my previous question ( I looked for ros_control and ros_controllers packages as a first steps in making my manipulator available for high-level.

As mentioned in some examples, it is need to make custom ROBOT_hardware_interface implementation, which has a ad() and write() methods.

For example extracts from example ( code contains prototypes like:

void MyRobot::read() {​

  // Write the protocol (I2C/CAN/ros_serial/ros_industrial)used to get the current joint position and/or velocity and/or effort       
  //from robot.
  // and fill JointStateHandle variables joint_position_[i], joint_velocity_[i] and joint_effort_[i]


So, the question is: is it possible to implement such code that read positions/velocities from other node using service calls (or maybe topics) ? May this way cause any problem? I think read() and write() methods are just usual functions, not specific to SPI/I2C etc. communications...

Thanks for answers!

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2021-02-02 01:10:26 -0500

Bence Magyar gravatar image

Clearpath's Husky is also using ros_control. The main reason for most people to implement a ros_control layer is to gain access to the standard set of controllers & a fairly seamless gazebo integration.

I agree that relying on ROS services in a RobotHW is not a great idea but if you can do it with topics, you suddenly have a non-blocking setup which, provided that the rest of the system manages to keep up, should work out fairly well. Of course you won't have realtime-safety guarantees but if you are running something low-rate of fairly safe, you are probably going to be fine.

The most extreme non-realtime ros_control implementation I made had a texas instruments microcontroller board talked to ros_control over rosserial and some topics. It was fine, ros_control is not only for industrial communication back-ends.

Here's a great example from Clearpath on how to make a very simple RobotHW implementation with topics, no realtime guarantees:

edit flag offensive delete link more

answered 2021-02-01 05:57:02 -0500

ingtux gravatar image

The short answer is yes you could have service calls or a continually updating topic subscription populate your read() method and in your write() method have a topic publish or action service request. If you did want something simple like this I wouldn't bother using ros_control however, it would be more suitable to just write your own py/cpp node that doesn't implement the robot_hw interface.

The main reason why this isn't a good idea is that your control loop is going to be slow as you are using non-realtime operations within it. Whilst its possible to avoid this with realtime publishers and subscribers or just having a slow control loop, as I said previously, it wouldn't be worth the effort to use ros_control.

You are right that there is no specific need for a i2c or CAN or etherCAT communication system in your robot_hardware but you will find that most research and commercial implementations will have this. I would recommend looking through some real world examples on github like Clearpath's Husky.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2021-01-26 11:09:11 -0500

Seen: 238 times

Last updated: Feb 02 '21