MHefny's Posts (25)

Sort by

DIY - Open Board Architecture for Linux - OBAL




This board is one of many Linux-Based boards that run Ardupilot. What is spepcial about this board is that has very simple architecture. Only necessary components has been added. No extra or redundant components. However it is still expandable and more sensors can be added if you want to.

The PCB shield is designed to use simple breakouts available in the market. No special soldering skills or components are required. You can build from scratch your own board using this PCB and learn the basic architrecture of Ardupilot boards and move to next step where you add extra sensors and ending by building your own board.

Yes this board acts more like a developing kit rather than a ready-to-fly board. Again if you want to fly with it you can but then do not use pin headers and solder the breakouts directly on the board.

On the software side. OBAL board does not have special drivers. All you need to do is to clone ardupilot repository and compile the code. Nothing special, nohting hidden , completely open source.




For more information please check Ardupilot Documentation. Also there are some videos that describe in details how to build it, compile and deploy the software. Have fun :)





Read more…


Mavlink3DMap is a semi-simulator that communicates with Ardupilot SITL vid  UDP and websockets to plot vehicles location and attitudein a 3D environment. It uses HTML, javascript and some 3D and physics libraries to work. The world semi is used because this tool can integrate with any Ardupilot SITL  regardless of its engine, and read vehicles location and plot it in a 3D environment. So all physics and logic computation are performed by SITL. However, one can add 3D objects and some physics using moderate developing effort. The tool can also track multiple drones given each drone has its own SYSID_THISMAV


Below is the famouse flying field in Australia where SITL flies there by default. As we can see the map is displayed in 3D, and from multiple views. A camera is attached to drone and can be controlled via buttons. Another camera is following the drone.


The above map uses flat landscape, i.e. the map is created on a 2D Plan, but the environement is a 3D environment.

The below image shows one step forward, it creates 3D mesh of the map and adjust drone absolute altitude accordingly based on drone home location.






















This project is in its very early stage, it is free and open-source and can be accessed here. I hope people start to use and contribute to it.


Read more…

Andruav - Same Device with Mission Planner

Andruav system is mainly an Android based system, recently it has supported Web using Andruav WebClient.  In this article the video shows a new integration tool. Andruav Web Plugin it is a simple application enables you to connect Mission Planner Directly to your Drone(s) anywhere in the world via Andruav Web, you dont need Andruav GCS mobile to connect your Mission Planner anymore.

Technically, Andruav Web Plugin is a nodejs app that you can easily install on your Windows, Mac or Ubuntu using a single command line. That means using any laptop you can open AndruavWeb on Chrome or FireFox, and connect to all your drones allover the world. Not only that, you can get low level control using Mission Planner or similar Apps that you run on your laptop using Andruav Web Plugin. 

Using Andruav Web, you can select different levels of speeds based on your connection bandwidth, and your needs. The default is level 2 which is the best optimization of mavlink messages that balance between speed and response. You can choose other levels based on your needs.

Have A Safe Flight

Read more…

Andruav 12,193 km RC Car Demo

This could be a record breaking. The above video shows a demo with Andruav to actually control a RC Car from LA in Cairo using Andruav, the distance is 12,193km 7576 miles between the driver in LA & the car in Cairo.

The demo was done in my home, and the car is pretty fast, so a caution was required when controlling it to avoid fast jumps.


The configuration is like described in the below image.


LA Configuration

Andruav-GCS running on a tablet, the tablet shares wifi with a laptop that runs mission planner, the mission planner is connected using TCP/IP to Andruav-GCS that acts as a telemetry. A Joystick is connected to Mission Planner for control.

The Tablet itself is running opens FPV screen using Andruav, it display what is captured by the RC Car mobile that is mounted on it.

Cairo Configuration

There were two separate Andruav there.

1- Andruav-GCS on WebClient, this is what we see on the large monitor, it shows Mario Location & it connects to Andruav-Drone “RC Car” same as the GCS in LA and display the very same video that Mario see in LA through Andruav-GCS on tablet. One-to-Many video streaming is one of the nice features in Andruav.



2- Andruav-Drone “RC Car”, the car has an APM board and a bluetooth module. A mobile is mounted on the car an connects to APM via bluetooth. It runs Andruav-Drone.


The other video from Cairo that shows the car on the other side is this one:

At last I want to thank Mr. Mario for his video & support.

Read more…

Andruav Web GCS is the new Andruav arm that enables UAV pilots to remotely control their drones. Andruav has been known for its ability to track multiple drones, multiple board types, and provide FPV capability. Now withAndruav Web you can control your quad, rover, plane by mouse clicks from your laptop.

DIY @ Home Flying

Thanks to Drone-SITL  you can reliably and safely test Andruav and its capabilities using a laptop and an Android mobile. Drone-STIL is a software-in-the-loop that simulate different vehicles run Ardupilot firmwares, the main andantage when it come to Andruav is that drone-stil simulates the input sensors, and physics model, but when it comes to calculations, path planning, modes ...etc. it uses the very same code that runs on your drone.

Drone-STIL may be not enough for practicing your flight skills, but it is enough to test and train your self on mission planning, using Tower APP & MAVLINK protocol. WHY ? because what happens here is that your commands are being processed with the very same code that runs on physical boards, the simulated sensors and motors are not the concern here, and not affecting any results in that area. So if you have a working tuned drone, so what Andruav can do with Drone-STIL will do it exactly with your own drone. So this is a training play ground that you can use to verify Andruav true capabilities.

Using Drone-STIL with Andruav

1- You need to install Drone-SITL on your machine.

2- You need to install MavProxy, this is the proxy that will be used to connect Andruav to Drone-SITL.
3- If you have everything installed correctly you should be able to run drone-sitl as in the following command:

                           sudo dronekit-sitl copter --home=-35.3632161,149.165229,0,0 --model=quad
4- Now you need to run mavproxy to connect your dronekit with Andruav. but first you need to know the IP address of Andruav Drone Mobile. each time you connect your mobile to your local wifi network it will get a new IP, so each time you need to get this new IP and connect to it.
Another solution is to use your wifi router to set a fixed IP address for your mobile by attaching a fixed IP address to the MAC address of your phone.

Assuming your mobile ip address is then you need to run MAVProxy:
                          sudo --master=tcp: --out=udpout:

Now all you need to do is to open Andruav in Drone Mode, go to FCB screen, and choose a UDP connection either native of via 3DR Services, and that's it.


Now Andruav will behave exactly as if it were connected to a real drone, now you can test your telemetry features easily and safely.

What is in the Video ?

The video is created using two Android mobiles running Andruav Drone-Mode, each mobile is connected to a Drone-STIL instance, one of them is for the quad, and the other is for Rover. 

In the video you can see Andruav automatically distinguishes between different vehicles, and modes that each vehicle can take.

Using double-click a destination appears where you can make vehicles goes to it -when they are in Guided mode-.

Also you can use Andruav Fence Editor, you can easily open it from Andruav Web to open in the same location, you can define fences in different shapes. Fences are stored in Andruav global database, and whenever you start any Drone your own fences will be downloaded automatically - you can delete them from web-.

Fences can be soft as in video, or hard that trigger RTL when a vehicle reaches it.

You can control YAW, Altitude, Capture Images from Mobile or Drone Camera.

You can stream HD Video from Drone Mobile.

Please try it yourself ... you can produce your own Andruav video same like the one above.

Have Fun :)


Read more…

Andruav - Video Streaming Capabilities

Back to Andruav :)

The above video shows how you can use Andruav for streaming video from your Drone(s), and receiving video simultaneously on different types of Andruav-GCS.  

Although the video shows devices in one place, but you  can make the same scenario using devices in different locations, even different continents, as long as they have Internet connection via ADSL 3G or 4G. Video quality depends on sender mobile, network and the receiver device.

The streaming protocol handles network bandwidth intelligently and adapt video quality according to bandwidth availability, also processing power of the receiving device determine video smoothing and glitches.

Giving current and expecting advances in technology in video streaming field and processing power, this should not be a problem in near future.
Please remember to use HTTPS when accessing Andruav Web Module to be able to access video.
Read more…

Andruav - More Powerful & Still for Free

A year from now I published Andruav latest article. Since then a lot of improvement have been applied.

What is Andruav in FPV ?

Andruav Video Streamer has been re-written to make use of modern Video Streaming technologies. Now Andruav stream video almost in real-time, it also can broadcast video from a single drone to multiple GCS including Online Web.

What is Andruav in Telemetry ?

Andruav already supports Telemetry for multiwii, APM & PixHawk. Now Telemetry is even better and more easy to configure.

The below video starting from minute 4 shows how can Andruav connect to Tower App, and stream data over Internet, while still you can access Video and other drones from Andruav GCS and on the same Device. 

What is Andruav as a Standalone App ?

Andruav connectivity has been expanded to connect using 3DR Services .

3DR Services already provide multiple options for connectivity, Andruav also provides Dual Connection i.e. Wifi & 3G/4G so that you can connect to SOLO and access it from Internet.

One of the distinguished feature of Andruav is the ability to many-to-many connections. i.e. You can use multiple GCS & multiple Drones all connected to each other.

In this video we can see Andruav GCS tracking two Drones running as Simulators.

What does it cost you to use Andruav ?

Andruav is a free app, you can download it for free from Google Play and use its full features for no cost.

As for hardware, you can use inexpensive, small, light weight yet powerful mobiles that supports 4G such as Micro-X-S240


As for ground station you can use your own mobile, a TV BOX -if you want a wide view-, or you can even access it online via Internet with much more features using Global ARC.

I hope you find Andruav interesting, and share your experience and feedback to make it even better.

Read more…

Maybe you are one of those who googled for the difference between Quadcopter & Tricopter. For sure you found many feedback and comparisons. 

Mainly the difference will be regarding power consuming, or mechanical complexity. Some prefer Quadcopters for its simplicity to build and fix, others prefer TRICopter for its ability to YAW more aggressively.

In this acticle we will discuss deep differences between Quadcopters & Tricopters, and the point here is flying & stability equations difference between quadcopter and Tricopter.

First Lets discuss Quadcopter Equation - no details here just a fast review-:

more details in broken english is here


There are three core equation for Stabilizing & Flying quadcopter is:

assuming M1, M2, M3, M4 are thrust for each motor.

equation #1:

Thrust(M1) + Thrust(M2) + Thrust(M3) + Thrust(M4) = Total Thrust  ... and this is determined by Thrust Stick only.

equation #2:
Thrust(M1) + Thrust(M3) = const. ... determined by Thrust stick equation #1
Thrust(M2) + Thrust(M4) = const. ... determined by Thrust

so for example when you want to roll anti clockwise, you increase M2 thrust by x and decrease M4 thrust by x. so that Equation 2 is always Valid under the same Thrust Stick position.

So for a roll a typical equation is:

M2 = Thrust + StickRoll * factor + PID (IMU ROLL)
M4 = Thrust - StickRoll * factor - PID (IMU ROLL)

so what you add to a motor is substracted from the other one on the same bar. That is because we need to keep the third equation valid:

equation #3:
Moment (M1 + M3) = Moment (M2 + M4)

This is very important because this is HOW QUAD make and correct YAW. Quadcopters -hex & octa- correct YAW using moment difference between motors on different bars.

So when we want to Roll equations are:

M1 = M1 + Stick YAW * factor + PID (IMU YAW)
M3 = M3 + Stick YAW * factor + PID (IMU YAW)
M2 = M2 -  Stick YAW * factor -  PID (IMU YAW)
M4 = M4 -  Stick YAW * factor -  PID (IMU YAW)

What you can notice here from above equations is that no equation CONTRADICTION with the other two. Ideally of course, as in real world we make some assumptions:

1- thrust is linear with motor signal sent to ESC - which is false but works :) -.
2- motor response to signal change instantly, so we read the very last IMU signal and send correction. especially if we use P only no I or D, we read the only last value, which is not true as it may has nothing to do with the last change because of inertia of propeller, quadframe ...etc. but again it works :)

Now lets go to Tricopter

The following equations are used:

equation #1:
Thrust(M1) + Thrust(M2) + Thrust(M3) = Total Thrust ... and this is determined by Thrust Stick only. same as quadcopter.

equation #2:
Thrust(M1) + Thrust (M2) = const for ROLL
but wait. Motor M1 & M2 acts as one virtual motor with M3 for pitch stabilization.
so Thrust (M1 + M2) = virtical Thrust (M3) = Thrust (M3 ) * Sin (ceta)

This is OK as for Roll we add x for M2 & subtract same x from M1 and it will not affect the pitch stabilization -at least in theory-.

Now lets go to the equation of YAW:

equation #3:
Moment (M1) + Moment(M2) = Thrust (M3) * Cos (ceta)

to correct or make YAW motion, you need to change ceta of Motor 3 using the Servo. But wait This will affect equation #2.

changing ceta will not only correct the YAW but will corrupt the pitch balance in equation #2, and then thrust of M1, M2 & M3 needs to be corrected
again to correct the picth. but wait this will corrupt equation #3 because the YAW will be affected again and again in infinite loop :)

So if you correct YAW using Motor thrust angle, and correct Picth using M3 Thrust then equation #2 & #3 will affect each other, but the Tricopter will be balanced as a whole, because correction is so fast and accurate especially when using a digital servo.

THERE IS A BIG difference between Quadcopter & TriCopter in flying concept.

The main advantage I can find in Tricopter because of the Servo:

1- You can get more agressive YAW motion compared to Quadcopter, as Thrust is used for YAW not moment, and thus force for YAW control can be higher.

2- You do not need to care about CCW & CW props as long as motors & their props rotates in the right direction, the servo will correct any moment even if all motors are CW or CCW. does not matter.

Best of All is Tilt motors for Racer FPV:

in Quadcopter if you fly in X mode and made front motors tilted to gain speed while keeping the frame horizontal for better aerodynamic.

In this situation the Roll correction will YAW deviation because thrust vector is not vertical to frame and when one motor corrects the Roll by increasing thrust it will cause YAW motion because of thrust horizontal component.
Things will be worst if the same motor is used to correct YAW using moment in the opposite direction, then YAW will not be stabilized at all.

in Tricopter this will not happen, actually you can build a fast Tricopter with tilted motor, and just ignore this effect, because YAW correction happens by the third motor servo, and equations 2 & 3 already affect each other, and will actively stabilize.

Read more…


This article is to share my findings in gyro calibration. I tried to make a python script that uses data comes from mobile phone [S5 that has 6050 IMU]. It was a good chance to write simple code and visualize results much easier than doing so on Arduino with IMU 6050 attached. But still the concept is the same.

I used this mobile app, this is not the only one, so you can choose other if you want.


I used three approaches for Gyro calibration.

First Approach:

This is the normal approach where you read values from Gyro and then divide total by number of reads. This is the average value. Almost all quadcopter firmwares do this step before arming to make sure that the value that is read from gyro represents zero rad/s i.e. no rotations.

gyro from value will be:

     Gyro = (gyro_raw - gyro_avg ) * timediff

      where gyro_avg is the average measured by reading a sample values and divide over count.

There is nothing wrong in above approach, it is simple, and really can make your quad flies. 

Second Approach:

The second approach was almost the same, but in this trial, I took values from First averaging algorithm as a first guess,  then I ran an inner loop that tries to get error based on the original average, and tries to add correction to it.

gyro of value will be:

      Gyro = (gyro_raw - gyro_avg_dyn) * timediff

      where gyro_avg_dyn: is the best average with least error.

I find this is a equivalent of running the first approach method multiple time and try to get the best average with least error. It could be smarter than blindly get an average after n counts -first method- where you can test some values in between. This also may be more useful when using integers rather than decimal in 8-bit chips.

Third Approach:

This approach was a bit different. It assumes that original average will give zero error for the noise, however drift will still occur, and it is in one direction. So if you integrate values from gyro it will keep either increasing or decreasing in one direction -as an overall behaviour-. 

The idea was to try to read the rate of which drift occurs and store it in a value called Gyro_AvrDriftRate. The unit of this value will be rad/sec^2.

So the Value of Gyro will be:    Gyro = (gyro_raw - gyro_avg - (gyro_avgdriftrate * timediff) ) * timediff

      where gyro_avg is the average measured by reading a sample values and divide over count.

      and gyro_avgdriftrate is drift rate per second


Drift already affects the original average value, as gyro_raw is not random values with normal distribution around an offset value; as it has drift component inside. and so the original average has a skew from the zero offset. In the third approach the drift will appear clearly in the integration of readings and using time-difference one can estimate a rate for the drift.

Actual Results:

Script Logic:

     1- calculate average and drift using the three methods.


     2- while loop:

              a. read gyro_raw

              b. calculate gyro_value_method1,2,3


              c. integrate these values into three different variables gyro_x1_int, gyro_x3_int, gyro_x3_int


              d. print result

The best approach should have the least absolute value i.e. the nearest to zero.


I ran the code several times, the result is not the same every time. but in general the third method is promising, as in

many cases it gives less drift than the other methods.


the third method is the one has x_rad/s2 label.

Also the second method sometimes get stuck in local minimum, as it reads less values in the inner loop, and sometimes get worst that normal average. 

This is not always the case. Anyway I hope this could be a small start for others to make much more investigation.

Note: sometimes values sent from mobile jumps in crazy way without movements, so I just added a skip statement to skip those values, and I assume you run this script while leaving your mobile with no movement at all.

Latest Code version is available at this link


Read more…

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.

Read more…

Andruav SDK


This is my fifth article about Andruav. The new thing about this topic is that it targets Developers more than users.

Andruav-SDK is a jar file that you can use to develop an application with same or more features of that in Andruav App.

Andruav Protocol

Andruav based systems uses web-sockets for communicating with other Andruav-based parties. Communication can take place as broadcast or peer-to-peer. It is very similar to IRC and chat room model, where you can communicate privately with someone or just speak to the whole room. In Andruav world we call them Groups and instead of talking to persons there are Units. A unit can be a vehicle “plane, quadcopter, rover” or can be a GCS “Ground Control Station”.

Andruav Communication Rules

Before we start, we need to define some communication rules for Andruav.

1- Any client connect to server identify itself by AccessCode "account".

2- for each packet the unit has to identify its name and group name.

a. unit name "sender" is a name unique for each account and identifies the unit of GCS.

b. group name "group" is a name unique for each account.

3- Each account can have multiple groups.

4- Each group can have multiple units.

5- Units can only communicate with other units in the same group. no group-to-group communication or account-account communication.

Command Types

command types are either system commands or communication commands. It is a fast way to tell server if it has to parse the message or just forward it to target(s).

system commands are:

add: to subscribe a unit or GCS in a group in an account.

del: to unsubscribe a unit or GCS from a group in an account.

ping: server reply with pong message and using timestamp created by sender the sender can evaluate quality of connection. Can be used to determine some features such as enable/disable video stream, or send a remote warning that there is a communication issue or send SMS as SOS message.

The other command type is communication commands and it has only two commands:

individual: instruct the server to send the message to a single unit. the target unit is found in field "target" and it should be found within the same group. target is extra field that appears only when sending individual messages.

common: instruct the server to send the message to all units and GCS in the same group.

In communication commands, server only acts as router for routing messages. the message field in Andruav command become a major player here. as it contains the actual command or info that is sent to target(s). Also another field appear when sending command called "message type" which is an id of type of command embedded in the message part.

Above attributes are sent in JSON format.

Andruav Messages can be either text or binary. Binary messages are used to carry telemetry data, images and video frames.

Remember you can Extend and Create new commands that fits your need. More information about classes are here.

There is alot to be written for documentation, however please contact me in case you need any support that is not clear in documentation.

How to Run Sample #1 APP

Code & App is on gitHub

You need to install Android APP apk file on two android mobiles.

from above video you need to only enter Access Code & Andruav Unit ID. The first one is a common alphanumeric, and the second one is unique per device.

You might also want to access this for details.

Read more…

This is my fourth article about Andruav. In the past few articles I talked about:

1- What is Andruav then I focused on the telemetry features in Andruav.

2- Andruav as a3G unlimited Range Telemetry and made demo on Multiwii.

3- Andruav as APM Telemetry 

Now lets get back to Andruav itself. As mentioned before Andruav is an interconnected system, it aims to connect multiple GCS & Drones together so that they can communicate and exchange information.

The first line of code of Andruav was written in Sep 2014, so it is relatively new, however there has been alot of progress since then. Now let us discuss the interconnectivity demo in the video:

Video Scenario:

The video shows how multiple drones and GCS can be interconnected using Andruav.

In the video we have:
        1- two Andruav mobiles that are mounted on two different drones.
        2- two Andruav mobiles that are GCS mobiles.

        GCS mobiles can be in two different places, states, countries ...etc. and they both can be very far from Drones.

Scenario #1:

   An Andruav-GCS connects to Drone 1 and display IMU data from it. then Drone 2 is selected and GCS mobile start display IMU data from Drone 2.

Scenario #2:

  Both GCS mobiles are connected to the same Drone. and they both display IMU data from a single drone.
Please note: both mobiles can take remote images from the drone, the preview will be sent only to the GCS that requested the image.

A Hi-Res image with GPS info will be stored and linked to KML file in the drone mobile.

Scenario #3:

   Each GCS is connected to a drone. i.e. GCS1 is connected to Drone1 and GCS2 is connected to Drone2.

Things to be notice:

       1- All drones are connected to all GCS all the time, it is the IMU data that is being redirected only.

       2- All drones and GCS can be tracked simultaneously on Google MAP of any GCS.

       3- A drone can be connected to a GCS as IMU data, while telemetry data is being sent to the other GCS.

Current version 1.0.30 can automatically distinguish between Multiwii protocol & MAVlink and optimize telemetry communication for each one.

As part of the roadmap, comming versions should be able to parse & inject packets and provide standard means of communication between different drones regardless of board type.

Read more…

Using Andruav as 3G/4G Telemetry for APM ArduPilot


This is my third article about Andruav, last one was a couple of weeks ago that was about the Telemetry feature in Andruav.

Since then some updates has been done to telemetry that I want to mention it here.

Andruav Telemetry has taken one more step forward. Now it can use USB besides Bluetooth when connecting to Flight Control Board (FCB). Also communication between drone and GCS has been extended so that  Andruav GCS can detect multiple telemetries on different drones and switch between them as shown in above video. Also protocol overhead has been reduced, which allows it now to work with less bandwidth up to 25%.

The video shows the below setup configuration:


We have two Andruav mobiles, one of them on Quad which is the  Drone-Mode Andruav and the other on land in pilot's hand which is GCS-Mode Andruav , The Quad has  Ardupilot board, the board is connected to Drone-Mode Andruav using USB cable - it can also use a Bluetooth connection-. 

On ground we have GCS-Mode Andruav mobile, and another mobile that runs Droid Planner, BTW you may use a laptop with Mission Planner on it.

The video starts actually showing when everything is connected and then make a playback showing from the beginning how to make such connection.

I want here to mention three things:

1- My english language is bad :( sorry .... I need to work on it.

2- When trying to make this type of connection you need Andruav GCS to have access to both a wi-fi and Internet, so you have two options:

     a. Andruav GCS is connected to a wi-fi that can access Internet as well.

     b. Andruav GCS has 3G/4G connection, and here you need to enable Wi-Fi Tethering so that the third mobile can connect to Andruav GCS. 

     In my demo all mobiles where connected to Wi-Fi router, however both Andruav  mobiles are connected and communicated through a server in server.

 3- If you see the last part of the video you will find that Andruav Camera Shooting and HUD info are working and independent of the telemetry feature that works in parallel.

Have a safe flight :)

Read more…

One of the attractive Andruav features is that besides the built-in FPV features and multi drone tracking, is the ability to provide a telemetry over internet between your drone and your GCS. The connection uses mobile internet which means that telemetry range is unlimited.

The above video uses a multiwii board from HK with a bluetooth module. the module is connected to Andruav-Drone mobile. Andruav Drone communicates using Mobile network via Andruav server to Andruav GCS. Then I useEZ-GUI to connect using TCP to Andruav GCS mobile.


As we can see still you can make remote camera shooting and read Andruav Drone sensors independent of quadcopter multiwii board. Still you can use othe Drone-GCS and track the same quad, or you can quad other drones using the same Andruav - GCS using the many-to-many Andruav communication.


You may download Andruav from here 

For info how to use and setup is here

Read more…



Have you ever think about controlling multiple drones, or enjoying a team flying with your friends, where you can both monitor your drones, even your friend who could not come to the field, even your friend in another country !!

If this is not enough lets imagine you need to fly your Ardu drone in a very long mission, and you need it to be connected with your ground station or Droid Planner, you need no expensive devices anymore.

Imagine you need your Ardu to follow your friend Multiwii, different platforms, well this is a comming soon feature :) rest are already there.

Let us start the story from the beginning. Mobile devices are getting more powerful every day, as in 2014 many mobiles have multiple cores with speed more +2GHz, and +1GB Ram. Recent mobile phones have complete set of sensors Gyro, Accelerometer, Magnetometer, Barometer, GPS as well as rich communication media including Bluetooth, Wifi and GPRS. This is not everything, even mid-range mobiles have powerful camera with very high resolution.


They also have loud speakers and high resolution screens with multi-touch capabilities. That makes mobile a very attractive platform for RC and UAV.

A board with same features would be quite complex to assemble and will require a lot of programming challenges to make these stuff work together, meanwhile an Android mobile provides these features with relatively easy programming and in high level languages such as Java or C++.

People have stopped thinking of mobiles as a classical phone since a while, and it is seen as an integrated device where you can talk to ppl., watch movies, listen to music. The Andruav project adopts the same vision in UAV world, hence your mobile is your own new control board.

So what is Andruav –pronounced “androiv”-. It is an interconnected Android-based mobile that allow both vehicle-to-vehicle and vehicle-to-GCS communication and control. It allows group communication, and drone-to-drone communication.

Currently the system is in its Beta Stage. I hope interested people can join to get the best out of this.



Read more…

ZERO_PID Tunes for Multirotors Part#2



                From more than a month from now Aug 2014, I posted a blog titled ZERO_PID Tune for Multicopter, It was about an algorithm I developed that allows quadcopter pilot to reset Gyro PIDs to ZERO, and fly! Using this algorithm, the quadcopter was able to generate valid values for P & I, and can successfully fly, the demo was on Multiwii code. Since then I was working on enhancing this algorithm, as I discovered some opportunities for improvment.

First Version Issues

                 Although as you can see in the video that quadcopter really flies, there was a devil in the details. P-factor & I-factor would saturate if you fly long enough – I discovered this later few days after the video-. Although quadcopter was safely taking off, but flying for a long time -1 to 2 min- in this mode will make P & I saturate especially if you play with sticks hard.

Another issue I have discovered in the first version was calculating I-factor assuming it is a percentage of P-factor. Although it was calculated separately from P-factor, it ended up as a percentage of P-factor.



       Although my background is engineering, but I am not a big fan of mathJ, so I started to simplify the problem as much as possible, and avoid complex math. The model depends on angular velocity of gyros only. It assumes there is no interference between different axes –which is true theoretically at least- as actual Gyro MEMS has slight interactions between axes.  


       First, let us start by a quad arm with a motor on it as in the figure, initially the motor is running, but you do not know if it is running fast enough to generate exact thrust to keep the arm with angular velocity zero. Again let’s assume that the motor is not producing enough thrust, so when reading the gyro we will get V1 = v1. With single value you cannot judge, you need to read two values, so you wait until the next IMU loop and read V2=v2.

       Now assume that both V1 & V2 have the same signs. This means the same direction, which is falling down –counter clockwise in the figure-.

Condition#1:     If V2 > V1 : this means the arm is accelerating and the quad in danger of flip. So let us reduce the P value by one if the difference is high enough.

Condition#2:     If V2 < V1 : this means the arm is decelerating and the quad is trying to adjust itself to reach angular velocity zero. However there is a danger here that the deceleration is so fast so that it will not only stop the arm but will move in the other direction and start oscillations. So let’s decrease P value by one if the difference is high enough.

Please note that by design, quad stability is active stability, i.e. you need to monitor and adjust to keep it stable, so whatever the P value is, it will oscillate, the idea here is the oscillation amplitude should be minimal.

Condition#3: What if V1 & V2 has different signs, i.e. our quad arm has reversed its rotation direction. This case is ignored as it will always happen due to oscillations as I mentioned in the previous paragraph. And we rely on condition 2 to minimize oscillations.    

What if the arm –in the figure- rotation direction is clockwise, in this case we are calculating the right arm that is falling down. That is why we use abs(Error) . So we always consider the falling arm.

ZERO_PID algorithm can be written now as follows:

void G_Tune (Error)  {

                If (Sign(Error) == Sign (OldError))


                       If ((abs(Error) - abs (OldError)) > High_Enough _1) // we are falling down.

                           P = P + 1;

                      If ((abs(Error) - abs (OldError)) <  - High_Enough_2 ) // we may oscillate.

                         P = P - 1;


               OldError = Error;



Simple :) and yet it works. Well almost :)

As we can see the above algorithm changes P-factor only. In the first version I used a parallel condition for I-factor that increases and decreases it with 0.1 steps. Later I discovered this was not the best approach.



Algorithm idea looks simple; however we need to consider some points that affect the performance of the algorithm.

  1. Aerodynamic Factor:  The above algorithm updates OldError = Error, actually it is not reasonable to assume that applying the updated P factor once in the PID and read the very next value will reflect the instant correct response, we need to consider motor acceleration and deceleration, as well as frame/propellers inertia, a lot of factor that makes our assumption not solid enough.3689610274?profile=original In the first version I tried to use complementary filter, and give a large weight for the new value, however keeping the old values so that we can have idea of the average performance. However we still read the very next action and update P-factor after one read. In the latest version I have defined time_skip parameter that make sure that the algorithm is executed one time each ntimes of PID calls. See the figure, the curve are the values from gyro while the bar chart shows samples taken by the algorithm. In practice I found time_skip  from 7 to 20 i.e. 14ms to ms gives the correct response, out of this range the quad still flies but the model assumption is not valid and it either saturate or stay in Zero. For low value of time_skip it stays in zero because V2 – V1 is small and within a safe range so quad assumes that this is a normal speed. Also V2 in this case does not represent the effect of previous updated P. also when time_skip is high, quad reads random values with large difference, and in this case condition #1 wins and P saturates, also still this is a fake reading. So time_skip is a critical parameter, which works well as long as we are in this range 7 – 20.
  2. Taking-Off & Landing: When you land with your quadcopter, once the quad hit the ground –even smoothly-, you will be able to see sudden peeks on the accelerometer graph. It is more clear on the Acc-Z, and this means calculated P could be corrupted during take-off or landing especially. Handling this was relatively easy. I just added a condition not to calculate P when Thrust is less than one third throttle. So now you can land and then switch from G_Tune to ACRO mode, you don’t need to do that in the air, however you can still do it safely as in the first version.

  3. What is Error Input Parameter: PID takes Error as an input, error could be gyro reading as in hefnycopter firmware , or as in multiwii it is the difference between stick value and correspondent gyro, i.e. between aileron value and the x-axes gyro. In the first version as used the same Error value as in multiwii, but this was not very good, as it means that when you make sudden stick change it will give error and the algorithm will correct P accordingly, although the current P value could be enough and correct. First I tried to define high and low boundaries for Error values, but after more thinking I was convinced that we need to consider only gyro reading as an input, and leave stick for multiwii algorithm.  

  4. Condition #2: Please re-read that condition again “However there is a danger here that the deceleration is so fast so that it will not only stop the arm” there is a vague word “danger”. Well how can we know if the deceleration is healthy and arm is slowing down in a proper speed, or it is slowing down too fast, well I don’t J. I tried some ranges and I found thatHigh_Enough _2 should be 1.5 to 2 times larger than High_Enough _1. Lower value for High_Enough_2 will make P always ZERO which is logic. And high value of it will make P saturate as condition #2 is hardly achieved because of the large barrier value.


Calculating I-Factor


                As I mentioned in the beginning of this article, I was calculating I as a percentage of P. Well in an article about sensors & PIDs I mentioned that I component in PID for gyro is used for restoring, it acts as a memory, because it is based on many values not the most recent one as P or the difference as D. I think about I component as the DC current in a signal or as a trim in your TX. Try to fly in Acro mode with I factor equal to Zero, you will find that if you tilt your try then take your hand of the sticks it will not get back, if you add some values to I-factor, it will tend to restore itself. And this is obvious because the I-component –i.e. the integration value not the I factor value- that was accumulated to overcome your stick need to be reduced back to zero. To have this effect I used a simple average variable to calculate the average value of gyro readings in a time window, and if the value is not Zero –higher or lower than a certain range- I is incremented otherwise it is decremented.


A Workable Code


                I attached a working code, you can use it to fly in ACRO mode only, as I used other PID parameters to as ZERO_PIDs parameters in order to study the effects above.


                LEVEL_P: represents High_Enough _1

                LEVEL _I: represents High_Enough_2

                ALT_P: represents time_skip counts.

                ALT_I: represents number of samples used for averaging Error for calculating I factor.

Note: if you put value ALT_I = 0.01 this means actually 10, as the minimum value is 0.001 which is 1. Same for other values, for example LEVEL_P = 1.0 means 10 and value 0.1 means 1 as there is no 0.001 and this is the minimum value for P, so take care when you play with values.


My Samples

              These figures are taken from MultiWii EZ-GUI for 3 flights:


                 as we can see High_Enough_1 = 10 & High_Enough_2 = 15 works very nice. time_skip here is 10 and values that are read for averaging to calculate I-factor is 100.

                 as I increased High_Enough_2 to 20 P values started to raise, especially in the third trial where I played more aggressive with quad compared to the calm first two flights.

Final Notice

                Still everything is experimental, and try it on your OWN RISK, try to fly smoothly and dont take off suddenly, let it leave ground easy.

 Latest Code is Here

Read more…

Zero-PIDs Tuner for Multirotors

This topic is about PID auto tuning algorithm that can tune your Quadcopter from PIDs ZERO as a start value.


       Adjusting PIDs is a problem for many of Quadcopter’ pilots, it would be nice to get your quadcopter to adjust PIDs for itself. I made some investigation in this area, and found many complex algorithms that are related to Adaptive PIDs, and Fuzzy Logic. Although my background is engineering but I don’t like complex math when you can make simple solutions :)

        I started with multiwii version 2.3, I chose it because its code is not that complex, while it has many GUI tools and debug facilities to trace, and it has one of the largest community that can test and verify the results. Anyway I have developed a new mode that I called G_TUNE, which enables quadcopter to calculate flyable PIDs values for ACRO mode. i.e. PIDs for GYRO.

How to Use

       G_Tune mode starts by resetting all Gyro' PIDs for Roll, Pitch & Yaw to Zero’s.  Then pilot needs to takeoff !!  yes it will take off as the algorithm will start instantly to correct errors and update PIDs parameters accordingly. Pilot should try not to make aggressive maneuvers. That is because the error in multiwii is calculated as (RC_Stick - Gyroreading) as stick position acts as rotation speed target i.e. the target rpm, so moving stick suddenly generates false errors.

        The algorithm mainly works as our human eye. what you do is that if you find your quad tilt you give thrust to motor to adjust this tilt. 


      Below is the state machine for the new mode.


    1- As we can see from above state diagram, You need to disarm your quadcopter, then you switch to G_Tune mode. once you do that all PIDs will be Zero and you can test that by switch back to ACRO mode again and try to fly "be careful as you have no control because all PIDs are ZERO"

  2- You can then switch back to G_TUNE the arm your quadcopter. Try to fly carefully, do not make aggressive moves, your quadcopter should fly reasonably stable.

  3- Now switch to GYRO mode in AIR to stop updating the values. dont try to land first. 

  4- Now fly again in ACRO mode and this time it will fly. 

The algorithm was able to generate the following PIDs values for ACRO mode:


Both values in the two screen shots flythe quadcopter


 1- This is a test mode that I tested only on my quadcopter with Simonk ESC, 10x4.5 props and Turnigy 1100 KV. It should work on other configuration, but I have not try it myself.

 2- Moving ELE & ALE sticks just before changing from G_TUNE to ACRO mode could corrupt the values, so please try to fly as stable as possible and switch to ACRO while sticks are almost released for best results.

 3- Switching back from GYRO to G_Tune mode in AIR could be dangerous -however the correction is very fast and it normally works- because PIDs are reset to ZEROs in AIR.




Read more…

Multiwii v2.3 Working on Arduino DUE

Most of us knows Arduino DUE It is a 32-bit ARM processor SAM3X8E that came with alot of expectation that a new era of Quadcopter firmware will be built on it -at least I thought so :) -.

Well that was very inspiring until I found that the new board has no EEPROM to save configuration settings, and the second problem was the 3.3V that made it incompatible with 5V interface.

Naze32was the first thing that made me have a second thought, as they solved the EEPROM issue by using Flash instead. So I started looking for similar code for Arduino DUE and thanks to Google could I found one written by cmaglie :)

Back to 3.3V. A brave man Rouan had no issues when dealing with 3.3V. I believe this is due to logic high is less than 3.3V even when working with 5V logic, so ESC can work directly now. for RX it seems that the 1-2ms pulse with 50Hz is not enough to burn the ports. This is based on my expectation, so I am not sure of the correct reason here.

Anyway I tried to proceed with Multiwii v2.3 and make the code compilable on both 8-bit AVR & new 32-ARM processor.... yes the same code.

It took be 21 days of dedication for this task, but guess what it is done :)

Although the firmware is flyable but not all configuration has been tested or even converted, I made a mass conversion here, but at least it is a good step forward. 

GitHub is here  

Read more…

Python Scripting in Mission Planner


I like the idea of having a script to your ground station. It is a way to implement some logic that your original GUI does not enable directly. It can also enable integration easily with other dlls and modules far beyond the original scope of the Mission Planner. The first thing I asked myself about when I found this "treasure" is what were the available variables and classes that I can already access, well I could not find a clear list, maybe I am not good at googling -which is true-. So I opened the source and tried to figure out myself.  

The main start here is Script.cs it is where the engine class and scope class exist. what we want here is the scope class, it is the INTERFACE point where you can LINK outter world with PYTHON script.

      scope.SetVariable (varname, realobject);

Using above function you can add more objects to link with and define names for it in Python. See the below figure where all objects are defined - and where you can add more if u want.

I traced back the added classes MainV2.comPort, MainV2.comPort.MAV.cs, this, this that are mapped to   MavLink.cs , CurrentState.cs,Script.cs that means any public variable of function in these classes can be accessed from python script.


Lets open Mission Planner and open the script window and check the above conclusion:


In the above image you can see Script.SendRC …. You can find this function in Script.cs 


Same for cs.alt which should exist in CurrentState.cs


Now you can get all the functions you want from these classes, you can even add your own classes and functions.


I hope you find my small blog is useful.


M. Hefny

Read more…

My Tilt-Tricopter on Gears

I built a Tricopter that front motors can tilt forward to gain speed.

I also added gears so that It can take-off and land like a plane !!!

Motors also can tilt-backward so it looks like a Scorpion with high tails and can move backward on gears .



Read more…