[Bug]: Trajectory provided sometimes starts at origin when leaving lift
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- data-visualization, robotics
Research direction
Start with the hotel world simulation demo and the trajectory generation path used when a robot responds to a request from a lift waypoint. Reproduce the patrol between L1 and L2 with many loops, using the linked rmf_visualization logging branch to inspect segments whose coordinates contain zero values. Done means lift-origin trajectories consistently begin at the lift waypoint coordinates and no rogue segment is visualized.
Written by the indexing model from the issue text.
Description
Before proceeding, is there an existing issue or discussion for this?
- I have done a search for similar issues and discussions.
OS and version
Ubuntu 22.04
Open-RMF installation type
Source build
Other Open-RMF installation methods
No response
Open-RMF version or commit hash
main
ROS distribution
Humble
ROS installation type
Binaries
Other ROS installation methods
No response
Package or library, if applicable
No response
Description of the bug
While running the hotel world simulation demo, by running robots up and down the lifts, there is the rare chance that a trajectory segment starting from (0, 0) or (0, #) or (#, 0) will be produced. It is hard to reproduce and goes away on it's own in a few seconds.
Sometimes only either x or y values will be 0, while some times both are 0.
Steps to reproduce the bug
Hard to reproduce
- Run simulation demo of hotel world (perhaps add names to waypoints near the lift to make repeating going up and down faster)
- Run a patrol task between a waypoint on L1 and L2 with a great number of loops
- When a robot trajectory is generated to respond to a request, where the trajectory starts from the lift waypoint, it has a small chance of being produced.
I logged it a little using https://github.com/open-rmf/rmf_visualization/tree/ac/zero-segment
Expected behavior
Trajectory segments should start from the lift waypoint coordinates and not anywhere with a zero coordinate.
Actual behavior
Sometimes the first segment of the trajectory starts from (0,0), which causes a visualization of the rogue trajectory
Additional information or screenshots
Sorry for the bad ss quality,
How we get the trajectory from the dashboard, this is the case where only x was 0
https://github.com/open-rmf/rmf_visualization/assets/5383623/4408e51e-b1dd-4021-900d-6586ed5eeb9b
- Dominant language
- C++
- Stars
- 32
- Forks
- 23
- Avg merge
- 37m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-rmf/rmf_visualization
-
Visualization serverOpenenhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
linking errorOpenbug
Difficulty 3/5 1-2 days Newbie friendliness 35/100
open-rmf/rmf_visualization#42 · 4 comments ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in open-rmf/rmf_visualization
Similar issues
-
bug engine::whispercpp runtime::rocm wg::platform-core
Difficulty 1/5 Under an hour Newbie friendliness 78/100
lemonade-sdk/lemonade#4168 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ROCm/rocm-libraries#15866 ·
Maintainers usually reply within 2 days
-
[Bug] export_build_environment admits its output directory only after the export ran in the build computerPossibly taken @viniciusdsandrade claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug required hardware test
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ReyeMe/SaturnRingLib#148 ·