Requirements
Going back to our overall system requirements, the requirement that is relevant to this behavior is:
The Configuration space generated from mapping shall include all navigable points for the robot and any occupied space must be truly un-navigable.
Therefore, here are the set of metrics for this behavior to successfully satisfy this requirement:
| Requirement | Metric |
|---|---|
| The robot shall execute a smooth trajectory. | Can't quantify, I can tell visually. |
| The robot shall map all possible spaces the robot can occupy to the configuration space. | +-10mm |
| The simulation should have a reasonable speed. | 1x Simulation Speed |
The end result is a C-space saved on disk, whose path is written to the blackboard and can be accessed by other behaviors executed henceforth. Here is how I think this sub-tree should look like.
The mapping behavior is a parallel behavior which ticks both the movement around the table and the behavior that processes lidar data to map. Once any of them return success, this behavior subtree is successful. The "GenerateMap" behavior will never return anything (except for errors which indicate the behavior cannot proceed without fixing something, which we can think about later), Its upto the "GoAroundTable" behavior to return SUCCESS / FAILURE.