0
$\begingroup$

Rosanswers logo

Dear all,

I am wondering what hardware tech is most used to interface with ROS. I have drawn a little diagram which I believe is typical of most ROS control architectures and I am wondering which particular technology you use for the items shown in white. The idea is to understand if there is a typical "kind of standard" control architecture. I guess this will be interesting for many among us.

Specifically:

  • The communication between the ROS PC and the controller
    • I expect most people use Ethernet, or I2C, SPI... But is it really the case?
  • The motor controller
    • I expect hobbyist use custom-made controllers or cheap ones from the internet and professionals use proprietary ones such as EPOS from Maxon... What do you use?
  • The communication between the encoders and the ROS PC
    • You also use Ethernet, or I2C, SPI?

Typical ROS architecture

I believe it would be great to indicate your skills level as well: whether you are a hobbyist, a researcher, or someone working in the industry...

Thanks,

Antoine.

Originally posted by arennuit on ROS Answers with karma: 955 on 2014-06-05

Post score: 3

Original comments

Comment by dornhege on 2014-06-05:
From my point of view there is no clear answer besides: Whatever the hardware dictates. The one thing I'd change in your diagram: Encoders are usually not directly connected to the PC.

Comment by arennuit on 2014-06-05:
Yep you are right, I have updated the diagram accordingly. Thanks.

Comment by AxisRobotics on 2018-09-19:
In our model, our encoders don't even directly connect to the motor controller. Point being, it's up to the designer of the robot and there are a lot of variables. When we first got started with ROS, it was the high level of abstraction that was difficult to digest. Start small!

Improve this question
$\endgroup$

2 Answers 2

Reset to default
0
$\begingroup$

Rosanswers logo

Interesting question indeed.

As for my own experience (academia): within ROS-Industrial we have a somewhat different setup:

image description http://wiki.ros.org/Industrial?action=AttachFile&do=get&target=ros_industrial_architecture.png

The driver part of ROS-Industrial (which lives in the ROS-I Controller layer in the above diagram) provides abstracted access to the sensors and actuators that the controller supports. On a hardware level this means that we use the facilities of the industrial controller built by the manufacturer, which provides us the blocks Motor Controller/Power and Motor/Encoders in your diagram.

The industrial controller runs a manufacturer specific program (most of the times in their proprietary language). The ROS side (the drivers) communicates with those programs using a simple TCP/UDP based protocol (simple_message). ROS-Industrial provided nodes (industrial_robot_client) implement the necessary interfaces (FollowJointTrajectoryAction, JointState, etc) needed for higher level ROS capabilities (eg MoveIt) to close the loop.

There are some drivers within ROS-Industrial though that are implemented on top of ros_control: the universal_robot C-API driver being one of them.

As for communication: many industrial controllers provide Ethernet connectivity, which is most often used. Some older controllers only support serial connections, but those aren't used in any released packages.

Originally posted by gvdhoorn with karma: 86574 on 2014-06-05

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by arennuit on 2014-06-05:
This is an interesting approach, I like the fact it is rather standardized (so much as ROS-I can be considered a standard ;)). Thanks ;)

Improve this answer
$\endgroup$
0
$\begingroup$

Rosanswers logo

I have a hobbyist-level mobile robot with the following setup:

  • A custom motor controller based on an arduino, a pololu motor controller, and a custom encoder
  • A serial (UART) link between my motor controller and my ROS PC
  • A custom ROS node which communicates with my motor controller and provides a standard ROS interface with /cmd_vel, /odom. TF frames and diagnostics.

I also work on a research project with a similar setup:

  • A custom hardware interface box with several CAN interfaces for commands and feedback
  • One ROS node for each CAN interface, exposing custom messages
  • A ROS node which aggregates the custom messages and exposes a standard ROS interface.

Originally posted by ahendrix with karma: 47576 on 2014-06-05

This answer was NOT ACCEPTED on the original site

Post score: 2

Original comments

Comment by arennuit on 2014-06-06:
Thanks for you answer! I guess the limit of your hobbyist architecture is that it does not scale to more than a single motor... Hence the CAN in your project... Is that right?

Comment by ahendrix on 2014-06-06:
That's not the case at all. My arduino is completely capable of driving several motors. The choice between CAN and TTL serial is driven mostly by the distance and the environment. The serial bus in my hobby project about 8 inches long and isn't subject to much noise.

Comment by ahendrix on 2014-06-06:
By contrast, the CAN bus in the research project I work on runs the length of a car, so it needs the significantly higher noise resistance present in CAN.

Comment by arennuit on 2014-06-10:
This makes sense (especially with the daisy chaining of motors in TTL). Thanks for your feedback!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.