This project is the implementation of Robofleet: Open Source Communication and Management for Fleets of Autonomous Robots
as presented at IROS 2021.
Citation:
@inproceedings{sikand2021robofleet,
title = {{ Robofleet: Secure Open Source Communication and Management for Fleets of Autonomous Robots }},
author = { Kavan Singh Sikand and Logan Zartman and Sadegh Rabiee and Joydeep Biswas },
booktitle = { Intelligent Robots and Systems (IROS), IEEE/RSJ International Conference on },
year = { 2021 },
pages = { 406--412 },
doi = { 10.1109/IROS51168.2021.9635830 },
}
Arxiv link: https://arxiv.org/pdf/2103.06993
IEEEXplore: https://ieeexplore.ieee.org/document/9635830
This project aims to create a system that enables ROS-based robot-to-robot communication, as well as visualization of robot data via a web-based frontend. Robots will run a client application to exchange data with a central server.
Each physical robot has existing control software, which publishes messages to the robot’s ROS topics. The Robofleet client will exchange these existing messages with the Robofleet server. Using Robofleet, this software may also subscribe to ROS topics for information from other robots or control messages.
This project targets the ROS 1 framework.
You will need to set up different components of Robofleet depending on your use case.
Make sure to clone submodules, using git clone --recursive https://github.com/ut-amrl/robofleet
.
robofleet_client
enables a robot to exchange ROS messages with robofleet_server
. To set up a new robot with Robofleet:
- Clone recursively
robofleet_client
- Choose a ROS Namespace for the robot (e.g.
/ut/testbot
) - Follow the configure and build instructions in the
robofleet_client
README
file- Make sure to read the inline documentation about configuring message types and topics.
- Extend an existing ROS node to publish
amrl_msgs/RobofleetStatus
messages to thestatus
topic. This will list your robot in the web visualizer, though it is not strictly necessary.- Alternatively, use
robofleet_client/scripts/basic_status.py
to quickly list your robot.
- Alternatively, use
- Run the
robofleet_client
in your robot's namespace (e.g.ROS_NAMESPACE="/ut/testbot" make run
) - Grant your robot permissions in the config file for
robofleet_server
- When trying to view your robot details in the web visualizer, remember to sign in if necessary!
robofleet_server
enables broadcasting of ROS messages between many clients (robots and visualizers) over the network. To run the server:
- Clone
robofleet_server
and follow the build instructions in itsREADME
file - Start the server with
yarn start
robofleet_webviz
is a browser-based Robofleet client that presents a GUI for many kinds of ROS messages received from robofleet_server
. A special RobofleetStatus
message enables a listing of all connected robots. To run the web visualizer:
- Clone
robofleet_webviz
and follow the build instructions in itsREADME
file - Run the development server with
yarn start
See information about "direct mode" in the robofleet_client
README
.
Most development tasks are isolated to each component of Robofleet. However, there are some tasks that require coordination across all components.
To exchange ROS messages over the network, with support for message metadata and unusual kinds of clients (such as the browser), Robofleet needs a structured message encoding format. Robofleet currently encodes messages using Flatbuffers. For details on how ROS messages are encoded in Flatbuffers, see the README
for msg2fbs
.
Imagine that you want to visualize some new message type, my_viz/Marker
. First, build each of the Robofleet components as explained in each of their README
files. Then, follow these steps:
cd msg2fbs
- Add
amrl_msgs
toROS_PACKAGE_PATH
and ensure that it has been built.export ROS_PACKAGE_PATH=../robofleet_client/amrl_msgs:$ROS_PACKAGE_PATH
- If your new message type is also in a local (not installed) package, make sure that it is also in your path.
- You can use another copy of
amrl_msgs
, but you must ensure that both copies stay in sync.
- Add the ROS name of the message type (e.g.
my_viz/Marker
) to the top of themakefile
make
to generate code and copy it into each Robofleet component.
- Add
cd ../robofleet_client
- Edit
src/config.hpp
to callcn.configure()
once per message type and topic, as shown in the example configuration. For example:c.configure(SendLocalMessage<my_viz::Marker>().from("/my/topic").to("my/topic"))
Remember to include the ROS headers for your new message type.- Make sure to read the inline documentation.
- Edit
encode_ros.hpp
to specializeencode<>()
for your new message type. See existing specializations for examples.- It helps to set up autocompletion in your editor.
- Robofleet only uses the
metadata
attribute on the root message type. For example, ifmy_viz/Marker
contains astd_msgs/String
, you should set themetadata
attribute of thestd_msgs/String
to0
(null). - Remember that you can use
encode<>()
recursively using the provided helper functions. - Make sure to return the raw offset (the
.o
attribute) of your root message object.
- Edit
decode_ros.hpp
to specializedecode<>()
for your new message type.- Again, you can decode recursively using provided helper functions.
make
to test your changes- Linker errors generally indicate that you did not correctly specialize
encode<>()
ordecode<>()
.
- Linker errors generally indicate that you did not correctly specialize
- Add an example that works for normal usage to
src/config.example.hpp
make format
to clean up your code- Commit the changes.
- Edit
cd ../robofleet_server
yarn build
to test the new schema code.- Commit the changes.
cd ../robofleet_webviz
yarn build
to test the new schema code.- Commit the changes.
cd ..
- Add the updated submodule commits and the changes to
msg2fbs
. - Commit the changes.
- Add the updated submodule commits and the changes to
All done! Now, you can consume the new message type in robofleet_webviz
, as well as transmit and receive it with the robofleet_client
.
Robofleet is used as a part of a number of other projects, including an augmented reality interface powered by unreal engine: The source code for this client is available here:
When JavaScript support for Flexbuffers is added, it would be possible to switch from Flatbuffers to Flexbuffers encoding with a mostly-unchanged architecture. This would:
- Eliminate the need to maintain a schema and generated code
- Move the burden of schema conformance into application code (no schemas means implicit schemas, defined by how message fields are accessed in code.)
- Allow the encoding of all message types automatically by the robot client*
- handling dynamically-typed ROS messages in C++ is probably possible using ShapeShifter and ros_msg_parser (formerly ros_type_introspection)
msg2fbs
demonstrates how to encode arbitrary message types usingrospy