# Development topics for Aerial Robotics - Indoor Navigation

**URL:** <https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347>\
**Category:** Aerial Robotics\
**Tags:** wg-aerial-robotics\
**Created:** [February 28, 2024, 5:08am UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347 "2024-02-28T05:08:59Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![botmayank](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/botmayank/32/33091_2.png) [@botmayank](https://discourse.openrobotics.org/u/botmayank)\
**Post date:** [February 28, 2024, 5:08am UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/1 "2024-02-28T05:08:59Z")

</div>

Hey,  
As a part of ROS-Aerial, we’re starting an indoor navigation subcommittee. Let’s use this thread to start ideating on existing projects which can be relevant that we can work on and also any new packages which can help push out an open-source autonomy stack for indoor navigation.

Prior research landscape mapping of autonomy stacks:  
[https://github.com/ROS-Aerial/aerial\_robotic\_landscape/blob/main/aerial\_autonomy\_stacks.md](https://github.com/ROS-Aerial/aerial_robotic_landscape/blob/main/aerial_autonomy_stacks.md)

Informal discussion Discord thread: [Discord](https://discord.com/channels/1077825543698927656/1141902822254850128/1210243245746163752)

Github Kanban page to track development tickets:

> **[Indoor navigation • ROS-Aerial](https://github.com/orgs/ROS-Aerial/projects/4/views/1)**
>
> Indoor navigation

---

<div class="post-metadata">

**Author:** ![KimMcG](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/kimmcg/32/23853_2.png) [@KimMcG](https://discourse.openrobotics.org/u/KimMcG)\
**Post date:** [February 28, 2024, 9:12am UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/2 "2024-02-28T09:12:05Z")

</div>

Thanks Mayank for starting this thread!

I guess my closest experience with this is trying to connect NAV2 with the Crazyflie and multiranger, which I partly succeeded (which I presented at [ROScon](https://vimeo.com/showcase/9954564/video/767140197) last year). At least there were some lessons learned from that:

- Current not a great solution for indoor 3D navigation. The UAV needs to act like a ground robot but this limits the capabilities
- I had a lot of trouble of making it NAV2 work with sparse sensing. Ofcourse a ‘lidar’ with only 4 rangesensors is pushing the limits, but there are solutions that haven’t been converted to ROS that are able to do SLAM with this. Also, indoor navigating quadcopters aren’t big and are perhaps forced to carry less then ideal ranging sensors.
- Visual based odometry (either with visual slam, or an downward facing camera for optical flow) is not well integrated in the ROS framework (at least what I know of), or at least there aren’t default packages for it. It would be nice to get it at the same level as wheel odometry solutions.
- Simulation realism (but perhaps a separate subcommittee needs to be done for this), aerial robotic dynamics could be better.

Don’t see that of me judging the current framework in place, don’t get me wrong. I’m just indicating some pain points that I faced trying to ‘force’ a ros package to work for a platform that it wasn’t designed for, so that created some nice insights. Also I’m sure that just a summer project working on this does not make me the expert on indoor navigation of UAVs but I like making demos and playing around with it:)

These were the github projects I used:

- [GitHub - knmcguire/crazyflie\_ros2\_experimental](https://github.com/knmcguire/crazyflie_ros2_experimental) (now mostly in archive mode)
- [ROS 2 Tutorials — Crazyswarm2 1.0a1 documentation](https://imrclab.github.io/crazyswarm2/tutorials.html) (these tutorials were based on that other project)

---

<div class="post-metadata">

**Author:** ![botmayank](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/botmayank/32/33091_2.png) [@botmayank](https://discourse.openrobotics.org/u/botmayank)\
**Post date:** [February 28, 2024, 4:22pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/3 "2024-02-28T16:22:08Z")

</div>

Yes, VIO is a topic that I’m interested in as well. As far as I know, several implementations were relying on sensors which could do on-board VIO like the Intel Realsense T265 tracking cameras (now discontinued) and directly consuming that into the autonomy ROS packages. Even I have not really seen packages for getting raw sensor data to run VIO on the host side for aerial use cases as such.

One approach could be looking into Nvidia IsaacROS packages like the one for VSLAM and seeing if it already works for 3d/can be extended for aerial use cases.

> **[Isaac ROS Visual SLAM — isaac\_ros\_docs documentation](https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_visual_slam/index.html)**

Another concern I have is about how to tackle varying hardware/resource requirements since autonomy companion computers could vary a lot in capabilities?

One potential way could be to figure out a simulation environment that is usable for such investigations which can allow us to run at least proof of concepts of such packages running on laptops/PCs and then later figure out how they perform on specific hardware.

On the hardware-specific front, there have been some recent interesting implementations of VIO/SLAM with Luxonis OAK-D cameras that I’ve come across.

> **[VIO and SLAM](https://docs.luxonis.com/software/ros/vio-slam)**
>
> This guide covers setting up SLAM projects, on-device SuperPoint for localization, and syncing frames with IMU messages for accurate mapping and navigation.

There’s also a bunch of cool in-camera compute for localization examples that people have pulled off.

> **[Luxonis Documentation](https://docs.luxonis.com/)**
>
> This is an ultimate guide to Luxonis software

---

<div class="post-metadata">

**Author:** ![gajena](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/gajena/32/19119_2.png) [@gajena](https://discourse.openrobotics.org/u/gajena)\
**Post date:** [March 1, 2024, 6:20pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/4 "2024-03-01T18:20:54Z")

</div>

From working with custom/prebuilt(like t265) sensors for VIO, I observed some things as follows:

- T265 has some issues with velocity updates over 7-8 meter altitude but provides some good features out of the box, like a simple implementation of place recognition, which can correct pose drift. Also, it is a stereo cam-based tracking system that provides depth for features while the camera is static. (sadly discontinued)

- I used oak-d-pro with some VIO algorithm. The issue I faced with oak was the imu msg arrival consistency, which can reduce the robustness of VIO algorithms ( also maybe I have to test it correctly since it has extensive custom API, which requires more testing time).

- From my experience with custom VIO sensor

From the perspective of performance vs compute:

- [open\_vins](https://github.com/rpng/open_vins/) performs best in comparison to other SOTA like [vins\_fusion](https://github.com/HKUST-Aerial-Robotics/VINS-Fusion) and also has continuous support and updates from the developer.
- open\_vins can run on a single core on an RPi5 with 20fps 640p, since it uses KLT feature tracking and Multi-State Constraint Kalman Filter (MSCKF) (based on my limited understanding) while vins\_fusion uses bundle adjustment optimization, which is more CPU intensive.
- but vins\_fusion provides some good features that might be necessary sometimes, like robust VIO initialization using SFM, while open\_vins require suitable IMU excitation.
- Both have multi-cam support in stereo configuration or multiple monocular configurations.
- Both can estimate the intrinsic and extrinsic of the sensors online, provided offline calibration is okayish if not great.

From a simulation perspective, I only used [rotors](https://github.com/ethz-asl/rotors_simulator) extensively. In my opinion, it provides an excellent platform to start with for indoor navigation. I’m unsure if it will be great for the VIO kind of thing.

---

<div class="post-metadata">

**Author:** ![gajena](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/gajena/32/19119_2.png) [@gajena](https://discourse.openrobotics.org/u/gajena)\
**Post date:** [March 1, 2024, 6:54pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/5 "2024-03-01T18:54:15Z")

</div>

I agree that 3d navigation is a mess right now; there is some excellent open-source software out there. But the issue comes down to the integration and testing, IMO.

Agilicious provides good software for controlling quadrotors at high speed, but there is nothing regarding avoidance/local planning. They generate time-optimal trajectories and provide them to the controller (also, software access is limited since it is not available openly for everyone).  
Then there is Kumar robotics software, which provides all the things needed. or at least they claim that they integrate everything from global planning to local planning, localization and control.  
Then there is [teach repeat plan](https://github.com/HKUST-Aerial-Robotics/Teach-Repeat-Replan) from HKUST Aerial Robotics group, which also integrates everything.

However, reproducing these setups without the constant support of the original software developers can be a tremendous task.

Currently, for the things I do in terms of 3D navigation. I am integrating different open-source things with some custom-built things since a big issue comes up with the compute cost, performance and form factor. which requires designing architecture while keeping compute, cost, performance and form factor in mind.

---

<div class="post-metadata">

**Author:** ![aarsh\_t](https://avatars.discourse-cdn.com/v4/letter/a/977dab/32.png) [@aarsh\_t](https://discourse.openrobotics.org/u/aarsh_t)\
**Post date:** [March 3, 2024, 3:39pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/6 "2024-03-03T15:39:06Z")

</div>

> [@botmayank](#):
>
> Another concern I have is about how to tackle varying hardware/resource requirements since autonomy companion computers could vary a lot in capabilities?

I’m not sure if we should be concerned about it. I was thinking of it as a ros-navigation approach if possible (general purpose).  
We can provide what kind of sensors and data are required and it can be utilized on the backend.

> [@botmayank](#):
>
> One potential way could be to figure out a simulation

Yes, that can be a good start. But for that, we also need input from the other subcommittees as well (mainly outdoor-nav i guess).

---

<div class="post-metadata">

**Author:** ![KimMcG](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/kimmcg/32/23853_2.png) [@KimMcG](https://discourse.openrobotics.org/u/KimMcG)\
**Post date:** [March 3, 2024, 3:48pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/7 "2024-03-03T15:48:26Z")

</div>

I just wanted to add that we have a page of autonomy stacks for aerial robotics in the aerial robotics landscape:

[https://github.com/ROS-Aerial/aerial\_robotic\_landscape/blob/main/aerial\_autonomy\_stacks.md](https://github.com/ROS-Aerial/aerial_robotic_landscape/blob/main/aerial_autonomy_stacks.md)

However, we do have to try to focus on packages that have been ported for ROS 2 (since ROS 1 only has 1 more year to go) and unfortunately I think that the Kumar robotics software has not yet though.

Aerostack2 has been mentioned quite a lot and has been presented [last year at our meetings](http://discourse.ros.org/t/may-2023-meetings-aerial-robotics/31231/3) and recently for the [gazebo sim community meeting](https://community.gazebosim.org/t/community-meeting-from-gazebo-simulation-to-wind-turbine-inspections-powered-by-aerostack2/2474), however, has anybody used the indoor navigation part one yet?

By the way, should we add a sensor section to the [hardware page on the aerial robotic landscape](https://github.com/ROS-Aerial/aerial_robotic_landscape/blob/main/hardware.md)? Seeing some good tips here but we don’t have a list of this anywhere.

---

<div class="post-metadata">

**Author:** ![aarsh\_t](https://avatars.discourse-cdn.com/v4/letter/a/977dab/32.png) [@aarsh\_t](https://discourse.openrobotics.org/u/aarsh_t)\
**Post date:** [March 3, 2024, 4:30pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/8 "2024-03-03T16:30:53Z")

</div>

> [@KimMcG](#):
>
> however, has anybody used the indoor navigation part one yet?

Not yet. I am planning to test it around this summer with cf2.1 (as they have used in example)

> [@KimMcG](#):
>
> should we add a sensor section

seems like a good idea.

---

<div class="post-metadata">

**Author:** ![KimMcG](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/kimmcg/32/23853_2.png) [@KimMcG](https://discourse.openrobotics.org/u/KimMcG)\
**Post date:** [March 10, 2024, 3:52pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/9 "2024-03-10T15:52:38Z")

</div>

@gajena I’ve added the packages and hardware you’ve recommended to the robotics landscape here:

[https://github.com/ROS-Aerial/aerial\_robotic\_landscape/pull/29](https://github.com/ROS-Aerial/aerial_robotic_landscape/pull/29)

There seems to be replacements for the Intel realsense T265 these days but I haven’t tried them out myself, but I’ve noted them in the list

---

<div class="post-metadata">

**Author:** ![Krishna\_Gupta](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/krishna_gupta/32/19629_2.png) [@Krishna\_Gupta](https://discourse.openrobotics.org/u/Krishna_Gupta)\
**Post date:** [March 11, 2024, 9:32am UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/10 "2024-03-11T09:32:58Z")

</div>

[https://github.com/ETH-PBL/NanoSLAM](https://github.com/ETH-PBL/NanoSLAM)

---

<div class="post-metadata">

**Author:** ![bonolo](https://avatars.discourse-cdn.com/v4/letter/b/7993a0/32.png) [@bonolo](https://discourse.openrobotics.org/u/bonolo)\
**Post date:** [March 27, 2024, 12:26pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/11 "2024-03-27T12:26:35Z")

</div>

A sensor section, with a focus on ROS 2 supported sensors for aerial applications, would be a useful addition.

---

<div class="post-metadata">

**Author:** ![botmayank](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/botmayank/32/33091_2.png) [@botmayank](https://discourse.openrobotics.org/u/botmayank)\
**Post date:** [March 27, 2024, 4:10pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/12 "2024-03-27T16:10:58Z")

</div>

This work looked very relevant to try and test out from @srmainwaring 's presentation today!

> **[GSoC 2023: GPS-Denied Autonomous Exploration with ROS 2](https://discuss.ardupilot.org/t/gsoc-2023-gps-denied-autonomous-exploration-with-ros-2/101121/23)**
>
> Thank you a lot! I can’t use GPS indoor since the signal would be too noisy, so I need to assume I have no GPS sensor. Sometimes, it can happen that the vehicle will move from outdoor to indoor so in this case I think the navigation wouldn’t be...

---

<div class="post-metadata">

**Author:** ![dfx-rick](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/dfx-rick/32/18697_2.png) [@dfx-rick](https://discourse.openrobotics.org/u/dfx-rick)\
**Post date:** [March 27, 2024, 4:28pm UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/13 "2024-03-27T16:28:42Z")

</div>

A similar scenario of GPS-denied navigation, almost similar but a little bit more complicated environment I have seen is in Forest regions with canopies and thick vegetation, which is an outdoor scenario. VIO could be used in such cases for navigation, but is prone to a lot of troubles due to intensity variations in outdoor scenarios.

The approaches for such type of navigation tasks are also very interesting to look into. I apologize if this sounds irrelevant to this thread, but I found this problem to be closer to this thread. The 3D Navigation thread was talking more about the GPS-based navigation.

---

<div class="post-metadata">

**Author:** ![bonolo](https://avatars.discourse-cdn.com/v4/letter/b/7993a0/32.png) [@bonolo](https://discourse.openrobotics.org/u/bonolo)\
**Post date:** [April 30, 2024, 7:25am UTC](https://discourse.openrobotics.org/t/development-topics-for-aerial-robotics-indoor-navigation/36347/14 "2024-04-30T07:25:04Z")

</div>

A list of ROS compatible indoor navigation packages is available here: [aerial\_robotic\_landscape/docs/aerial\_autonomy\_stacks.md at main · ROS-Aerial/aerial\_robotic\_landscape · GitHub](https://github.com/ROS-Aerial/aerial_robotic_landscape/blob/main/docs/aerial_autonomy_stacks.md#indoor-navigation-packages)

Feel free to add your own packages if you’re working on anything new and exciting!