It’s my second-to-last week, and wow did I get a lot done! To begin, I will cover our work flow as well as what I have so far with the Define Zones and Map Registration programs. In the first step, you have a semantic map or a floor plan to work from. This is a (very) loose floor plan that I drew of the lab. On this image, you can place markers to form zones, and each zone can be saved with its own privacy type. At the current moment it still only handles 4 points, but this should be expandable to any number of points as long as we can register them. You can define the zones, specify their name and privacy type, and also export all of them into a YAML file.

The next step is translating the semantic floor plan/map into the SLAM map generated by the robot using Map Registration. In the below example, using Jonathon’s Triangle library we can deal with the crookedness and other errors present in the robot’s SLAM map. Once points are selected and paired between the two maps, you can import the YAML file from earlier defined zones program. (As a side note, learning how to use the YAML library as far as importing and exporting data was a really useful thing that I learned how to do this week.) This Map Registration program was developed by both Penn and I. I worked mostly with the User Interface and file IO (front-end), and Penn handled the transformation of points (back-end).

Finally, Alex has developed a package that imports the converted points and places those points as a marker in rViz. Since it shows up in Rviz, it can be used in our remote_nav package which also uses rviz (in other words, the navigator can see these zones and if they can or cannot travel there)
From here, the plan is to make it so that the costmap can be manipulated so that a robot cannot navigate to an area specified as “private”. This can be applied to other types of filters. If the robot was confined to public areas then it would not be allowed to leave zones marked as such.