"Runtime-configurable" Parameters in Autoware.ai

Archive Autoware
1

There has been some discussion internally at AutonomouStuff (and in the community - see Fix twist_gate problems when using decision_maker. (#9) · Issues · Autoware Foundation / MovedToGitHub / core_planning · GitLab) about what in Autoware.ai should be considered “runtime-configurable” parameters. Since we are using launch files to run Autoware.ai in a repeatable configuration and the original design targeted using the UI provided by runtime_manager, we have run into several cases of nodes making assumptions about things changing during runtime that some of us at AS think should be static once the node is launched. I’m using this opportunity to start a discussion about how the community feels regarding this issue. Here are a list of items which could be changed within a node, some of which are currently configurable through the UI (using a message on a /config topic) and some of which are only configurable as start-up parameters, either through ROS params or command-line arguments:

  1. The names of topics to which the node will publish/subscribe (i.e. instead of using topic name remapping, some nodes accept parameters for the topic names)
  2. Whether a node will publish/subscribe to specific information, regardless of topic name (e.g. if using a node in conjunction with another node, change the advertisement of topics to account for that node’s subscriptions/publications)
  3. Internal algorithm parameters which affect the output values of messages published on topics but not the topic names (e.g. max_velocity, min_steering_angle, etc.)
  4. Whether a node actually publishes data or not to a given topic (even if the node is already advertising a topic, a parameter sometimes tells it to not publish any data on that topic)

There are two major methods that users of Autoware.ai use today for launching nodes: the runtime_manager UI and launch files. When instructions are given for how to do something in the UI, you can ask users to launch nodes in a specific order. However, when nodes are launched from launch files, the order of launch is indeterminate because each node is launched as its own process and process scheduling is indeterminate.

I would like to make the following basic assumption (and would like to hear if anyone disagrees): I believe that any node, when launched, should not depend on the existence of any other node for determining its runtime configuration.

Opinion: I believe that topic names and the advertisement of or subscription to those topics should be decided when a node is launched and should not be changed while the node is running (1 and 2 above). I’m personally just fine with parameters which affect only the data being published to topics (3 and 4 above) being modifiable while a node is running.

Here’s a concrete example: Currently, the waypoint_replanner node gets the list of running nodes from roscore and looks for a node named decision_maker. It then changes its topic subscriptions/publications based on whether a node with the name decision_maker is currently running or not. I believe this is bad practice and a startup parameter (e.g. use_decision_maker) should be set at launch and the topics should not change.

Opinions from the community?

2

I can’t find a documented ROS best practice or REP, but part of what you describe is what I understood as a ROS standard (maybe it was an unofficial standard).
Basically that the node should be designed to simply start up and wait patiently until the topics/tfs that it needs are published.
If a node determines what it needs based on the existence of other nodes, then it sort of violates this standard since the node will do different things without explicit control through parameters.
It also blatantly goes against roslaunch/node design in that it does matter which order the nodes are launched in, when it shouldn’t.

I agree with your opinion statement and would be interested to hear from anyone about a use case that disagrees with it.

3

I very much agree that the interdependence between nodes is a major design issue. Additionally, I find that the use of the /config topics hides the node configuration from the user. I cannot simply look at the log file or use “rosparam list” to determine the settings used to launch a given node. Instead, I must echo the various /config topics before the data is published in order to ensure the configuration is recorded. Depending on rosparam or the widely used dynamic_reconfigure package seems like the more reliable method for parameter configuration to me.

Many nodes in autoware seem to operate on the assumption that the runtime_manager is used, which is a bad assumption. I imagine, most users will only use the runtime manager for initial development. Once they have identified the configuration that is desired they will write custom launch scripts or UI as AStuff and my own team has done. Then the user’s own research can proceed using the necessary components from Autoware.

1 Like
4

The way these sorts of things are done in the current Autoware nodes is indicative of many bad practices being adopted and then perpetuated over time. They do need to be fixed.

Here are some specific comments and general advice all mixed up.

This is a ROS anti-pattern. It should not be done. Any topic name changes must be done using remapping.

This is a really bad smell.

If you are trying to account for another node changing its topic name, you need to remap; use a launch file parameter to avoid specifying the remap target in two places.

Publishing is a no-op if there are no subscribers, and if no one in your system is interested in the data then no one will subscribe. If you really don’t want the node to publish to the topic, remap the topic name to something obscure.

If no data is being published on a topic, subscribing to it is zero-cost other than a little memory. If you really don’t want your node to subscribe to a topic (e.g. because it is being used by several other nodes), remap the topic name to something obscure when you launch your node.

Parameters all the way. Do not use your own command line arguments, which is something many Autoware nodes do.

If a parameter should be changeable only at launch time, use a standard parameter. You can control when you grab the value of it easily.

If a parameter should be changeable at runtime, use dynamic_reconfigure.

This is a bad smell. If you are going to provide an API, you should provide it properly. If you do not want anyone else to use the data you are publishing then remap the topic name to something obscure.

If you want to turn on and off bits of a node (e.g. to reduce computation time), you should consider whether those functions should be in separate nodes that can be started and stopped based on the system integrator’s needs.

One node depending on another for its configuration destroys reusability, separation of concerns, and half a dozen other good software engineering practices. Every node must be independently usable and launchable. All configuration should only come from external tools such as roslaunch and rosparam. No configuration should be done through a topic, except via dynamic_reconfigure.

There are no words.

If the behaviour of waypoint_replanner changes significantly depending on if the decision_maker node is present or not, then there should probably be two separate implementations that meet the same interface.

If the behaviour does not change significantly, then a startup parameter is more suitable. However I still feel that this is a bad smell because it reduces the understandability and independence of the node. Ideally nodes should only adapt to whether data is available or not, or whether a service/action is being provided or not, not to the presencen or absense of other nodes.

3 Likes