LICENSE 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.
SUPERVISOR CAPABILITIES
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:
Ubuntu 22 | ROS2 Humble: Fully Supported |
ROS2 Iron: Partially Tested |
|
Ubuntu 20 | ROS1 Noetic: Fully Supported |
ROS2 Foxy: Partially Tested |
ROS2 Galactic: Partially Tested |
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:
- Collision avoidance: Device that gives the location and extents of an object in the path of the robot’s motion
- 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.
- State constraints such as preventing an AMR from tilting: Typically handled by an IMU or integrated IMU/GPS package as well as wheel odometry.
Category | Supported Devices |
---|---|
Compute Architecture |
|
LIDARs and Laser Scans
Note: 3Laws is compatible with any LIDAR or Laser Scan with a driver that publishes to sensor_msgs/PointCloud, sensor_msgs/PointCloud2, or sensor_msgs/LaserScan |
|
RADARs
Note: Any radar with a driver that publishes to radar_msgs/RadarTrack |
|
Point Cloud Cameras
Note: Any camera with a driver that publishes to sensor_msgs/PointCloud or sensor_msgs/PointCloud2 |
|
Position Tracking Cameras
Note: Any camera with a driver that publishes to nav_msgs/Odometry |
|
Inertial Measurement Units (IMUs)
Note: Any IMU with a driver that publishes to sensor_msgs/Imu |
|
Global Positioning System (GPS)
Note: Any GPS with a driver that publishes to sensor_msgs/NavSatFix |
|
SUPERVISOR INTEGRATION AND TROUBLESHOOTING
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.