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

Serial communication with multiple nodes

asked 2018-09-20 02:52:58 -0500

lorenznew gravatar image

updated 2018-09-20 04:12:30 -0500

hey,

I've got a short question. When i have two nodes, both want to communicate via a serial port. One wants to send a command an receive an answer. The other one just sends a command. How can I be sure, that they do not send parallel at the same time? And, no one sends, while an answer is received?

ah, and I would like to use the serial.h libary

EDDIT: The Nodes are running on one PC and would like to communicate to external Hardware, such as a control board used for reading sensors und moving motors.

Thanks a lot

L

edit retag flag offensive close merge delete

Comments

Can you clarify the question a little. Are the two nodes on different computers which are communicating via a serial link? Or are both nodes on the same computer trying to share a serial port to a third device, which is not possible as far as I know.

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-09-20 03:52:41 -0500 )edit

The Nodes are running on one PC and would like to communicate to external Hardware, such as a control board used for reading sensors und moving motors. Thanks!

lorenznew gravatar image lorenznew  ( 2018-09-20 04:12:03 -0500 )edit
1

Not a complete answer (as it involves a node), but shared_serial is a package that seems to implement what you are after.

gvdhoorn gravatar image gvdhoorn  ( 2018-09-20 04:41:02 -0500 )edit

Your question is a classic "concurrent access to a shared resource" problem.

Normally you could use a mutex or one of the various locks to protect access to the shared resource.

In the case of multiple processes though (nodes are processes) this becomes more difficult. Sharing mutexes using ..

gvdhoorn gravatar image gvdhoorn  ( 2018-09-20 04:42:25 -0500 )edit

.. a shared memory segment is a possibility, but will of course completely lock your two nodes together (both at the design as well as the implementation level).

Introducing a 'gateway' node / entity that serialises access to the shared resource is a common approach used in these cases.

The ..

gvdhoorn gravatar image gvdhoorn  ( 2018-09-20 04:43:49 -0500 )edit

.. setup would have three nodes:

  • the gateway (or bridge)
  • node A
  • node B

if A or B want to access the resource, they have to go through the gateway. All nodes communicate using messages.

In the case of ROS, you could use nodelets to remove the msging overhead, but that is an optimisation.

gvdhoorn gravatar image gvdhoorn  ( 2018-09-20 04:45:12 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-09-21 17:57:49 -0500

billy gravatar image

I have similar situation and solved it this way:

  • Several nodes writing to a topic /serialport and a node that sends the messages out serial port.
  • One node that reads messages in from the serial port, decodes and puts data onto the appropriate topic so the relevant node gets it's answer.

In my case, the controller (LPC1769) will send an answer back when it has it and can take other commands in the meantime so no need to hold the port while waiting for response. In this way, I can keep the port running near max capacity. I treat the serial port output 100% separate from the input and have no mutexes or other controls. This is similar to the way gvdhoorn proposed except I use two nodes to access the HW. Maybe this helps you. One weakness of this method is that ROS could spam the controller to the point that messages get dropped. That hasn't been an issue yet though. Input buffer on controller is large.

edit flag offensive delete link more

Comments

I have similar situation and solved it this way

I don't have any shares in it, but that is exactly what shared_serial does.

gvdhoorn gravatar image gvdhoorn  ( 2018-09-24 02:26:24 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2018-09-20 02:52:58 -0500

Seen: 1,142 times

Last updated: Sep 21 '18