The Neato Runner has a singular easily tunable parameter that changes the number of goals. It does this by changing the length of a circular buffer that is powered by a circular shifter that deals with multiple instances of the RRT class, saved path object, and saved waypoint directions object - one copy for each goal. These could be wrapped into a single class or perhaps the path and directions objects could be stored within the RRT class; however, the legacy code was designed in this way and it was simpler to maintain that architecture than change it retroactively. Each of these objects is stored as an attribute in the Neato Runner node with a descriptive prefix and then a numerical suffix that counts up from zero. The Neato follows the path given by the first goal, but then has the future goals pre-planned to allow for seamless transitions. It also allows the final goal to be recomputed for as long as is necessary without inhibiting the robot’s performance. The image below shows what the circular buffer looks like for the RRT objects.
Whenever the Occupancy Field is updated, there is cause for concern that the new frontier may have revealed an obstacle that invalidates a prior goal or path. These two conditions are checked.
If a goal is within 0.5 meters of the current position, it is considered achieved and the Neato shifts all objects to start guiding towards the next goal. The old goal is added to the back of the circular buffer and is reset randomly.
The goal is reset based on either the prior goal or the current Neato position, depending on which goal is being reset.
We tried tuning the Neato control algorithm to be better, but we found that we faced a lot of unforeseen challenges going from simulation to reality, so we were not really able to make a single tuning that worked. We attempted PID to go from waypoint to waypoint, but we only ended up being able to implement P in a stable manner. Some of the issues we faced were angle wrappings where if the desired heading and current heading were on opposite sides of the x-axis, then we would end up with undesirable control signals pointing in the wrong directions. We fixed this by implementing a function that detected and mitigated wrap-around errors. We also struggled to choose the correct waypoint to follow. What we decided on was that we would scan a path and weight each waypoint based on its distance and angle deviation from the current trajectory. We would then path plan to the waypoint with the lowest weight. We had to include some in order to prevent the robot from revisiting already completed waypoints by backtracking; otherwise, it could decide to circle the same waypoint. The weighting algorithm, although uniquely tuned through testing to this particular use case, can be thought of exactly like goal resetting.