Finish map annotator UI

[WxyElaine]

Now we have a browser-based SVG editor. I removed the rws-app branch and added this branch so that this one is only used for developing map annotator.

[nickswalker]

Notes from testing:

• I like that some example maps are included. Makes it easy to play with
• I found it confusing that the "save" button seems to both update the database and download the modified SVG
• There's no dependency on Fetch, right? If so, this should go in uw_common
• Thoughts around initial workflow: I assume people start with the PGM and the yaml. I see in the repo that the SVGs are vectorized versions of the PGM. I don't think this is the way to go, because it results in duplicating the geometry information from the PGM. Updates to the PGM (cleaning up noise etc) would cause these to go out of sync. This also requires people to run some process on the PGM in order to get something they can upload. Is it possible to have them upload the PGM and YAML files and then build the wrapper SVG for them?
  • SVG supports externally linked images with the <image> tag, but I see that Chrome doesn't render externally linked PGMs. Still, this would be give a way to avoid duplicating the map itself: user uploads PGM, dump PGM onto a canvas for display. Allow drawing of annotations. When user downloads, put all annotations into SVG format, then add an tag referencing the uploaded PGM.
• I like the HUD for the X Y coordinates. Getting them into map frame is going to require the YAML information I think
• The modals that appear on adding a pose or a region would be more appropriate as tool tips
• It was tough to work with the smaller map. The distance between the label and the annotation being large is a big factor. The ability to zoom in would be helpful
• I like that region labels can't be moved, but because they stay fixed they can end up arbitrarily far from the annotation they belong with. This could be fixed by having them update to be beside end point 0 or something
• Haven't figured out how to reproduce it, but sometimes poses disappear while editing a region's end points

[nickswalker]

Map rename is implemented now: https://github.com/utexas-bwi/knowledge_representation/commit/3ed5cb9c253b7dabdf7f3a207866e65eb4cd6e91

[nickswalker]

I've added a file->db loading functionality to knowledge representation here. It's based on the format of the SVG as of the latest commit on this PR.

Some comments on the format now that I've played with the sample annotation you sent (shown in Inkscape below):

• Everything was really easy to machine read. The parsing logic is simple :+1:
• I'm surprised at how well the base64 encoded background image trick works; it's great that it's viewable in chrome now. I wonder if it'll render in the GitHub UI? That would be an awesome bonus
• My model of how people will interact with the annotation file, based off my experiences with BWI and AustinVilla, is that most will just need the ability to view a full annotated map and then add/edit poses. These annotations are committed to the team repo so they're shared with everyone, and when someone needs to make a tweak, they often do it in a hurry. It's important that we have a good local-editing solution to facilitate this. Inkscape is really just one option, but another would be to make running this interface and editing a local file (potentially without any connection to database or even a running ros node) a bullet-proof, works-as-soon-as-I-clone-the-repo solution. I haven't yet tested out the local-editing experience with the latest commit, so for now, some thoughts about how editing the Inkscape editing experience:
  • Points work really well. It's easy to drag around the group of the dot and the text.
  • Poses and regions, which are specified as lines and polygons, aren't directly editable in inkscape. This seems like a really dumb Inkscape limitation to me, especially since they can be made editable just by hitting a button that converts them to a path... But we could work around it by representing both of these annotation types as paths
  • Having the dots on the polygon points looks good and makes the shape clearer, but it makes editing the shape harder because moving a point on the path doesn't automatically move the dot. I would recommend not saving these dots when downloading the SVG, and instead just drawing them in the UI
  • The radius and line-widths feel too big in the inkscape UI, where it's easier to zoom in on things. This makes it feel harder to precisely place a point, because the width of the dot is the equivalent of 35cm in map dimensions (0.05 pixel/m * 7 pixel diameter). At least for the downloaded copy, would recommend reducing stroke weights and the dot radius.
  • It's unfortunate that SVG doesn't support having strokes inset along the boundary. Even with the region stroke reduced, it could be difficult to visually check that two regions are lined up right next to eachother with no space between. This is a somewhat important sanity check to prevent the situation where the robot needs to known what room its in, but happens to be on some thin boundary between rooms and fails because it's not actually in any annotated room. I'll have to do more testing on the alignment experience

[WxyElaine]

• It seems that GitHub UI cannot decode base64 image, only the annotations are visible. See this file
• The current version of interface cannot be used without the ROS node, because there's a service call to the database which checks for duplicate entries every time the user tries to add an element. But this interface can be used locally (no other things need to be running, no database or ROS node) if I make some small changes. Maybe I can add a button on the interface which let the user switch between interface+database mode and interface-only mode? If this solution sounds good, I think we don't need to convert line and polygon to path since we can do local editing using this interface?
• I will adjust the stroke width, and also try to add zoom in/out functionality

[nickswalker]

Hm it actually does render for me in Safari and Chrome on macOS 10.15.

Sure, a local mode sounds good, and in that case the annotation format is fine as is.

[WxyElaine]

Hm it actually does render for me in Safari and Chrome on macOS 10.15.

Umm...the background doesn't show up on my Safari (macOS 10.15), but does show up on Chrome and the Safari on my phone.

[nickswalker]

I tested out the latest version by annotating the house sim (result here). It's still a little uncomfortable to navigate around the map because the view of the map is small, and I kept holding middle mouse button to try to pan and accidentally moving regions, but I was able to make and save all the annotations I wanted. We should work to merge this in now.

I did have to comment out an import, and then the line that removes the robotpose from the svg before saving (something about the element not being a child of the clone, happened after a couple saves). Somehow some poses appeared without a head on insertion, but they worked normally otherwise.

[WxyElaine]

I fix the bug with removing robot pose from download copy in the latest commit.

I worked on all the frontend updates in Chrome, and they all worked fine. But I just tried the interface in Firefox, and Firefox calculates the event.offsetX and event.offsetY different from Chrome, so that the drag&drop behaves wired in Firefox. Which browser did you use?

[nickswalker]

This will land in homeskies/uw_common#16