Andruav - Towards a Shared Data Model

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.

Views: 1461

Comment by Tim V on June 6, 2015 at 4:40pm

Great work!!!

Does this work with Pixhawk as well or APM only?

Comment by MHefny on June 7, 2015 at 3:03pm

no it works on Pixhawk as it is the same Mavlink.

although I dont have a pixhawk in home put it was confirmed that it works here http://diydrones.com/profiles/blogs/andruav-multiple-drones-multipl... in the comments section.

Comment by benbojangles on June 8, 2015 at 4:03am

nice that it has the controls. Any thoughts on incorporating gstreamer into this hud screen?

Comment by MHefny on June 8, 2015 at 5:27am

@benbojangles 

Andruav can already transfer a very low rate video 1 - 2 fps.

However adding streamer is in the road map.

Comment by JLJu on June 11, 2015 at 1:53pm

Nice job!

Is the software intended to work at a UCS level like STANAG 4586?

Comment by MHefny on June 11, 2015 at 8:46pm

@Jose.L.Jr

Thanks for the link. Actually I had no idea about that project. I believe Andruav share some objectives with STANAG -in a simple way-. 

Actually what Andruav did in Drone mode is that It creates a virtual board with its IMU and commands that represents the actual board but in standard way. even sensor scaling are changed to keep all the same. Also the virtual board is given high level command that it translates to its specific physical board.

On a higher level Andruav devices communicates in a common language, and moves IMU data, images, GPS, Mission paths using same format no matter what board is connected.

The only exception is when activating the telemetry option on GCS Andruav and connect to a Drone Andruav only then all data received from FCBoard on Drone will be transferred to GCS Andruav to enable using 3rd Party GCS connected.  

Please review this video for telemetry 

Comment by JLJu on June 12, 2015 at 12:34am

I like your Andruav approach. Thanks for the video, you have a new BasicAirData follower!

STANAG 4586 is currently used on a remarkable number of non DIY platforms. Back in 2008 I wrote some code for a SIL UAS Sim, I found useful to have a common interface so I loosely followed STANAG; It was a well documented start. This standard is based on Vehicle Specific Modules; modules provide platform specific information, to interface with new hardware you need a new VSM. Different standards, referenced into 4586, are covering specific aspects like payload management and video links.

Comment by MHefny on June 12, 2015 at 2:46pm

@Jose.L.Jr 

Thank you again. I will review "STANAG", thanks for enlightening me with this info.

Regards,

M.Hefny

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service