We use the Odroid U3 to control a quad-rotor (no microcontroller-based flight control, just plain Linux control code). As a Linux distribution on the ODROID we use Gentoo, and of course our quadrotor natively compiles all of its software (kernel, userspace) :D
Please have a look at our first operating prototype:

A more detailed picture with annotations is provided here:

As you can see, on top of the U3 we use the IO shield from ODROID. The U3 io shield is programmed with a simple firmware similar to FirmataC, which:
- parses PPM RC receiver signals and sends them to ttySAC0
- reads pwm outputs from the autopilot via ttySAC0 and generates the PWM signals.

Some additional electronics, including power supply, logic level converters and a I2C IMU (MPU9150 + MS5611) sensor are placed on top of the IO shield. The GPS receiver is connected via USB and we have WiFi and a Webcam connected to USB as well.

The software for controlling the UAV is called PenguPilot. It is freely available via Github here, but the documentation is in an early stage: https://github.com/PenguPilot/PenguPilot

Stay tuned for the next update (in-flight video) and do not hesitate to contact me.

Views: 11848

Comment by Juraj Kolesar on June 25, 2014 at 12:27am

According to my experience with MCB (Master Control Board) linux kernels run ok while you do just simple tasks. Once you start adding load to CPU, the timer starts to generate more leaks. Let's say we evaluate the PWM outputs planed every 5ms. Everything runs OK. But when you start other tasks (e.g. streaming video) the outputs update starts to float around 8-10ms. You can not see it directly on the flight, but when the CPU load is heavier the time leaks starts to float far behind planned 5ms. And it becomes dangerous, because sometimes you can also see the fallouts of the PWM rotor outputs.

But looking at your solution description it seems that you have additional microcontroler taking care about the real control timing, but you just call it "U3 IO shield". So it is not a clean plain Linux control. Am I right?

Currently I am working on something similar. I call it "pilot&navigator" solution, where pilot is APM2.6 and navigator is RaspberryPi. APM is piloting (controlling) the flight and RasPi is navigating (computing waypoints, requested heading, video streaming ...). After our experience (including not just damaged props) we drop all the solutions performing all task on one CPU and divide it. So the "pilot" board must care just about the pilot tasks, and don't be bothered by something else.

Comment by Tobias Simon on June 25, 2014 at 2:04am

Hi Juraj, it is plain Linux control.

The Linux program reads the MPU-9150 sensor via I2C, performs sensor fusion and computes the 4 motor setpoints.

The IO shield just generates the PWM signals for the motors. We could also use a board like this via I2C instead: http://www.abusemark.com/downloads/stm_manual_v2.pdf (which we actually do for our Raspberry PI based copter)

Comment by Tobias Simon on June 25, 2014 at 4:03am

Here comes some info regarding LLC and sensor/actuator interfacing:

The bottom view of the io board interface/power circruitry looks like this:

My friend Alex has already designed a custom U3 IO shield, which combines the two boards and provides a 3.3v and 5v i2c interface: Custom odroid IO shield

Comment by Tobias Simon on June 25, 2014 at 4:05am

In the lower picture it should be "LLC 1.8V/3.3V", not 5V...

Comment by Juraj Kolesar on June 25, 2014 at 7:39am

Ok understand, so the shield is basicaly PWM interface for Odroid and kind of I2C bus for sensors, but the values are calculated directly on board.

Have you tried already what I described above? To put some CPU load, if you see some time leaks? We were able to see it from the logs, where we measured time between two cycles of calculation values for PWM. If there were no additional load the values were stable within 100microseconds around 5 ms.  Once the load was increased the time was jumping around about 3ms. And sometimes it was increased up to 20ms.

Comment by Tobias Simon on June 25, 2014 at 9:47am

Yes we did these kinds of measurements. We basically logged every control step into a file and after the run, looked at the time deltas.

If you set the correct scheduling policy and priority via sched_setscheduler, then there is (nearly) no influence of additional load running at a lower priority. Thus, you can see 100% CPU utilization but the time deltas are not influenced due to correct scheduler behavior (you need at least CONFIG_PREEMPT in your kernel config).

Comment by Tobias Simon on June 25, 2014 at 11:26am



This is our Gumstix Overo based "PenguCopter" :-)

Comment by hotelzululima on July 1, 2014 at 10:31pm

Hi Tobias.

     have you looked at the parallela OpenCL 16 core boards yet?



ps just got 2 of these in...

Comment by Tobias Simon on July 1, 2014 at 11:35pm

This board looks interesting! Thanks for sharing

Comment by hotelzululima on July 2, 2014 at 8:57pm

@tobias.. the adapteva/parallela shop reopened again today and has stock again in case you were NOT in time last friday... to snatch a couple



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

Join DIY Drones


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

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service