It has been a while since my last article about Andruav.
Now Andruav has version 1.0.51. Some nice features have been added to Andruav -most of them were part of the road map-.
Andruav is originally seen as a system that allows multiple GCS & Drones to communicate with each other. Multiple GCS should be able to track multiple drones simultaneously, even drones should be able to communicate track each others, and form a fleet. And moreover, is to try to accomplish this on different drone types with different flight boards.
Andruav is neither intends to be a drone firmware nor a complete GCS where you can set PIDs for your board, it is a big brother -or high level controller- for the originally installed flight control boards.
Enough Talking for future :)
I want to mention some new features and technical challenges that Andruav had to solve. Andruav used to be able to act as a 3G/4G telemetry between flight control board "FCB" and a GCS software such as mission planner or EZ-GUI for multiwii. Now Andruav took another step, it is self aware of the existence of a FCB.
Andruav can communicate with flight control boards, either APM or Multiwii.
1- It can detects "automatically" what type of board is connected.
2- Distinguishes the type of vehicle, and firmware versions.
3- Gets IMU data from FCB
Andruav-drone can switch intelligently between mobile built-in IMU and a connected flight control board IMU when available. So when you open the FPV screen of Andruav-GCS mobile you no longer see IMU of Andruav-Drone mobile sensors, but you see FCB IMU data -if exists-.
You can also change flight modes from Andruav, with no help from a third party GCS, this is limited to APM for the current version.
As above image shows, You can even use on-screen RC to control your drone -considering 3G delays you should wisely select the flight mode-. RC sticks can work on both Multiwii & APM although the logic of controlling is different between Multiwii & APM. The first uses a time out approach, while the second uses a release approach to release sticks and get back to TX.
Another challenge is that multiwii IMU data is different in type and scale from APM. This has been solved via constructing a shared model representation for the vehicle, that is independent from FCB and protocol specs. Yes this means some details might be hidden, on the other hand, you have a generic system where hybrid vehicle types, equipped with different system can communicate and work together.
This unified view is what differs this version from the old 1.0.30+ version that has a telemetry option to enable third party application with no actual understanding of what is being sent.
Next step is to enhance some GUI especially in FPV to enable sensor fusion between FCB & Drone mobile sensors, also a drone-to-drone communication is coming soon.