Late to the party, but here’s my $0.02. Generally, +1 to all of Geoff Biggs’ coimments. I’d like to see:
- More pluggability in the elements of the nav stack, and the ability to hot-swap implementations.
- A common API that will allow people to add their own underlying representations.
- The ability to handle time. I’ve been toying with the idea of a map that changes throughout the day (as corridors become congested, and such), so the ability to integrate this into the system would be important to me as a specific use case.
- The ability to run more than one algorithm at a time, compare the results and mux them. This is important for localization, where it can be used to compare the performance of two algorithms, or to use different algorithms at different time.
- Factoring things up as finely as possible. As Geoff pointed out, this should be more lightweight in ROS2
- Ability to develop in Python or C++.
- Use floats or doubles as the underlying representation, not some fixed-point hack. Actually, it might be nice to use arbitrary underlying representations (of probabilities).
- Some more modern algorithms from the literature.
- Being able to swap maps in and out of core seamlessly, so that I don’t have to keep all of campus in memory at the same time.
- Multiple floors in a building. Hybrids to let me get from one building to another.
I’d be interested in having our group here at Oregon State help with some of this, depending on where it goes.