Siddharth Purohit's Posts

Arducopter performance over Linux board Beaglebone with APM4.0 (aka Pixhawk fire cape)

Posted by Siddharth Purohit on September 5, 2014 at 1:21pm

Hello everyone, beaglepilot project has reached two most important milestones in the last couple of weeks. First one was first Arduplane flight by Andrew Tridgell: First Flight Plane and first Arducopter flight by Victor Mayoral Vilches: First Flight Quad. As Victor mentioned in his blog post that he was running Arducopter @ 100Hz and that we are working on enabling 400Hz. In this post I'll be sharing some figures which display performance of Arducopter running @ 400Hz and under three prominent conditions, the conditions are as follows:

1. no load: The code is executed without any stress i.e. no extra software is run besides background processes.

2. Very heavy load: The code is executed under very high stress environment: 2 CPU-bound processes, 1 I/O-bound process, and 1 memory allocator process. Under this environment CPU is running @ 100% and MEM is running @ greater than 50% overall.

3. Only CPU load: The code is executed with load only over CPU (100%) using 7 CPU-bound processes.

Tool used for analysis is a tool named Stress which is a simple workload generator for POSIX systems.

Following is a chart of results obtained:

click on the image to checkout full perf gists.

Description about kernels used:

Preempt-rt: this version of kernel is 3.8.13 with preempt-rt patch (about) and basic preemption enabled.

Vanilla: plain 3.8.13 kernel without any patch or extra configs.

Preempt: this version of kernel is plain 3.8.13 kernel with preemptible kernel option enabled.

You all are welcome to share your conclusions or critique on this data.

Thankyou.

Regards,

Siddharth Bharat Purohit

The sPRUnal chord of Beaglepilot continued

Posted by Siddharth Purohit on June 19, 2014 at 9:00am

In my last blog post i discussed how PRU can be useful in the development of Beaglebone-Linux-Ardupilot based Autopilot. In this blog post i'll be sharing how it is being implemented presently on beaglepilot. PRU-PWM (PWM generation using PRU) is in development stage and there are many possibilities to make it work at its best.

Implementation of PWM generation using PRU is based on the work by Pantelis Antoniou on testpru & driver to go along with it. Initially I worked with AM335x PRU Package for uploading the firmware in binary format. After seeing the power and ease of usage of Pantelis's infrastructure I moved to implement it inside Ardupilot HAL. Pantelis's infrastructure works on the basis of upcalls and downcalls. All three cores constantly keep in touch by raising signals to each other so that they can inform each other what to do next, while data exchange occurs via shared memory. Also sysfs interface is provided so that userspace can communicate with PRUs.

All was perfect until the measurement of time taken for writing PWM value for each channel was found out to be between 500-1000us, which is about 20 times higher than required. The bottleneck in the whole apparatus was sysfs interface, opening, writing and closing of files took a of time. So we had to let go of sysfs interface and thus only purpose of driver was to load the firmware. Another thing we need to let go of is the rproc and virtio implementation done by Pantelis which was unnecessary for Ardupilot and consumed one extra PRU core. So final implementation is as follows: Firmware is loaded to PRU, All pins required as PWM channel (which actually are R31 bits as explained in previous post) are declared to be used using cape manager overlays for now, but will be declared under device tree in future. Ardupilot (Userspace) communicates and exchanges data via placing data directly into Shared Memory via mmap, no signals are raised because communication is between only two devices and simplex type(PRU1 and ARM, PRU0 is not in picture now and will be serving other purposes like PPM reader or sensor data time stamper etc). Data is placed into the shared memory along with access flag, application on both side poll for the access and change the value of access flag data when they have placed it into there local memory(in PRUs case) or writing into shared memory is complete(in ARMs case). Another task in this development is to create an independent firmware loader either in userspace or in kernel space as driver. The firmware loader should be able to load elf files into the PRU. For now Pantelis's driver is handling that task, until everything is going well we can turn a blind eye on independent firmware loader's development.

All in all after making these changes, PWM write time for each channel reduced to 10us with some occasional measured time of 500us-1000us, the reason for which is yet unknown. It would be great if you all can share your views on this implementation.

Regards,

Siddharth Bharat Purohit

The sPRUnal chord of Beaglepilot

Posted by Siddharth Purohit on June 7, 2014 at 1:10pm

An Axiom: You just can't make your unmanned vehicle of any use until all its actuators respond correctly. Which means there should be enough means, i.e. PWM ports in ardupilot's case ,to control them correctly. How can this be achieved on a linux machine(BeagleBone (Black))with just six PWM channels. You don't just want your unmanned vehicle to travel (well you may require more than six channels for doing that too), you require PWM for many things and we can start our list with operating camera gimbal. Software PWM on a Beaglebone is close to unthinkable, even 20-50us of latencies in toggling PWM pin can lead to your beloved vehicle's devastation, and can even cause harm to you and people around you.One way is to add another hardware to generate as many PWMs as you want. This can be the way then, you might wonder. However, it is rather better if you can do everything with as few things as possible. So here comes the PRUSS(Programmable Remote Unit Subsystem) in the picture. There are two PRUs in am335x microprocessor , lets call them PRU0 and PRU1. The beauty of this system is that the three cores: ARM core, PRU0, PRU1, act as conjoined triplets. Except the general purpose registers, each and every part of there memory is mapped to each other's memory. For example I can very easily access GPIO peripheral belonging to ARM core via PRUx and toggle them, leaving linux kernel running on ARM core asking to itself "who is trying to play with my things?" but it will never know. Well, i guess you all agree its not a pretty thing to do. Don't worry we will not trouble our sweet kernel as there is another tool which PRUSS technology has got in its arsenal: All the bits of General Purpose register R30 are mapped to physical pins. So there you go, you just got 32*2 i.e. 64 pins waiting to be acting as PWM channel with resolution as low as 4ns. Also, If you don't mind troubling linux kernel and a few 100ns latencies are fine by you, you can convert each and every GPIO pin into a PWM channel(but i don't think anybody will be required to go that far).Many of you might have started asking questions to yourselves, well why not just port ardupilot to PRUSS cores rather than ARM core seeing it is so powerful? PRUSS is no doubt a very fast core running at 200MHz but it has very little memory, only 4Kb Program and 8Kb Data RAM: you can't even fit in a printf code with floating point support into PRU's PRAM. PRUSS in beaglepilot system is being utilised like our Spinal Chord. They will do any menial recursive tasks like generating PWM or may be if required collect and pass timestamped sensor data but they can't be utilised for major data crunching or storing purposes. Therefore any task which has very small memory requirements but require not only hard realtime but also very narrow execution time is to be thrown towards PRU to handle.So I guess this post, at-least in part, answers some of the questions like: Why use BeagleBone Black platform? How PRU is useful to the Beaglepilot project? But leaves you with the question: How it is actually being implemented inside Beaglepilot? I'll leave you all with this question until next time.Regards,Siddharth Bharat Purohit