I wasn’t going to post this because frankly I’m sick and tired of having projects fall apart and die around me after I tell the world that they’re going to happen. I tend to be an open person, I don’t like secrets, nor do I see the reason the world is so secretively, but when it comes to projects this nasty little cycle seems to happen.
I get all excited about something and go off and do like a fraction of the work required to complete the project, then life catches up with me, schools starts or I realize I don’t have what I need in terms of knowledge, tools or just money / time to complete my goal. So the project gets shelved in my head.
Well I’m running out of shelf space (flat surfaces are a premium in my life both physically and mentally), so I think it’s time to actually get one of these ideas alone a little further.
A while back NAR posted this:
http://polynomic3d.com/user/smith/NAR/NARPE_forum.png
The team genuinely wants a better on-robot co-processor, because like all good teams we aspire to write better code. But what we really want is more capability. As one of the prominent programming people on NAR, last year I wrote thousands of lines of code for our robot. This code tried to structure the robot in a way that allowed the code to understand the robot’s makeup. The idea was to write one set of code that could operate (at least drive) any robot that the team could build within reason.
The problem for me was the lack of any OOP support on the Cortex and the difficulty of debugging with a very limited console. As a programmer I’ve spent most of my life writing OOP code, and while I favor a component based structure for distributing logic, OOP is the best we have at the moment. Yet we here at Vex don’t have a means to write such code on the Cortex and even if we did the lack of RAM on the Cortex would limit what we could do.
When the Raspberry Pi came out, suddenly putting a full Linux box on a mobile platform didn’t seem as crazy as it used to. Now we could have a whole CPU on the robot, with gigabytes of ROM and hundreds of megabytes of RAM, USB, Ethernet, WiFi and some GPIO to boot.
Problem is, the rules of VEX U forbid us from removing the Cortex from the equation. The motors and VEXnet must go through the Cortex, so it became necessary to bridge the Cortex and Pi.
This is not a trivial task. And as time went by, I began to realize that the Pi has some shortcomings. As such, I chose a different platform, namely the BeagleBone Black. The biggest reason was that fact that the BBB uses DDR3 RAM which is much faster than the SDRAM on the Pi, and the fact that the BBB has way more I/O.
http://polynomic3d.com/user/smith/B4C/Cover.png
So I’ve made some progress on this already, which I’ll share here. But I’ll also use this thread as a build / programming log so that others can pitch in, or learn to do what we’re doing.
SO let’s get started, first thing is the Cortex’s UART.
http://polynomic3d.com/user/smith/B4C/UART-Close-Up.png
I chose to use the UART because it’s a pretty easy protocol, and the Cortex has two UART ports, leaving both an I2C and UART port left over. UART is build for two-way communication between exactly two devices.
If you want to learn more about UART, see this Sparkfun guide. Also be sure to read the Cortex pinout to get everything plugged in correctly.
THE FOLLOWING SECTION WAS NOT ACTUALLY NECESSARY!
I mistakenly believed that the Cortex used 5v logic level and needed to be shifted to 3.3v, the Cortex does in fact use 3.3v logic level and does not need to be level shifted.
That being said, some Arduino’s DO use 5v logic level and therefore need to be shifted, so I’ve chosen to leave this section here.
The BBB can be damaged by this higher voltage, luckily Sparkfun sells a small level converter board.
http://polynomic3d.com/user/smith/B4C/Sparkfun-Level-Shifter.png
I used right angle headers because I wanted to create something closer to a wire, you could alternatively use straight headers and set this up on a breadboard if you wanted. Which may be what I do with my second level shifter.
END OF NOT ACTUALLY NECESSARY SECTION!
Thanks James for being James
Now comes the task of actually making these devices talk. Unfortunately I couldn’t get PROS to output anything over UART. I’ve asked them for help, so hopefully the issue can be figured out but for now the following ROBOTC program serves as a decent test:
#pragma config(UART_Usage, UART1, uartUserControl, baudRate9600, IOPins, None, None)
#pragma config(UART_Usage, UART2, uartUserControl, baudRate9600, IOPins, None, None)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
task main() {
while(true) {
sendChar(uartOne, 'A');
delay(250);
sendChar(uartOne, 'B');
delay(250);
sendChar(uartOne, 'C');
delay(250);
sendChar(uartOne, 'D');
delay(250);
sendChar(uartOne, 'E');
delay(250);
sendChar(uartOne, '\n');
delay(250);
}
}All it does is write “ABCDE” over and over. But that’s enough to test the communication link.
Notice the “baudRate9600” up in the config, 9600 is the default baud rate for the BeagleBone Black. I hope to up this to 115200 later.
NOTE: I’ve flashed my BBB with the Debian image, because Debian rocks. You can find the image here and the flashing guide here.
Be sure to read the following (at the bottom):
Don’t be an idiot like me and NOT read this and leave the microSD card in, and wonder why the BBB shuts down every 15 minutes, incurring unnecessary writes to the eMMC the whole time.
On the BBB, you have to enable the UART ports. This isn’t all that simple. This guide explains the device tree and gives some good examples.
The basic process looks something like this:
mkdir /mnt/boot
mount /dev/mmcblk0p1 /mnt/boot
nano /mnt/boot/uEnv.txtThen you add these lines:
# UART 1
cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5And reboot, this tells the BBB to enable all the UARTs.
To verify that the UARTs are enabled:
cd /sys/devices/bone_capemgr.*
cat slotsYou should get something like this:
root@beagle:/sys/devices/bone_capemgr.9# cat slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2
9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART5After that all we have to do is:
cat /dev/ttyO4
http://polynomic3d.com/user/smith/B4C/First-Contect.JPG
And we now have an open channel between the BeagleBone Black and the Cortex.
Right now, it’s kind of like a marriage, the Cortex does all the talking, repeating itself all the time and the BBB just listens. The next step will be to establish a more complicated communications protocol between the two devices.
I’ll probably use Jame’s P3, after I actually figure out how it works beyond the basics or I may derive my own protocol based off of it.
Once we have a good communication protocol, we’ll begin to leverage that WiFi adapter and the apache2 server running on the BBB.
In the short run, we’ll use the BBB to do some major real-time data logging.
In the long run, we’ll (hopefully) begin to send RPC calls to the Cortex, basically we’re going to tell it what to do.
-Cody
