Map point of interest annotation

[nickswalker]

Most navigation in @Home is to predefined locations, which we'll annotate on top of the robot's pgm map. We want the ability to:

• annotate points of interest (POI) on an existing map via a GUI
• (eventually) annotate polygonal regions of interest (ROI) via a GUI
• store these annotations in a repository and reload them

There is no widely adopted standard for how to do this, so everyone rolls their own stack:

• BWI built an annotation tool which also had special handling of doors (important for office setting). It was an awful QT app. Annotations would bake down into yaml files describing polygons and PGM rasters (example). A special intermediate node would load this data off disk and provide an API for approaching POIs and for checking whether doors were open.
• HCRL made a browser-based GUI to mark points of interest and keep them in a mongo backing store. These can be queried over ROS or directly from the backing store, and then the application can do whatever with them. There is no on-disk representation.
• Homer's tool supports POI CRUD ops over ROS, and has the additional interesting feature of allowing direct modifications to the map via a GUI. Their ROS interface gives a good idea of what it can do. Not clear if there's an on-disk representation for things besides the modified map (which gets baked to PGM)

I think we should plan to leverage RWS (since homeskies/uw_fetch#2 seems to be going well) to serve an interface for live modifications, but how we represent, store and use the annotations in the rest of the system still needs to be resolved. And there still needs to be a way for developers to create and store annotations without an RWS instance or even ROS at all. I'm thinking:

• human-understandable canonical representation; maybe as an SVG file that overlays the pgm so that people can edit them in Inkscape?
• converters that take this data and dump it (or summaries of it) to the Postgres store so we can reason about the annotations. Postgres is "the truth" for the robot. RWS interface modifies Postgres. Querying POI/ROIs -> SQL call. Caller is responsible for things like checking what region the robot is in
• separate converters dump from Postgres to files either periodically or whenever we want so that we can commit this data

[nickswalker]

I verified that Inkscape could work in this setting. Open it up, import the the PGM as a referenced image, resize the artboard to fit, then draw polygons. Use object properties to name them. Can put polygons on layers with different names (e.g. "rooms"). Poses can work as lines with custom markers on the ends. Doors as lines, though matching them with approach poses may mean manually matching their name with the door. All of this bakes to markup we can parse easily, and that we can show and edit in any other SVG friendly tools, including web browsers.

Tagging @YuqianJiang in case you want to follow whatever we develop here

[nickswalker]

After realizing that database systems already handle the basic geometric operations that we'd need for working with annotations at runtime, I started implementing map types in knowledge representation. Poses and points are working now as of utexas-bwi/knowledge_representation@b9b3fe9. The work for loading in annotations remains to be done.

I also found this photo I took during the 2019 competition showing @YuqianJiang working with BWI's tool to annotate an arena map, to attach some visual context for this stuff:

[WxyElaine]

I think the map annotator might probably depends on fetch_api, so I will develop it in the rws-app branch inside uw_fetch for now

[nickswalker]

Hm why?

[WxyElaine]

I’m thinking maybe we want some fetch-specific functions on the interface in the future. But for map annotation itself it shouldn’t rely on fetch stuff.