Blogs

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.