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

How to run a node with realtime priority

asked 2017-01-07 06:39:31 -0500

Cerin gravatar image

What's the appropriate launch-prefix to use to make a node run with realtime priority?

I have a node that relays low-level motor control commands to an Arduino over a USB serial line, and the default node has really bad latency. Sometimes it can take up to 10 seconds for the node to accept a service command (e.g. stop all motors!), which obviously can be fatal to the robot in some circumstances.

I know you're supposed to use the "launch-prefix" argument in the launch file to set the node's process priority via nice, but what are the best nice values to use? Would this combination of nice and ionice be appropriate for running a node in near-realtime?

nice -n 19 ionice -c1 -n0
edit retag flag offensive close merge delete

Comments

Are you sure that this is possible in a launch file? A normal user cannot run nice with negative values.

NEngelhard gravatar image NEngelhard  ( 2017-01-07 09:28:44 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
2

answered 2017-01-07 12:37:46 -0500

ahendrix gravatar image

This is tough.

If there's a specific operation where you want to reduce the latency, you should measure the latency at each step of the process and work to reduce the largest sources of latency first.

In the case of a ROS service call taking too long, my gut tells me the largest source of latency would be the service connection setup.

I suggest you collect timestamps at the following points, to see where the latency is:

  • Immediately before the service client is created
  • Immediately before you make the service call
  • Within the service call, collect the following timestamps and return them as part of the service result:
    • Beginning of service callback
    • Immediately before you send data over USB (if this differs significantly from the beginning)
    • Immediately after you send data over USB
    • If you're expecting data back over USB, a timestamp after you get data back over USB
    • Immediately before your service callbacks returns
  • Immediately after the service call returns in the client

From those timestamps, you should be able to see how long it takes to set up the service client, how long it takes for the service call to get from the client to the server, how long your USB transaction takes, and how long it takes to get the result back.

Once you have that data, that will show whether the underlying issue is setup latency, scheduling latency in the server, USB latency, or something else.

edit flag offensive delete link more

Comments

I completely agree, and this is what I've been trying to do. I've set the serial baudrate to 115200, the highest supported, and profiled the rosservice command, and the service callback.

Cerin gravatar image Cerin  ( 2017-01-07 19:40:20 -0500 )edit

The rosservice command takes a median time of 2 seconds, but the timestamp difference printed at the end of my callback only shows a median time of 0.2 seconds. So presumably the bulk of the overhead is with ROS's internal message passing.

Cerin gravatar image Cerin  ( 2017-01-07 19:41:24 -0500 )edit

I'm running all commands on the localhost, so network latency isn't an issue. How can I speed up ROS's message passing?

Cerin gravatar image Cerin  ( 2017-01-07 19:42:59 -0500 )edit

There's a lot of overhead involved in starting up the python interpreter and loading the rosservice script from disk, even before it can begin executing. The easy things to do are to switch to a custom node that runs continuously to call the service.

ahendrix gravatar image ahendrix  ( 2017-01-07 21:51:59 -0500 )edit

Within your custom node, you can keep a persistent service client, so that you don't have to do the service client setup every time you want to send a stop command.

ahendrix gravatar image ahendrix  ( 2017-01-07 21:52:51 -0500 )edit

Good point.

Cerin gravatar image Cerin  ( 2017-01-08 12:37:24 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2017-01-07 06:39:31 -0500

Seen: 1,770 times

Last updated: Jan 07 '17