**There is a new puppy in the family !!**
**PocketPilot** is a smaller versions of the BBBmini (https://github.com/mirkix/BBBMINI), designed for use with PocketBeagle (https://beagleboard.org/pocket, a small version of BeagleBone Black). It provides a very small & light-weight open-source ArduPilot based autopilot / flight controller for quadcopter drones & robots.
**Summary of Technical Specifications**
Processor: Octavo Systems OSD3358 1GHz ARM® Cortex-A8
512MB DDR3 RAM integrated
Integrated power management
2×32-bit 200-MHz programmable real-time units (PRUs)
ARM Cortex-M3
72 expansion pin headers with power and battery I/Os, high-speed USB, 8 analog inputs, 44 digital I/Os and numerous digital interface peripherals
microUSB host/client and microSD connectors
For test and initial developments, I have build a prototype using through-hole components & connectors, with sensor modules soldered directly on the breadboard. Since it doesn't need any SMD components, this is relatively easy to build, for an experienced builder by following this schematic:
Please note that there is no ESD protection for USB1 on the prototype, so be very carefull if you plan to use it. We will implement proper protection on a PCB release.
The initial flight test was performed on a 450 class quadcopter == Youtube video
Please note this is flying indoor using optical flow (Lidar Lite V3 and PX4FLOW)
**Integration on a 180 size quadcopter**
In order to reflect the compactness of the PocketPilot , I have integrated the prototype into a KingKong 188 (Aliexpress) quadcopter with these components:
4 x Multistar 1704 and DYS20 A ESC (Blheli)
5 Amp UBEC
Micro Flysky PPM receiver
900 Mhz Telemetry radio with Pigtail Spring Antenna
3S Battery 1800 MAh
VL53LX0 TOF RangeFinder
There is no special instructions for the build but you need a good UBEC with a steep voltage rising curve in order to get the PocketBeagle starting becauses of the power/battery management unit.
This is one of the first test on the KingKong, its flying Alt-Hold using the 7$ VlL53L0X TOF RangeFinder
**LINUX and SOFTWARE**
A special thanks to **Mirko Denecke** for having adapted the BBBMINI ArduPilot code to the PocketPilot and **Robert C Nelson** for making the OS Images including: Linux Debian, Kernel with RT patch and the uboot overlays; allowing to define the IO using a configuration file, making the BeagleBone such a powerfull Linux Embedded Computer.
You can read the instructions here:
https://github.com/PocketPilot/PocketPilot/blob/master/PocketInstructions.md
**MORE TO COME:**
For anyone interested, we are planning to release a complete sensor cape for the PocketBeagle so stay tuned :slight_smile:
Comments
Hello Curt
If you look on the table above you can see that UART2 is not the default mapping, it is SPI0.
You need to configure PINS in order to get Uart2 exposed.
Loo at the way we remap here
https://github.com/PocketPilot/PocketPilot/blob/master/config/pocke...
Hi Patrick,
Hopefully you don't mind me asking a pocketbeagle question? Are you using /dev/ttyS2 in your system? I have ttyS4 working great on my pocketbeagle, but I've been trying all day to get ttyS2 to talk with zero luck. The device driver is there, I can open the device without error, but trying to read or write doesn't nothing? Did you have to do anything special to get ttyS2 working on your system? I'm running the Debian 9.2 image here from beagleboard.org.
Thanks!
Hello Curt
PWM, depending on how you map the Pocket , take alook at the config pin file and you will everything we are exposing: https://github.com/PocketPilot/PocketPilot/blob/master/config/pocke...
For sensors, if you look at my schematic you will see : MPU9250 IMU-COMPASS & MS5611 Barometer , both on SPI.
Concerning the connector, the prototype is using 0.100" headers, we will release a PCB based PocketCape with stadardised DroneCode JST-GH connectors and associated pinouts.
On note on building , I used 18mm long pins headers and ajusted height so I can use connectors on both sides. If you look at the picture, you will see that all the ''others'' peripherals = Telemetry Radio and Range finder are connected using doublerow pass through smd type female headers , 26 Gage multistrand and single row female header for interfacing:
P.S. For ease of reading, I have removed referenced to your project, hope you will publish soon ;-)
Hi Patrick, ok I do have a couple questions. Sorry if any of this is stated obviously and I missed it. How many PWM outputs can the pocketpilot support? I see 4 obviously for quad copter use, but can you do more than that? What are you using for sensors (imu, gps, pressure, etc.) I wasn't confident I could figure this out from the pictures. Are you talking to the imu via i2c or spi? Do you have support for additional analog ins (like for reading battery voltages or current draw?) Do you do anything with supporting JST-GH / DF13 connectors or do you wire everything back to the pocketbeagle 0.1" headers? I don't think throughhole versions of the JST-GH connectors exist so supporting those pretty much requires a reflow oven -- or cable surgery/splicing to change the connector to something else. Blah! Plug and play is nice when it works!
I noticed the latest beaglebone images come with all the arducopter/plane/rover software preinstalled, wow! (I finally booted up my pocketbeagle this morning and was poking around and noticed these packages when I ran apt update.)
Thanks!
Thanks Marc
The code is in Master and the ADC is now exposed on the new Images.
Mirko is testing the DSM code and will update wiki pretty soon.
If you want to test it now, I just left the instructions for the Blue on the BBMINI Gitter:
https://gitter.im/mirkix/BBBMINI
Yup. I *really* like the concept of the PRU's, but have chosen an easier path to follow by adding my own easy-to-program external processor. I use the teensy to handle all the interrupts and hard real time chores. This simplifies the higher level code that runs on the beaglebone. I have setup the two processors to communicate over a shared UART at 500,000 baud. The whole system runs at a tight 100hz.
I will definitely share video when I get my new board up in the air, but I have a previous evolution of this same basic system and software that has been flying successfully (and being used in projects and research) for several years now.
Here is a video of my current system which uses a full size beaglebone, and atmega2560 companion cpu, mpu6000, ublox8. In the video I am showing my auto-land system, along with the repeatability of my circle holds. I'm using augmented reality tricks to draw the past flight path in the video. If you skip to the end after the 3rd landing, I point the camera up at the sky and you can see my circle hold and the 3rd landing approach: https://www.youtube.com/watch?v=1fgVt5OetlI
Curt,
Actually the new uboot config-pin method is pretty close to PINS in the Arduino IDE.
Everything is reference to the Cape Universal that expose an standard gpio mapping on the BeagleBones.
Here is the map for the PocketBeagle:
Just like an Arduino or a Tennsy, each gpio as a default and optionnal functions that you specify interactively using config-pin utility from User Space or at laucnch using a cfg file.
You can take a look at the PocketPilot config file here:
https://github.com/PocketPilot/PocketPilot/blob/master/config/pocke...
EASY !!!!
As for the PRU, its so deep within the SOC that it is still mainly developped in assembler. Just like with FPGA, its hard to make a simple IDE because it is so intimately related to hardware, that any type of abstraction layer make it suboptimal.
the pru is not linux.
ist just a co-processor for the sitara.
offloading interrupts from the linux kernel is actually a good thing.
we will see where the road ends.
but at least you have to show a video when your work is getting up in the air ;-)
I'm not complaining about the great work folks have done to develop the beaglebone architecture, but I wish they had found a way to allow setting up and programming the PRU's with "simple" arduino style tools. The complexity of PRU's, the devel tools, device tree, etc. just really is an impediment for me. If code robustness and understandability is a dimension on the decision matrix, then simpler boards (like teensy or atmel) that can be programmed with arduino tools become more attractive. You give up board real estate to add another processor to handle all the sensors and PWM outputs, but that's about it. Everything else becomes way easier and maybe even comprehensible for a more average DIY'er.
I don't know if I ever make any headway on my goals to find simpler ways to do things, but I do try. The more experience I gain, the more important I feel it is to seek simplicity. My on-board flight code (software stack?) is heavily invested in python running in the main loop. The primary purpose is to shave complexity out of the system and make the code easier to read and work with. This is another reason my system needs a beaglebone or pi type processor at the heart of it.
I really shouldn't complain about complexity because we all do it and it's a natural way humans build things. We add features, we expand the infrastructure to include the new features, we build abstraction layers to hide differences in underlying hardware or software libs. But over and over again I notice that highly elaborate and polished systems are barriers for new people to enter the field and begin experimenting with the technology themselves. So my reaction to all that is to independently develop my own overly complex system ... but at least it's simple in my own mind. :-)
robert nelson is very nice.
did need his help as well to build an embedded linux system.
-
1
-
2
of 2 Next