Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X and Y value in traffic editor is different from nav_graph generated by compilation #391

Open
destkk opened this issue Sep 19, 2021 · 4 comments

Comments

@destkk
Copy link

destkk commented Sep 19, 2021

Ubuntu 20.04
Ros2 Foxy

I am trying to create a 3 levels map in traffic editor using a 3 different level floor plan + map created by a robot. I have overlay the robot map and keying in an offset so the origin (0,0) for all 3 levels are the same.

The waypoints that have been created for the first floor are accurate when I compare the x and y of the waypoint in traffic editor and nav_graph generated after compilation.

However, the waypoints for the 2nd and 3rd floor are different in terms of the y value has an increasing difference as the waypoint gets further from the origin.

I have added fiducials for all 3 floors to make it align but the fact is due to the robot mapping all 3 levels are not exactly aligned with one another.

May I know in order to resolve this do I have to rotate the map to make it align with each other for me to add the fiducial? Or is there any other suggestions that I could resolve this.

@codebot
Copy link
Contributor

codebot commented Sep 19, 2021 via email

@destkk
Copy link
Author

destkk commented Sep 20, 2021

Indeed, fiducials are the intended way to address this situation, which as you mentioned is unavoidable when aligning floors. I realize the fiducial tool is not well documented at the moment. The “trick” to making it work is that each fiducial that you want to be aligned must be named the same on all levels. For example, if one fiducial is a pillar of a car park, it should be named “carpark_pillar” (or some other string) on all levels in which it appears. To debug the fiducial alignment, the build log for the nav graph generator should contain the names of the fiducials that it found and how they are paired to generate constraints for the alignment process. Note that at least two common fiducials are required in order to solve for all parameters (x, y translation, scale, and yaw rotation). The more fiducials you add, the better, to compensate for mapping errors. Depending on the size of the space, I would suggest starting with three or four.

On Sun, 19 Sep 2021 at 7:55 PM, destkk @.***> wrote: Ubuntu 20.04 Ros2 Foxy I am trying to create a 3 levels map in traffic editor using a 3 different level floor plan + map created by a robot. I have overlay the robot map and keying in an offset so the origin (0,0) for all 3 levels are the same. The waypoints that have been created for the first floor are accurate when I compare the x and y of the waypoint in traffic editor and nav_graph generated after compilation. However, the waypoints for the 2nd and 3rd floor are different in terms of the y value has an increasing difference as the waypoint gets further from the origin. I have added fiducials for all 3 floors to make it align but the fact is due to the robot mapping all 3 levels are not exactly aligned with one another. May I know in order to resolve this do I have to rotate the map to make it align with each other for me to add the fiducial? Or is there any other suggestions that I could resolve this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#391>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIFDWQCPN3PWEINK2F6OSLUCXFTJANCNFSM5EKIJ7DA .

Hello. Thanks for the prompt reply. Please refer to the screenshot below for the 3 maps mapped by the robot. I have tried to add the fiducials for the 3 levels using the lift as the reference point but apparently i still face the same issue as mentioned above. The nav_graph of the 1st floor is accurate while the other 2 is not.

Screenshot from 2021-09-20 10-03-59
Screenshot from 2021-09-20 10-04-01
Screenshot from 2021-09-20 10-04-03

For example, you can see the screenshot below for the x and y value of L2 for this particular waypoint, x = 35.12, y = 4.473.

But according to the nav_graph it shows

      - 34.98805463852676
      - 5.074628842552811
      - {name: WP27}

Screenshot from 2021-09-20 10-06-52

Another waypoint is x = 76.49, y = 17.

But according to the nav_graph it shows

      - 76.16944644317378
      - 18.23107428374425
      - {name: WP33}

Screenshot from 2021-09-20 10-09-20

I am not too sure what steps should i take to resolve this issue.

@codebot
Copy link
Contributor

codebot commented Sep 20, 2021

I guess I don't totally understand the issue -- is there a problem with the generated nav graph (either in simulation or in real-world experiments), or is it primarily a question as to why the numbers are different in the traffic-editor GUI versus the generated nav graph?

As to why they are different: the two coordinates are doing different things:

  • The GUI level-alignment is simply there for convenience sake, so that when you change levels, you don't have to pan/zoom the map again. For example, if you're looking at a lift shaft on L1 and then click L3 in the levels panel, the display will pan/zoom the L3 image so that it's aligned in the same place. However, it does not rotate the floorplan image of L3; it only pans/zooms. The GUI alignment is there just for convenience when changing levels. The "properties" panel showing x/y meters is an ultra-simplistic calculation that just uses this calculated scale and offset. This means that distances in the traffic-editor should be preserved (if you click a lane it should calculate its length), but the absolute coordinates of non-reference levels will be somewhat different from the nav graph, with the difference depending on how much the floorplans have to rotate in order to align their fiducials. The underlying assumption in the GUI is that the building floorplan image is already rotated to a "canonical" view angle that building operators are used to seeing (for example, with the major corridors oriented horizontally on the image), and the GUI does not rotate the floorplan images, to prevent confusion from how people are used to orienting the floorplan image. (This assumption may be wrong, and we can revisit this if desired.)
  • The nav graph generator does a more complete alignment solution that includes yaw as well as scale and translation. As a result, when dealing with hand-clicked fiducial points, the solution will be slightly different, because the floorplans will likely rotate slightly in order to align the fiducials as close as possible. I suspect this accounts for the differences you are seeing between the traffic-editor GUI and the generated nav graph.

Thank you for providing the screenshots. A few questions/suggestions:

  • I see that there is a significant difference in scale between the reference level (L1) and the other levels, especially L3. Were they mapped with different scale settings, or do those scales emerge from architectural drawings rasterized at different resolutions?
  • I'd suggest to place the fiducial marks in "very different" places in the floorplan. Basically you want the furthest-separated points that are recognizable in all the floor plans you want to align. This reduces the effect of rasterization and "click accuracy" when placing the fiducial mark, and should make the resulting solution more robust.

@codebot
Copy link
Contributor

codebot commented Feb 8, 2022

This issue may end up being related to #419 , where the coordinates shown in the "x(m)" and "y(m)" fields in the vertex properties panel are scaled, but not translated, by the world transform of the level in the generated simulation model and navigation graph. I'll find a way to compute the "fully translated" vertex coordinates, so that they will match what appears in the output products of the build process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants