-
Notifications
You must be signed in to change notification settings - Fork 38
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
Poop topo nodes #187
base: humble-dev
Are you sure you want to change the base?
Poop topo nodes #187
Conversation
Hi @ibrahimhroob , for the AOC project, we use the repository at https://github.com/GPrathap/topological_navigation.git (branch: humble-dev). Please send it there instead. Thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good in general. May I request changes to the README to explain what this does?
Also, is it possible to check that a waypoint does not exist yet (e.g. check if the new waypoint is within the verts
of an existing one, and only create a new one if none exists? Then, can we make it so that the last waypoint where the button was pressed (could be an old or a new one) is used to create also an edge to the current one? Or is that too tricky?
Also, any idea what causes the assertion failure in https://github.com/LCAS/topological_navigation/actions/runs/9923089501/job/27412865755?pr=187#step:5:2365 ? |
I am not sure as it did pass the humble distro, but is seems something related to |
Might it be worth including feature to either set the vert radii proportional to how far the back trigger is pressed in; or to have a few different options assigned to different buttons? |
Hi @marc-hanheide, yes I can do that. I'll add two options:
|
Thanks for this suggestion, very nice idea, I will see what I can do ... |
@GPrathap can we stop using personal forks please. Nothing against branches, I understand they are needed, but team members should work in the team's organisation so we can see and collaborate more easily. @ibrahimhroob is right that a PR should go against the upstream. Any fork can still pull from upstream then. |
I do have different proposal, instead of creating the edges during the session, I propose to create them as post process step, for that I will be using interactive markers at rviz where I can click two nodes to create edge, the order of clicking will determine the edge direction. |
Screencast.from.21-07-24.19.38.01.webmIn this illustration I am creating some random nodes using |
Screencast.from.22-07-24.12.40.55.webmI do have another proposal that is to create a simple GUI window that should the attribute of the selected node and edges and offer to modify them through the GUI. In the above video I am only should the clicked marker pose but it is easy to expand it for other tasks, like changing the name/pose/edge actions etc... |
How does this relate to the existing RViz tools we have for toponav? Have you had a look at those existing ones? It feels like we’re reinventing what we used to have? Just checking if you had reviewed what’s there. |
also, can you figure out why the CI is failing? Is it an outdated test, or a race condition? |
The existing rviz tools were fairly over-engineered for what they achieved, I think this approach works much better than they did. If a standard collection of topics are used (and they just happen to be defaulted to the same topics as the default rviz tools), it could be built into an API for standardised dashboard interfaces. |
I agree they were “over-engineered”, but I think we still need a “coherent” toolset. |
I just had a look at: https://github.com/LCAS/topological_navigation/tree/humble-dev/topological_rviz_tools, but it seems all still in ROS1? and has not be migrated to ROS2 yet. But I do agree all of those tools need to be in one place. |
I think for this manual topo map I will keep it as simple as possible and just add the edge creation tool by clicking on two nodes with no GUI or other complicated things (which will use the stander API of RVIZ2). |
Please correct me if I'm mistaken, but it appears the failure occurred here, which corresponds to this test:
However, when I ran it again, the test passed successfully. I also ran the tests locally on my machine, and they all passed. Could this be a "race condition"? If so, would increasing the test timeout resolve the issue? When the test fails it took 25 seconds: However in the successful run it took 8 seconds. While on my machine it took 6 seconds: So I believe this is timeout issue with the test. |
Looks like a race condition… We need to check why the tests keep failing. |
Ping |
I did increase the test timeout and it solved it |
What type of PR is this? (check all applicable)
Description
In this PR, I reintroduce the manual topo map creation tool originally developed by @sergimolina and migrate it to ROS2. Follow these steps to use the tool:
Launch the Tool:
manual_topomapping.launch.py
.Add a New Node:
LT
andA
buttons simultaneously.node_thresh
. Refer to the figure below for button mapping.Remove a Node:
LT
andB
buttons on the joystick.Save the Topo Map:
LT
andY
buttons on the joystick.tmap_dir
, which can be configured in the launch file.Please find the attached video below for illustrating how to use this tool.
Related Tickets & Documents
QA Instructions, Screenshots, Recordings
Screencast.from.13-07-24.22.27.44.webm