¶ IGVC 2021 Software Architecture
¶ Goals
These were the goals of the software over the two years it was being developed. It is important to understand the goals to understand the decisions made behind the architecture and features implemented.
¶ Modular to addition or removal of algorithms, features, or hardware.
This was accomplished through the use of ROS and separation of features into nodes. Each element of the software has a separate node and can be replaced with nodes that are equivalent in how they interact with the rest of the system (that is, they have the same publishing and subscribed topics).
¶ Flexible and configurable to competition environment.
At the top of many nodes are configuration parameters to allow the code to be adapted. For example, many of the vision parameters and tunable.
¶ High-level overview
Below is a screenshot from rqt_graph showing the nodes and the topics between them in the final code iteration used at competition. One exception is that the igvc_display node was left out as it subscribed to many topics and cluttered the image while not being useful for understanding the architecture.
The software as a whole can be considered solving for the function f(x) -> y that maps the state of the robot x to commands it should follow y. Throughout the rest of this document, we will explore what x, f, and y are and how they are implemented in the code.
¶ State Estimation, x
The robot employs the following sensors which produce the following information
- Camera: The camera produces a color view of the environment in front of the robot. For the IGVC21 codebase, this was used to develop a map of obstacles vs non-obstacles.
- IMU: IMUs use a fusion of accelerometers, gyroscopes, and magnetometers to estimate mainly orientation. IMUs are finicky and are subject to error if certain ideal conditions are not met. In particular, the magnetometer requires a stable magnetic field which is not easily found in a robot due to current running the motors or metal screws, casings, etc.
- GPS: GPS units use information broadcasted over radio waves to determine an accurate estimate of time. By receiving from multiple GPS satellites, we can produce an accurate estimation of our Earth-referenced position as well. This is accurate to about 5 meters.
- Encoders: Encoders are a highly accurate way to measure the rotations of the drive axles. Encoders can therefore be used to estimate position and orientation travelled by the robot but assumes that the wheels do not slip.
- LIDAR: LIDARs produce accurate measures of distances in a plane relative to the robot. LIDARs are particularly useful for detecting obstacles that the robot may want to avoid. Because LIDARs rely on transmitting and detecting light, large sources of stray photos such as the Sun may completely saturate a LIDAR's sensor.
All these sensors combine to grant us many different views of the environment around the robot. Unfortunately, these views are not congruent and therefore processing must be done to create a common understanding of the robot's state. To accomplish this, the robot feeds all the data into a common node which then combines the data into our state estimate. There are many algorithms that can accomplish this, but we chose to use an Extended Kalman Filter (EKF) which is seen as the /ekf_with_gps node.
TODO: Describe more about the EKF and our state here