Control architecture survey

asked 2014-06-05 05:09:57 -0500

955 ●67 ●83 ●98

updated 2014-06-05 08:31:19 -0500

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.

edit retag flag offensive close merge delete

Comments

1

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.

dornhege ( 2014-06-05 06:17:24 -0500 )edit

Yep you are right, I have updated the diagram accordingly. Thanks.

arennuit ( 2014-06-05 08:31:52 -0500 )edit

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!

AxisRobotics ( 2018-09-19 20:35:44 -0500 )edit

add a comment

4

answered 2014-06-05 05:55:21 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2014-06-05 05:56:08 -0500

Interesting question indeed.

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

image description

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.

edit flag offensive delete link

Comments

This is an interesting approach, I like the fact it is rather standardized (so much as ROS-I can be considered a standard ;)). Thanks ;)

arennuit ( 2014-06-05 08:23:15 -0500 )edit

add a comment

2

answered 2014-06-05 17:30:41 -0500

ahendrix

47576 ●179 ●367 ●662 http://namniart.com/

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.

edit flag offensive delete link

Comments

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?

arennuit ( 2014-06-06 02:05:34 -0500 )edit

1

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.

ahendrix ( 2014-06-06 11:13:34 -0500 )edit

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.

ahendrix ( 2014-06-06 11:14:39 -0500 )edit

This makes sense (especially with the daisy chaining of motors in TTL). Thanks for your feedback!

arennuit ( 2014-06-10 06:13:30 -0500 )edit

add a comment

Control architecture survey

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Control architecture survey edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Control architecture survey