Autopilot on Linux, from a device tree point of view

Getting ArduPilot on the BeagleBone Black(and on Linux in general) involves taking care of a lot of operating system related functionalities which are may or may not be related to an autopilot. This is because Linux is used in a lot of different places, so it has a very generic toolset. Especially when it comes to embedded Linux, there are a lot of things that we could do without on an autopilot. In the following post, I'll be giving a brief overview of the device tree, and the choices that we are making and why.

  1. How does the device tree work ?
    A device tree is something which loads device/board specific information at boot. The kernel doesn't include any information about the specific features and requirements of a particular board. It only includes a framework to load the required details when it boots.
    These details include information like

    • CPU frequency
    • Pin modes of the pins (Usually a single pin can be used in different ways as per the mode it is set in)
    • Other such things
      For example, take a look at the device tree written by panto that comes with the official BeagleBone Black images.
  2. What are capes ? BeagleBone Black is a prototyping board. That means different people use it in different ways. It's more of a lego brick than a castle you build using it ;) For building applications using the BBB, one puts a cape on top of it. Depending on what one want's to do, one could use a Replicape, which is a cape for 3D printers, or one could use the Audio cape or the Relay cape. There is one for almost every kind of application and loads more are being developed everyday.
    The PixHawk Fire being developed by Philip Rowse at 3DR is a cape too.

  3. What is capemgr ?
    So a devicetree loads certain pins in certain values at boot. A particular cape may depend on certain other pins too. To load the same from userspace, after the BBB has booted up, we use the capemgr.
    Each cape has it's own device tree overlay, which consists of the pins that particular board uses. These overlaysare dynamically loaded from the userspace.
    This means that using capemgr, one can manipulate pin modes at runtime.

  4. So why not use capemgr It is higly risky for pin modes to be manipulated at runtime for an autopilot. You wouldn't want a pin connected to your barometer lose it's functionality in flight. No need to elaborate the consequences of such a thing happening, either accidently or maliciously.

  5. Loading our own device tree Since we won't be using the capemgr, which was made for loading pins required by capes, we need something to make use of the device tree which loads up at boot. All the pins that are required by will be present in this DT. A script will check that all the pins are loaded as per our requirements and will not allow the autopilot to start if there is something amiss.

  6. Compatibility with other other capes Our approach will break compatibility for all the present capes. It means we won't be able to use BBB as an autopilot and in a 3D printer at the same time, but such scenarios are rare. We will miss out on some relevant capes like LCD cape, etc. But that's not a deal breaker.

  7. Future vision The future vision for Debian, device tree and Linux in general is that we will have our own image in binary available for download, along with instructions on how to build it. We will be having quite a few initialisation scripts that ensure that the Linux has booted up to a robust system fit enough for something as serious as an autopilot.
    We have this in place at the moment, on the wiki. We will be adding a lot more documentation as we progress.

In the next post, I'll be covering how to make changes to U Boot to load the device tree of our choice.

Happy flying :)

PS I am one of the 3 students (along with Victor and Sid) who are working with 3DR for BeaglePilot/PXF.

Views: 1391

Tags: beaglebone, beaglepilot, black, fire, linux, pixhawk

Comment by titeuf007 on June 9, 2014 at 6:01am

i am very excited to see beaglebone flying....

the only problem of this board is the size! but we will have a more powerful fc to compare pixhawk and a lot cheaper


Moderator
Comment by Roberto Navoni on June 9, 2014 at 7:33am

Hi Anuj,

Congratulation for your work and all the other team on BBB :) In the next week I'm try to understand this platform and doing my first fly with you :) I see that is not yet implement the HMC5983 driver ... i can try to implement it myself as small contribution to your work :)

About the DeviceTree , Cape ecc ecc is interesting approach not so standard respect to other linux box that i'm playing until now.

best

Roberto 

Comment by Julian Josephs on June 9, 2014 at 9:51am

How does the PixHawk Fire compare to the regular PixHawk board in terms of capabilities?

Comment by Cliff-E on June 9, 2014 at 9:59am

Just think of the device tree like a text-editable version of the HAL. 

This is where linux (embedded) is heading, all the major distros support it and the standard is maturing.

Comment by Badman Teddy Edward on June 10, 2014 at 3:41am

God speed, you magnificent bastards.

Comment by c j g on June 10, 2014 at 11:47am


Are there other arguments as well? I really think, that breaking standard compatibility is not the best way to go. It also halts devlopments of additional Lidar or FIR Capes ... so, is how great the probability for manipulated pin modes at runtime ?

Comment by Cliff-E on June 10, 2014 at 12:55pm

What is nice about device tree is you can dedicate a pin 'exclusive' (pwm out for example) or not. If it's not exclusive, you can actually switch behavior of pins on cycles. Very interesting option on the sensor front. 

And each device tree (dts) spec can be activated via hot-plugged, so you can have different specs for different capes (designed that way).

Comment by Anuj Deshpande on June 10, 2014 at 10:26pm

Philip has posted information like schematics and other board files here

https://github.com/diydrones/PXF

The capabilities of the board could be better understood there rather than in a comment. It's got loads of stuff on it, and plans for more.
Also, the PXF uses a lot of pins, so the scope of other capes is maybe limited.

Comment by Greg Dronsky on June 11, 2014 at 4:57am

Very interesting work guys!

Will there be a possibility to easily plugin a script in python for example to provide data form px4flow kit to Ardupilot on BBB?

Comment by Swift on July 1, 2014 at 6:57pm

I agree Anuj. It is mandatory that a mechanism exist in order to identify the cape attached to the BBB. And of course without having to recompile the Kernel...  The device tree seems to be a solution in order to "mux things up"  otherwise magic smoke would show up. I spent many hours trying to connect a SparkFun protocape using the lastest image of BBB Debian. Interesting readings:

http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tr...

http://papermint-designs.com/community/node/338

I was able to enjoy my Sparkfun purchase when I flashed the BBB with Angstrom latest image.  Things went well after that following procedures that I learned during my 2 days.... :) far from beeing an expert but is possible that there is something with Debian image that don't compute regarding the device tree?   

Comment

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

Join DIY Drones

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service