How to use and extend the MRS software platform? about mrs_uav_system HOT 3 CLOSED

Hello, regarding the tmux sessions that run on the drones, we have examples here:
https://github.com/ctu-mrs/uav_core/tree/master/tmux_scripts
We use bare tmux scripts for real drones, not tmuxinator.
You simply SSH into the drone over wifi, and run the tmux script there.
You can also set your computer in a way to run the required tmux session right away on computer startup.

from mrs_uav_system.

1 The system should run as-is on a Raspberry Pi or most of the other common ARM-based platforms (e.g. Jetson TX, Xavier NX or the Odroid).
1.1 Run the simulation environment on a separate computer, connected through Ethernet LAN to the Raspberry Pi/whatever. Run the MRS self-localization and control pipeline on the device to be tested for CPU/RAM. The px4 autopilot runs on a separate embedded microcontroller (we use the PixHawk autopilot HW), so it's not limited by computational resources of the onboard PC. According to our experience, the system should run out of the box onboard a Raspberry Pi or equivalent platform.
1.2 Enough for what? If you want to test the CPU/RAM load, bear in mind that the simulation itself is significantly more computationally demanding, then the MRS self-localization and control pipeline. Therefore if you run the whole simulation on the Raspberry Pi, you'd be testing the computer as a simulation platform and not as an onboard computer platform, which is probably not what you want. If you just want to run the MRS pipeline, you can get off with a much weaker CPU than for a whole simulation.

2 In general, I'd say just try to install our system on a freshly flashed Raspberry Pi with Ubuntu 18.04 and see what works and what doesn't. It should work. If you encounter any specific problems, try to solve them one by one (pull requests welcome) or contact us in case you need something from our side.
2.1 We use the normal desktop version of Ubuntu, because we usually utilize GUI for debugging purposes etc. (our full Linux setup is available here: https://github.com/klaxalk/linux-setup). However, a minimal installation should be sufficient. Worse case, you might encounter some missing packages, which will have to be manually installed, if we forgot about some in the installation scripts.
2.2 I also have no experience with ardupilot, but AFAIK, it should be compatible with MAVROS. We use px4. Regarding the OS, we're using Ubuntu 18.04, so I'd start with that, if possible. The flavor (lubuntu/xubuntu/kubuntu) is irrelevant, as we don't rely on the window manager anyways (in fact, we use a separate window manager for work - the i3wm, but the MRS pipeline is completely separate from a WM).
2.3 See response to 2.

3 Instead of this solution, I'd recommend using the PixHawk in place of the Raspberry Pi. This is the solution we are using currently and have experience with. We've not tested using Raspberry Pi or any other embedded computer in place of the PixHawk.
3.1 I don't see why not, but we can't really help you with this solution as we have no experience with it.
3.2 I guess whichever suits you the most. On the computer where you intend to run our pipeline, I'd recommend using Ubuntu 18.04, since that's what we are using.
3.3 That seems like a possible solution if you insist on using navio2 as the flight controller instead of PixHawk.

4 I refer you to our documentation: https://ctu-mrs.github.io. There is a specific section about simulation with a detailed tutorial on how to set up a basic simulation experiment, which is a good starting point to see that everything is working. Then you should add your specific HW platform into the simulation environment and test the system with it. You'll most probably have to set the correct weight, dimensions, motor layout and motor constants. @klaxalk may provide better details regarding this procedure. After your platform is flying in simulations, you can try going to real-world experiments.

5 You add another drone ;) On a more serious note - you should have the drones on a common LAN over WiFi and enable the collision avoidance to... well... avoid collisions. Although perhaps your question was more specific? If so, please rephrase.

6 Yes.
6.1 With normal GPS, there are potentially much larger position errors. It wildly depends on specific conditions (satellite visibility, EM interference, quality of GPS etc.). Nowadays, we're using RTK GPS mostly as a ground-truth for evaluation of various localization and detection algorithms.
6.2 We were using the Tersus GNSS RTK, but we don't have very good experience with it. It takes forever for the GPS to acquire RTK fix and communication between the base station and RTK modules is unreliable. We've been testing a new solution - @DanHert may know more about that.

7 I'll look for some list. Again, @DanHert may have a better idea.

Hope this was helpful :) Feel free to ask more questions in case anything is still unclear!

from mrs_uav_system.

Thanks a lot for the responses @matemat13 !

I'll keep you posted if at some point this alternative raspberry Pi + navio2 solution would be working.
But first, I prefer to walk on a safer road and learn how to use the exact same hardware setup as you are using.

I have one main follow-up question concerning the transition from simulation to real-hardware tests.
Assume I have built the same F450 drones as you have (so using intel NUC) and the mrs-uav-system is installed on the NUCs.
Assume that the multiple NUCs and a ground station are connected via router over a common LAN over WiFi.
Up to now I only ran some basic simulation tests e.g. three drones gps by running those simulation Tmux sessions. Is there any equivalent basic tmux session for outdoor swarm use you could point me to? I assume from the ground PC you are telling each NUC somehow to only run a specific part of the code. That part is not clear how you do that.

Thanks!

from mrs_uav_system.