Building an Android based autopilot

I bought a PhoneDrone board a couple of months ago, hoping to use the board in order to build some sort of autopilot or plane stabilization in conjunction with any standard Android phone that supports Android 2.3.5+.

My idea is to use the sensors in the phone to stabilize a plane. Initially I thought about stabilizing even a multirotor, but I soon figured out, that would be way to complicated. So I´m starting with a plane. In my case I´m using the EPP-FPV from hobbyking since it has plenty of space to hold all the electronics and flies very docile.

After getting in contact with the nice folks at the 3drobotics support I was able to get some code samples and build a basic prototype connecting all the pieces. A Samsung Galaxy Nexus, the PhoneDrone board, a Turnigy9x receiver and some servos which you can see in the embedded video at the top.

 
The next step is involving the onboard gyro and accelerometer to stabilize one axis of the plane. The code is allready in the repository and I tested it very briefly but I wanted to see first how an APM2.0 stabilizes my plane. Also I´m thinking very hard about backup solutions in case my PhoneDrone-Android setups fails in the air. I´ve studied the failsafe of the APM1 and APM2 and decided to get a  "Wireless Buddy Box System" with  4 or  8 channels from Hobbyking. Dedicated hardware failsafe seems like a good idea to me.

Next steps are actually getting experience with the APM2.0 to get a real feeling what to expect from a plane autopilot since I´ve only used this kind of hardware on multirotors so far. Then I will see how much of the functionality I can cover with the "IMU" that is in my phone. It´s really cool if you think about it, my Galxy Nexus Phone has all the sensors of the APM2.0 (gyro, ass, compass, gps, baro) plus a "modem" and a very handy input device called a touch screen to configure the software :) Plus it has tons of memory, dual core ARM processors and it´s own backup battery.

I´ll keep you guys up to date with my progress here on diydrones. You can also look directly at my github for changes in the code, my youtube channel or twitter.

I´ve also created a google group to exchange ideas and experiences with other people who bought a PhoneDrone board.

Falko, current the Arducopter code updates IMU readings, and flight control at 100hz. This is controlled by a hardware timer, with no scheduler. That means tasks are very close to real time. Having realtime task execution doesn't really depend on how powerful the processor is. As long as you can guarantee that a task is always executed at 100hz, within an acceptable delay, then you're fine. The problem with Android is that without a preemtive scheduler, and realtime kernel, you cannot guarantee the 100hz task scheduling. You can for instance be blocked on I/O without a realtime kernel and miss running the the stabilizaton task for several time slices. That's ok, for non-realtime tasks, since the scheduler will usually compensate by letting the task run longer the next time it schedules in and at the end the task is still getting the same amount of cpu time. However for realtime tasks, missing several time slices, will leave your craft out of control for that amount of time, and there's no making it up later by updating the IMU multiple times, or updating your crafts attitude more often.

This what I think for Arducopter. But, this situation may be different for planes. In the case of planes, a stable platform will fly fine, without the need for constant stabilization, so realtime updates are not so critical. In that case, perhaps an android based IMU may work. On the other hand, one can also argue that a plane is usually flying faster that a multirotor does, and any loss of control is a cruise missile with no guidance system.

To me, a safe flying platform, plane or multirotor, should not rely on an android based phone.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Developer

John Arne Birkeland May 14, 2012 at 6:20pm

Compared to an 8bit AVR, the average cpu(s) in a Android system is just so much faster and has so much more helping hardware that they should offsets any schedule timing errors and comparatively have better "real time" performance then the AVR. At least for AHRS math in the 1000 Hz range. Heck, my Tegra 3 based Transformer Prime as a companion core used just to keep the system alive during idle sleep that is much, much faster then any 8-bit AVR.
johnm545 May 14, 2012 at 11:53am

Real time or not, this works. Here are some tips. You will probably need to root your phone and set the CPU to a constant speed to get anything running off the android handler working smoothly. Otherwise it will throttle right down to one or two hundred megahertz. The sensor event listener, however, seems to run off a hardware interrupt of some sort. On my nexus s, it can spit out gyro readings at 1000 Hz reliably and consistently. Put your time critical code directly in the onsensorchanged callback method, and avoid unnecessary object creation and abstraction in your loops to keep garbage collection to a minimum. It is possible to run the dcm/complementary filter code at 1000 Hz with floating point math while using about 10% CPU... :-)
Ellison Chan May 13, 2012 at 2:18pm

Well, my concern ii with using the phone as the sole IMU. The fact is that a multirotor is impossible to "fly" without some kind of automatic stabilization. I think it may be beyond even and fighter pilot's capability. Without an IMU there's very little that the 2560 can do, other than control the speed of your motors. Again, in the case of an airplane, a stable platform should fly fine without stabilization, so a buddy system would be a good backup, providing that you tell the phone is not working, and was able take control in time. Not trying to discourage any experimentation, just adding a voice of caution.
deadfalkon May 13, 2012 at 1:20pm

Ellison "cruise missile with no guidance system" is a little over the top don´t you think ;-) We´re talking about a foam plane and with the "Wireless Buddy Box System" as an external switch that can take away the power from the autopilot at any time. Maybe I´ll have to see if use the phone only as an IMU and all the processing that needs to be realtime will happen in the ATmega2560.

This will stay an experiment, and I will make sure it is safe at all time. To adress your last sentence: To me also, a safe flying platform should not rely on an phone or even an autopilot, that´s where I come in as a human pilot :)
Ellison Chan May 13, 2012 at 11:31am

Falko, current the Arducopter code updates IMU readings, and flight control at 100hz. This is controlled by a hardware timer, with no scheduler. That means tasks are very close to real time. Having realtime task execution doesn't really depend on how powerful the processor is. As long as you can guarantee that a task is always executed at 100hz, within an acceptable delay, then you're fine. The problem with Android is that without a preemtive scheduler, and realtime kernel, you cannot guarantee the 100hz task scheduling. You can for instance be blocked on I/O without a realtime kernel and miss running the the stabilizaton task for several time slices. That's ok, for non-realtime tasks, since the scheduler will usually compensate by letting the task run longer the next time it schedules in and at the end the task is still getting the same amount of cpu time. However for realtime tasks, missing several time slices, will leave your craft out of control for that amount of time, and there's no making it up later by updating the IMU multiple times, or updating your crafts attitude more often.

This what I think for Arducopter. But, this situation may be different for planes. In the case of planes, a stable platform will fly fine, without the need for constant stabilization, so realtime updates are not so critical. In that case, perhaps an android based IMU may work. On the other hand, one can also argue that a plane is usually flying faster that a multirotor does, and any loss of control is a cruise missile with no guidance system.

To me, a safe flying platform, plane or multirotor, should not rely on an android based phone.
deadfalkon May 13, 2012 at 10:37am

@Ellison I know all that. But I'm hoping since the phone had that much more power, it doesn't matter for my purpose that it is not am realtime capable OS. The question will be, what is the limit of the whole setup. I'm taking the extreme approach trying to do as much as possible on the phone to find out what is possible... I mean we're having quadcore phones now with more than 1 GHz per core, maybe this will be enough power. Why shouldn't it work when there are "realtime" 3D engines available on the market who have to do so much more than stabilizing a plane on one ore two axis...
Ellison Chan May 13, 2012 at 9:32am

Falko, you know, having worked with IOS and Android, that these are not realtime capable OSes. Given this, it would not be safe to rely on the android phone as your IMU. I would recommend using a separate I2C based IMU like a pololu 9dof imu as your main sensor for craft stabilization. It would be safer to have the stabilization code running on the arduino. You could use the Android as a secondary source of flight control, like the joystick interface that MP supports, which injects control packets to the APM.
Douglas D. May 13, 2012 at 8:45am

The shaky servo behavior is dew to the skin/friction on the screen. Garbing and pulling the skin...to fix this i suggest the "anti fingerprint/smug and anti glare screen protector. Should solve your problem for a couple bux on e blaaaaah. Same concept on your laptop mouse pad. Smooth ones become sticky, but the ruff surface ones tend to be much smoother motion and reaction.
deadfalkon May 13, 2012 at 8:00am

I'm using the servo that was included in the sample code. The "fail safe" I build at the beginning is quite smooth. This is still the case, when no phone is connected, it behaves nice. I still have to work on the timing of the communication to the phone, currently it sometimes blocks completely which would be fatal in the air. I come with a Android/iOS background so there might be some arduino/C that would help me keep a stable frame rate. But that is part of this challenge to learn about these kinds of things :)
3D Robotics

Chris Anderson May 13, 2012 at 7:47am

Excellent! I added a link to this on the product page.

of 3

This reply was deleted.