Navio+ and Odroid-C1: the most powerful Linux autopilot

ODROID-C1-NAVIO-darkblue-small

Some time ago we’ve released a new version of our Linux autopilot - Navio+. Main new feature is that Navio+ supports HAT standard and is compatible with Raspberry Pi models A+,B+ and also with… Odroid-C1. It is a new board from Hardkernel powered by quadcore 1.5GHz CPU with 1GB of RAM. Odroid-C1 sets a new standard for performance - it is fast, 10 times faster than Raspberry Pi and faster than most of the single-board computers on the market. It also features EMMC storage for high performance memory operations. Another benefit of Odroid C1 is that you can build APM on it in just 45 seconds.

Here are the benchmark results for Raspberry Pi B+ and Odroid-C1 made by intorobotics.com:

Odroid-C1-vs-Raspberry-Pi-B+

Besides DMIPS, very important improved metrics are system call overhead and context switching that will positively affect real-time capabilities.

We’ve added support for Navio+ and Odroid-C1 combo in APM. The porting was mostly straightforward thanks to the APM’s HAL and as we already had the drivers for Navio+. As Odroid-C1 is a new board, not all required system features were implemented and we had to do some tuning. Luckily, Hardkernel team is very responsive and great in communication and helped us solve the problems as we found them.

Most of the features are implemented for C1 such as toolchain configuration, build target, IMU, baro, GPIO driver, RGB LED etc.

But we won’t be kept without work, a couple of things are still left to do:

  1. RT_PREEMPT kernel. The real-time patch doesn’t apply as smoothly as on Raspberry Pi’s Linux, so we’ll have to deal with that by manually applying the failed hunks.
  2. RCInput. This is a tricky part on Linux, but on Raspberry Pi it was solved by using DMA. We can go that way too, but Amlogic S805 has quite a few other peripherals we can use - unlike BCM2835 it’s got a lot of spare timers that can generate 1us interrupts. Datasheet was only released a couple of days ago and we’re currently exploring the possibilities.

APM’s port for Odroid-C1 is available here:

https://github.com/emlid/ardupilot/commits/navio-odroid-c1

For now our main goal is to take Odroid-C1 into the air and we believe that many exciting projects will follow, that will take advantage of incredible processing power.

Just got my ODROID-C1 today. Can’t wait for the Navio+ to get here so I can start taking over the world… one rover at a time!

Hello

I am getting ready to work with the odroid and navio. I can see the link for the APM port but since you don’t have a RT kernel or an OS image available yet, can you advise on which OS image should be used so I can have a functional navio odroid combination for testing

Thanks in advance

@jtengland Hehe, sounds like a plan :smile:

@amitganjoo There are some additional settings required to make Odroid C1 work with Navio+ so it will be hard to test with default image. RT kernel was quite a challenge, but @mikhail.avkhimenia made great progress on it. I believe that first release of image might come out this week.

I don’t mean to hijack this thread but don’t want to start another for a simple question. I’m very interested in using this board for my Navio+, but it looks like the ODROID only supports 720P Video input (through the USB 2.0), compared to the 1080P on the Raspberry Pi (through MIPI). Anyone know how I could record 1080P on the ODROID through a camera module? (not external camera unit recording 1080P then transferring 720P data, adds weight)

Thanks.

How about a 1080p USB camera module with h.264 compression built in? Or an IP camera with h.264 compression.

1 Like

@igor.vereninov

Is there any news on the progress of the open issues?

I am able to build the navio-odroid-c1 branch of the ardupilot fork, and would appreciate if can use the mean time until the navio+ arrives to check out and experiment with the rt-kernel.

I haven’t found an odroid branch for the rt-kernel on github yet, do you have any hints for me were to look?

thank you

My latest build of the kernel was running ArduPilot with a stress for all night and didn’t crash or freeze so far. I’'ll do a couple of more tests and if it’s okay I’ll upload it soon.

A little update about the Odroid - it crashes under storage stress with SD card. It’s not rt-preempt related, as it crashes on default kernel too. We’ll contact Hardkernel team and will try to solve that issue.

Did a little more digging. I believe the stats for the 720P may be because they used THEIR 720P camera they have available for sale. Looking up the bitrates of 1080P video and USB 2.0, it should be plenty fast enough.

For ref: https://www.avforums.com/threads/streaming-1080p-mkvs-via-usb-2-external-hdd-viable.881720/

Affirmative,

I already had my first crash with the SD storage while cloning from github …

:smile:

Just to let you people know …

the pixhawk team is discussing porting the px4 firmware to odroid and navio+:

see more details here:
http://pixhawk.org/dev/ros/px4linux?s[]=navio

Yeah, we are aware of that. We are in touch with them :smile:

rawshark, could you please try to repeat the SD crash with the default kernel?

mikhail,

i’ll test excessive access to sd today …
and let you know the results.

regards

time sh -c “dd if=/dev/zero of=ddfile bs=1024 count=2000000 && sync”

2000000+0 records in
2000000+0 records out
2028000000 bytes (2.0 GB) copied, 119.99 seconds, 16.9 MB/s

It is damned slow for an micro-sdxc card, but no crash so far.

Best Regards

Raw

After updating:

Linux odroid 3.10.69-71 #1 SMP PREEMPT Mon Feb 23 21:04:31 BRT 2015 armv7l armv7l armv7l GNU/Linux

2000000+0 records in
2000000+0 records out
1.) Run …
2028000000 bytes (2.0 GB) copied, 141.777 s, 14.3 MB/s

real 2m23.968s
user 0m1.430s
sys 1m1.630s

2.) Run

2028000000 bytes (2.0 GB) copied, 117.31 s, 17.3 MB/s

real 1m59.175s
user 0m1.450s
sys 0m56.330s

Performance is not getting better, but no crash so far

I don’t think it’s just the storage load by itself, but storage + load. Could you please try running:

stress --cpu 8 --io 4 --vm 2 --hdd 2 --vm-bytes 128M --timeout 2500s

That’s the only situation when I’m able to crash it.