DPRG
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: Huff, Brian L bhuff at uta.edu
Date: Sun Feb 8 11:06:01 CST 2015

Hello David and Blackstag,

Once again David, I find your comments informative and consistent with my experience.  I was surprised to learn that the PRU's on the BBB's had a C development option.  I thought we were stuck with assembler.

For good or bad ROS seems to gobbling up the oxygen in the Robotics community discussions, particularly in the Research and Open Source "Commercial" Startups.  I think ROS is for software lovers more than hardware lovers; just my personal opinion and observation.  The BBB does provide possibly the best nexus  between "big world computing" i.e. ROS / Linux and "Small World Computing" self managed hard real time (HRT) I/O intensive control, i.e. traditional microcontroller environments.  Hats off to the TI engineers that realized that HRT was not going to be easy (even possible) through the ARM layered cash architecture.  Hence the inclusion of the PRU's with their dedicated I/O access.  The shared memory between the ARM and PRUs allow these two worlds to work together.  (As best I understand it).

Thank you to all of the DPRG members that contribute their thoughts and "golden nuggets" of information to the community.  I have not been a very faithful DPRG member.  Sorry.  Do you guys have an on-line dues payment and Membership signup page?

Brian Huff
________________________________
From: dprglist-bounces at dprg.org [dprglist-bounces at dprg.org] On Behalf Of David Anderson [davida at smu.edu]
Sent: Sunday, February 08, 2015 10:12 AM
To: blackstag; dprglist
Subject: [DPRG] BBB: (was Video of Drone Contolled by BeagleBOne Black Running APM Pilot Software)

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... :)

cheers
dpa


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/2c5aa3d5/attachment.html 

More information about the DPRG mailing list