-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Welcome to the ServiceRobotControlStack wiki!
This is a full control stack for Kobuki Turtlebot2 with a forward facing Hokuyo URG Laser Scanner, allowing for visitation of arbitrary (x, y) points on a map. A key feature of this control stack is it uses vector maps instead of grid maps, allowing for higher precision and more flexibility in obstacle representation than using occupancy maps.
This project depends on two external dependencies.
This library provides hot reloading of Lua config files. This allows for parameter tuning on actively running robots without requiring re-compilation or even binary restarts. All configurable parameters in this project are set using config-reader. See the README.md for more information.
This library provides many core computational geometry and math functions with a focus on robotics.
The stack is structured as a control loop, with information flowing through each of the following sections in order.
Code exists in control_stack/include/cs/localization and control_stack/src/localization.
This system is initialized with the approximate start location of the robot on the map. Given an odometry or laser scan update, the localization system updates its localization estimate and emits an MLE for robot's pose on the map. This system is implemented as a standard particle filter (Probabilistic Robotics, Chapter 4 Section 3). Tune-able parameters are set in control_stack/config/nav_config.lua, under the pf table.
Code exists in control_stack/include/cs/obstacle_avoidance and control_stack/src/obstacle_avoidance.
Observations are matched against the map using the MLE from the localization system, with observations poorly explained treated as observations from short-term (non-map) obstacles; short-term observations are clustered using a single pass clustering technique to form a vector representation. The map and the short-term obstacles are then presented for consumption as obstacle sets. Tune-able parameters are set in control_stack/config/nav_config.lua, under the od table.
Code exists in control_stack/include/cs/path_finding and control_stack/src/path_finding.
Using the obstacle detection system's map and short-term obstacles, the robot plans paths using a standard RRT (Rapidly-Exploring Random Trees: A New Tool for Path Planning. S M LaValle, 1998) which then employs path smoothing. Paths are obstacle-aware, but not kinodynamics aware. The base PathFinding class provides functions that allow for reuse of existing paths if possible. Tune-able parameters are set in control_stack/config/nav_config.lua, under the path_finding and rrt tables.
Code exists in control_stack/src/main/nav_node.cpp.
Implemented as a simple P controller in X and theta space, with the objective of driving to the second waypoint in the given planned path. Commands are kinodynamics aware but not obstacle aware. Tune-able parameters are set in control_stack/config/nav_config.lua, under the control and limits tables.
Code exists in control_stack/include/cs/obstacle_avoidance and control_stack/src/obstacle_avoidance.
Given a desired command, this system ensures that robot will be safe for the next N timesteps. Uses the standard velocity space planner (Probabilistic Robotics, Chapter 5 Section 3) to avoid collision with obstacles as a result of the lack of obstacle awareness from the motion planner. Tune-able parameters are set in control_stack/config/nav_config.lua, under the od, control, and limits tables.
The control stack is configured as a set of ROS nodes. nav_node is the singular control node, deployed both in simulation and on the actual robot. simulation_node which is a drop-in replacement for the real robot's sensors in order to allow for testing on the desktop and in the CI system.
nav_node is configured to accept ROS LaserScan and Twist odometry readings and emit ROS Twist commands on the topics setup for the Kobuki Turtlebot2. This node optionally publishes several debug topics if they are enabled in the associated components.
simulator_node is designed to be a drop-in replacement for the robot in order to allow for desktop testing as well as testing in the CI system. Simulation parameters are configurable in control_stack/config/sim_config.lua, allowing for features such as variable sensing or activation noise, as well as the publishing of the ground truth for simulation based testing purposes.
Development of the control stack is supported by both local and remote tooling. Before every commit, code is linted by cpplint.py in order to ensure conformity to the Google C++ style guide, formatted with clang-format to ensure uniformity of presentation, and then built to ensure local build success. Tooling then also ensures proper author attribution and date settings with copyright header checks. Once a commit is pushed, a Jenkins CI server runs a build pipeline. This pipeline again runs the above formatting and style checkers, builds the code in Debug and Release mode for both clang++ and g++, and then validates the code by running a series of integration tests of nav_node against simulator_node, first with standard configuration and then under valgrind, a memory error detector, in order to find and catch memory errors as they happen. Code that fails triggers a notification in the #newstack-ci channel of the servicerobots Slack.
The clustering algorithm needs to be improved for thin objects and the maintenance of the new versus old plan system needs to be updated to handle partially executed plans.