Frequently Asked Questions

This link provides a registration form to request a license. The license code, which is valid for 60 days from the request date, will be e-mailed to the address that you provide. Please check your spam folder.

You may install the license on two (2) devices with the trial license. After 60 days, the license will expire, and Supervisor will no longer start up.

Make sure that your robot is receiving the commands for motion. Use ROS2 rqt (ROS1 rqt_graph) to illustrate the topic connections. ROS topic echo commands can also be used to verify that the commands are varying as expected.

3Laws Supervisor is an off-the-shelf ROS-based node that provides collision avoidance for ground robots such as omni-directional quadruped, omni-directional wheeled, font-steered wheeled, and differential drive wheeled/tracked platforms.

3Laws Supervisor Pro uses the same technology as Supervisor but is built to support specific applications:

• Communication interfaces other than ROS
• Platforms such as flying propeller-based vehicles, fixed wing aircraft, marine surface boats, submarines, passenger vehicles, and autonomous big-rigs, for example.
• A wide variety of single or combined objectives including collision avoidance, geo-fencing, stability, and specific-state limiting (such as angle-of-attack).
• Operational Domains where formal certification is desired.
• Specific optimizations based on higher-order system models. The more accurate the model, the more responsive the Supervisor can be, and the higher performance that can be obtained from the system.

Please contact sales to discuss the possibilities with Supervisor Pro.

Supervisor uses ROS for communication and execution. The following versions of ROS/ROS2 are supported:

These versions are supported on amd64 (x86_64) and arm64 processor architectures.

Please contact 3Laws support to discuss
availability of other configurations.
Foxy, Iron, and Galactic have been compiled (and
can be requested), but have not been thoroughly tested by 3Laws.

Supervisor has been deployed on systems including Raspberry Pi 4. If a 2D Lidar with less than 2000 points is used, Supervisor will be able to recalculate solutions typically in 2ms or less.

Detailed user documentation is available here

The base Supervisor has been tested with 2-dimensional LIDARs like SLAMTec RPLidar. Other 2-dimensional LIDARS are also expected to work after a little configuration through the Control Panel web-based interface.

3Laws Supervisor Pro easily integrates with the majority of off the shelf sensor technology, making it possible to introduce reliably safe and high-performance products to the market with an accelerated timeline and lower costs.

The list of devices below are units that are supported by ROS (as of 20240617). Message integration on ROS is straightforward. Other devices can also be supported if the application program interface (API) is available.

After message integration, data processing for the sensor needs to be tuned to get the best performance based on the sensor’s physical behavior in the desired application environment.

Sensors needed for each application are typically as follows:

1. Collision avoidance: Device that gives the location and extents of an object in the path of the robot’s motion
2. Geofencing: Sensors include Inertial Measurement Units (IMUs) that provide an estimate of the device’s location and orientation, Global Positioning Sensors (GPS) that are useful outdoors when there is good satellite coverage, and position tracking cameras.
3. State constraints such as preventing an AMR from tilting: Typically handled by an IMU or integrated IMU/GPS package as well as wheel odometry.

After installing Supervisor on a ROS-based system, the command paths need to be rearranged so that Supervisor sits between the planner/autonomy-stack and the robot drivers if Supervisor is to be used actively (e.g. not just as a monitor).

There basic need os to change the robot driver’s subscription for commands from the existing one (e.g. “/cmd”) to the Supervisor output (“/lll/ram/filtered_input”) and then set up Supervisor to subscribe to the original command set (e.g. “/cmd”). This can be accomplished by changing the subscription topic in the low-level driver/controller or by remapping the input at launch time. Examples of this are provided in: here

The autocompletion capabilities fails to find topics:

If the Rosbridge web server is connected to the control panel (see User guide > Control Panel for installation and connection details), topics don’t appear (only rosout and client_count) try the following:

Check if the Rosbridge web server is connected to the control panel. You can do this by checking top right corner of the control panel. If the Rosbridge web server is connected, you should see a green icon.

Click on the reload button in the top right corner of the topic form (green circular arrow).

Stop the Rosbridge web server, source your ROS workspace and start the Rosbridge web server again.

Check the Rosbridge web server log for any errors.

Messages appear in standard out reporting that QP fails to solve

If the Supervisor filter rate is set too fast, the processor might not have enough time to finish the QP problem. The delay may also occur if the laser scan has too many points. The best approach is to reduce the rate at which the filter solves to see if that resolves the problem.

Platform fails to move even when there are no objects nearby

Try launching Supervisor from a terminal to see what error messages appear. Supervisor will typically color fatal errors with “red” text. If a critical error occurs, Supervisor will stop operating. None of the commands will get forwarded to the platform.

Supervisor may also keep the platform stationary if the LIDAR data or the list of obstacles is not delivering data quickly enough. This design ensures that if Supervisor does not have sufficient information about surrounding collision candidates, it does not allow the platform to proceed. A good strategy is to start up the Operations tab for Control Panel (with Rosbridge) and see if any of the input blocks (desired input, state, perception) is a color other than green.

Another cause of platform failing to move is that the topic routing is not correct. The ROS rqt tool with the Node Graph can visually display the routing well. Verify that the desired inputs (e.g. cmd_vel_plan) are coming into Supervisor, and that Supervisor’s outputs (e.g. /lll/ram/filtered_input) is properly mapped to the signal that the lower layer is expecting (e.g. cmd_vel).

My robot doesn’t move when I send a command

Make sure in that in the Operation tab of the Control Panel everything is green. If not, check the logs for errors.

The Operation tabs show that everything is OK but the robot still doesn’t move

Make sure that your robot is receiving the commands for motion. Use ROS rqt (ROS1 rqt_graph) to illustrate the topic connections. ROS topic echo commands can also be used to verify that the commands are varying as expected.