DPRG List  

[DPRG] BBB: (was Video of Drone Contolled by BeagleBOne Black Running APM Pilot Software)

Subject: [DPRG] BBB: (was Video of Drone Contolled by BeagleBOne Black Running APM Pilot Software)
From: David Anderson davida at smu.edu
Date: Sun Feb 8 10:12:32 CST 2015

Thanks Jason.

One of the main reasons I have stuck with the much-outdated MC68332 
processor in Mark Castelluccio's excellent MRM board all these years for 
most of my robots is because of the on-chip 16 channel TPU co-processor, 
and it's shared memory segment with the main CPU.

Other options have pretty much all required going to multiple processors 
with some sort of comm protocol and all the inherent hassles therein; 
latencies, multiple development environments and tool chains, and the 
need to solve problems in multiple hardware spaces.  It gets hairy 
pretty fast.

But it looks like maybe the ARM + PRUs of my BBB might be just the 
ticket.  Still needs two development environments, ARM and PRU, but 
there is shared memory for comm, and lots of low-level I/O access.

Not sure I need Linux though, with which I am very familiar.   I have a 
light-weight realtime executive that is perhaps more targeted to 
realtime robotics than Linux is, that I can run on the ARM.  Just 
thinking out loud here.

My current focus on robot AI is more down at the ganglia level than the 
level of the "brain."  I think that's where we are currently in robot 
evolution.  Where life was about 4.5 billion years ago.  We're still 
working on the cell-level machinery, by that model.  C3PO, which might 
need Linux or something like it, is in my estimation, still a very long 
way off.

At some point, one of those hobby ROS robots may do something amazing, 
and I'll be a convert.  As of now, still waiting... :)


On 02/05/2015 07:11 PM, blackstag wrote:
> http://www.embeddedrelated.com/showarticle/603.php
> On Thu, Feb 5, 2015 at 4:23 PM, David Anderson <davida at smu.edu 
> <mailto:davida at smu.edu>> wrote:
>     Dick,
>     Good find.  Haven't watched it yet, but this phrase caught my eye:
>     "There's a C compiler for the PRU."
>     Any details?
>     dpa
>     On 02/04/2015 12:27 PM, Dick Swan wrote:
>>     This is interesting 48 minute video
>>     <https://www.youtube.com/watch?v=2Twl2mQAh6g> from the lead
>>     developer of APM Pilot. It was given at a LINUX conference. He
>>     was describing the successful results of running APM code on LINUX.
>>     Here’s my comments on some topics in the talk indicating the
>>     approximate time in the video that it occurred.
>>     4:38 Live demonstration of a drone / airplane controlled via
>>     LINUX port of APM Pilot on a BeagleBone Black (BBB). The drone
>>     was at an airfield some distance from the conference location and
>>     watched a video as it took off, flew to way points and
>>     autonomously landed. LINUX console was remotely running on the
>>     overhead screen along with a video (Skype call) of the plane.
>>     6:38 Drone was compiling LINUX kernel at same time as flying. On
>>     the BBB the kernel compile takes 5-6 hours because of relatively
>>     “low powered” CPU) when dedicated to this task. The compile time
>>     increases when APM is also running to around 10 hours.
>>     1,200 SPI transactions per second from IMU in this application
>>     (i.e. simultaneous  APM Pilot and Kernel compile). Elsewhere he
>>     mentions 4K SPI per second.
>>     Uses a BBB “Cape” (similar to a Arduino “Shield”) to provide the
>>     navigation sensors. Several BBB Capes now exist that contain the
>>     appropriate navigation sensors (i.e GPS and IMU and barometer).
>>     For example, the successful NavIO Cape from Kickstarter; and
>>     recently announced NavIO+. Plus several more Capes from others.
>>     Most (all?) were introduced in the last year.
>>     20:21 Uses inline waits for sending 20 byte SPI packets. Better
>>     (faster?) than DMA because DMA setup has too much overhead.
>>     22:05 Why use “user space driver” instead of kernel drivers?
>>     Answer: Same driver source code used on LINUX as on Arduino APM!
>>     Same drivers run on different OSes! It wasn’t explicit but it
>>     seemed the user space drivers were for SPI and I2C; it was
>>     unclear if the low level SPI/I2C hardware control was in kernel
>>     space.
>>     24:00 Future will see many of the current I2C sensors (gyro,
>>     accel, compass, GPS) migrate to CAN Bus.
>>     24:58 Describes how APM handles real-time critical threads –
>>     they’re described as LINUX “FIFO scheduled real time task” with
>>     pages locked, predefined stacks, etc for best performance.
>>     There’s six critical tasks that run in APM.
>>     27:15 Some problems with “jitter” on the long duration nominal 20
>>     millisecond loop.
>>     ·19 of 2M loops (i.e. a 11 hour run) were over 30 msec. This was
>>     the same run APM with LINUX kernel compile in background. 18 of
>>     these were under 50 msec. Easily handled by APM Pilot since all
>>     the calculations running on the 20 msec loop adjust for the
>>     actual loop time rather than assuming it is “precisely” 20 msec.
>>     ·Longest time was 1.7 seconds. This is a bug. Possibly writing to
>>     SD Card with interrupts disabled and waited too long.
>>     31:20     Two things need microsecond timing; i.e. servo pulse
>>     input and PWM servo pulse output. Solution uses the 200 MHZ
>>     simple PRU (Programmable Real-time Units) on BBB. PRUs have
>>     direct access to GPIO pins. I think PRUs are on-board the CPU
>>     chip. PRUs have shared access to the BBB memory. There’s a C
>>     compiler for the PRU. Total source code for the PRUs is 300 lines.
>>     37:00 Description of latest Outback challenge competition held
>>     Oct 2014. It’s a “search and rescue” autonomous drone looking for
>>     a human (via image recognition) at an approximate GPS location 6
>>     miles away. Drone needs to fily to approximate location, search
>>     for the human and then drops a water bottle to the human. APM
>>     team won the competition. Many of the other entrants used chunks
>>     of APM code.
>>     38:30 Picture of image recognition from Outback challenge. It
>>     looks similar to the images you see from a CMU Cam where color
>>     blob is highlighted with a rectangle overlaid on the camera
>>     image. I’m amazed at how the image recognition found a human
>>     shape from the air.
>>     Some of the new sensors drivers in development for integration
>>     with APM include.
>>     ·Optical flow sensors
>>     ·Laser range finding. Pointing downward for containing altitude.
>>     ·Use Android quad-core (i.e. lots more CPU cycles) and then do
>>     image recognition using increased processing power.
>>     _______________________________________________
>>     DPRGlist mailing list
>>     DPRGlist at dprg.org  <mailto:DPRGlist at dprg.org>
>>     http://list.dprg.org/mailman/listinfo/dprglist
>     _______________________________________________
>     DPRGlist mailing list
>     DPRGlist at dprg.org <mailto:DPRGlist at dprg.org>
>     http://list.dprg.org/mailman/listinfo/dprglist
> -- 
> for secure mail be sure to mail me with proton mail at 
> blackstag at protonmail.ch <mailto:blackstag at protonmail.ch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.dprg.org/pipermail/dprglist/attachments/20150208/1a71b0fd/attachment.html 

More information about the DPRG mailing list