Flying with Linux at LinuxConf 2015

Ardupilot developer Andrew Tridgell has presented 'Flying with Linux' at LinuxConf 2015 in Auckland, New Zealand.  During his presentation Tridge connected to the running autopilot software of a plane being flown in Canberra Australia by CanberraUAV chief pilot Jack Pittar and Grant Morphett. A Skype connection to Grant's phone was used to display the flight to the audience in New Zealand.

Running Ardupilot on Linux enables other cpu intensive processes such as image recognition software to be run on the same platform as the auto pilot. To demonstrate how capable the system was of multitasking, a new linux kernel was being compiled while ardupilot was also being run to fly the plane. Compiling software typically places a very high load on a system but ardupilot ran normally flying the plane three times around a circuit. The plane even did a successful auto landing despite high winds.

Flight telemetry streamed live to the presentation while Tridge explained how the system was configured and the work that the CanberraUAV team had done since his last presentation a year ago. This work included winning the prestigious Outback Search and Rescue Challenge held in Queensland Australia last year.

3689634108?profile=original 

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • 3701915699?profile=original

  • Developer

    @Bim, you can access the mavlink data either internally over UDP or TCP, or via serial ports, or both

    I haven't yet investigated using CPU affinity on multi-core Linux. Once my C1 arrives I'll be able to play with that

  • Developer

    @Victor we have a libraries/AP_HAL/Util.h function set_system_clock() that is called when we get GPS lock. Right now we only call it on PX4, but we should be able to use the same code on Linux. See:

    https://github.com/diydrones/ardupilot/blob/master/libraries/AP_HAL...

    maybe you could do a PR that enables this on Linux too?

    It would be even better if we had a battery backed RTC on the Linux boards. We should probably make it not set the system clock if it is already within some margin of the GPS time (perhaps 2 minutes?) so it doesn't override a system that has a battery backed RTC

  • @Víctor Mayoral

    You could connect to your Odroid using the same serial ports you use in your PixHawk

    Should've been more clear, I meant how would I access sensors and send commands from the BBB it self.

    That depend on how you code your image recognition code. If you set your threads to SCHED_FIFO and assign a higher priority than the autopilot then it might be the case.

    I know very little on how Linux works and operating systems in general, so I'm worried a bug on my code could crash the aircraft.
    I mean, every once in a while I'd crash my computer or get it to freeze due to bugs in my code.
    That's why I personally feel more comfortable with a 'companion computer', having a separated flight controller I can't mess up would make me sleep better.

  • That was great Tridge! Congratulations.

    @Bim,

    Currently I'm accessing real time flight data and sending commands via mavlink (Pixhawk connected directly to an ODROID), how does it work on Linux APM? Can a user access raw sensor readings without interfering with the flight controller?

    You could connect to your Odroid using the same serial ports you use in your PixHawk. Additionally you could use the Ethernet port integrated on the BBB, another option is Ethernet-over-USB, wireless connections between the boards (i wouldn't go this way though), ...

    Regarding the loop iteration that took 1.7 seconds, if you'd use a multicore computer (Like the ODROID-C1 you mentioned), could you configure it to dedicate one core completely to the APM and avoid incidents like that? I'm worried that code I write (Image recognition for example) could crash the OS and crash the aircraft.

    That depend on how you code your image recognition code. If you set your threads to SCHED_FIFO and assign a higher priority than the autopilot then it might be the case. This publication might help understand how it works.

    I encountered the same annoyance of having to set the clock every time, so I just made it automatically set the clock according to the GPS.

    This is quite interesting. @Tridge is there a good reason not to do this ourselves? We are experimenting with 4G which might be another way of getting the time right.

    Cheers,

  • Just watched the entire lecture and enjoyed every part of it.

    Few questions from a novice,

    Currently I'm accessing real time flight data and sending commands via mavlink (Pixhawk connected directly to an ODROID), how does it work on Linux APM? Can a user access raw sensor readings without interfering with the flight controller?

    Regarding the loop iteration that took 1.7 seconds, if you'd use a multicore computer (Like the ODROID-C1 you mentioned), could you configure it to dedicate one core completely to the APM and avoid incidents like that? I'm worried that code I write (Image recognition for example) could crash the OS and crash the aircraft.

    I encountered the same annoyance of having to set the clock every time, so I just made it automatically set the clock according to the GPS.

  • BTW I have just ordered a Raspberry B+ so I can get a Navio+ board going.  Your talk was intruiging and I cannot wait to try it out so I will get it going on the Raspberry and then switch to the C1 when they have an image available. Having run SITL it seems from the instructions that the BBB is just running an .elf file that SITL runs in a different way.

  • @Tridge - Interesting - thanks for the reply.  I guess you did not want to have a 3G USB dongle on the BBB.  OpenVPN works really well and it is amazing what you can connect over it.

  • Developer

    @Stephen I used OpenVPN to establish a VPN to Grants laptop which was connected over a 3G link, then had two telemetry radios from his laptop to the aircraft, one for telemetry, one for the root shell

  • Moderator

    That's nuts well done Tridge and team.

This reply was deleted.