dimensionalOS / dimensionalOS/dimos
Nav wishlist
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 4.5k
- Forks
- 808
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 233
Description
why
This will be used for:
- XXXXXX redacted
- Aoki
- any future livox integration.
Nav is a critical component and biggest unknown for me personally atm
preliminary wishlist
-
proper dimos integration
dimos docker module (auto downloaded, auto built) noto_rosconversions but correct ROSTransport integration -
map load
what's the format? Ideally voxel grid (pointcloud2) might want to support occupancygrid also but can write a converter? idk -
relocalization on the loaded map
how do frame_ids work exactly? does our base_link jump? does world->map jump? etc
how does this interact with local controllers, make sure local controller donesn't think the robot teleported -
robust in dynamic envs, no polution of local map when navigating if people are walking around the robot, in my tests walking around G1 would capture it forever because it thought space got occupied around it
above are critical things we can't move at all without, below are things we should have a clear path towards, no optional "nice to haves" actually here
-
map save
what's the format? Ideally voxel grid (pointcloud2) -
dynamic global map
Immediate voxel deletions and aditions based on the changes in the environment.
so not this: https://discord.com/channels/1341146487186391173/1357833666751107174/1418758974848766024dimos --replay --no-dask run unitree-go2
Does this. if this is an issue for ROS side, we can potentially use ROS only for odometry via fast-lio and nothing else, use my global mapper?I can also solve relocalization on my end with O3D ICP, this worked ok in my initial tests but needs more research and confirmation
-
to_rosmethods and ros imports to be removed from the codebase
todo
agree on above, timelines, and create a ros nav module spec
there is an option of running only fast-lio, maybe voxelizer/decimation for lidar, and everything else on dimos stack
https://github.com/BurhanMuhyiddin/FAST-LIO-NON-ROS fast lio might not need ros. voxelizer very easy to write in cpp or even cuda
Contributor 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.
Research direction
No implementation files or tests are named. Start by reviewing the wishlist and the linked FAST-LIO and replay references, then agree on scope, timelines, and a ROS navigation module specification; done means the team has a decided, actionable plan rather than an open-ended list of navigation requirements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, docker, python
- Domain
- robotics
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100