3689600054?profile=original

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.

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • 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?

  • 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.

    diydrones/PXF
    Contribute to diydrones/PXF development by creating an account on GitHub.
  • 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).


  • 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 ?

  • God speed, you magnificent bastards.

  • 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.

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

  • Moderator

    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 

  • 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

This reply was deleted.