Skip navigation

BeagleBoard

5 Posts authored by: stanto

Vote for us here!

 

So we took this:

 

Foooosbaaall!

 

And ended up with this:

 

One Tired Paul

 

With Paul looking a bit perplexed at controlling the arms with the BeagleBone Black, the tracking actually works!

 

 

The above video is the OpenCV code tracking the direction of the ball and predicting where it will go so that the motors controlling the arms can react.

 

 

The above video shows the arms moving in reaction to the location of the ball; it acknowledges the location of the ball and tries to identify which player is best to 'chase' it, so that's why it seems a bit erratic at times.

 

It took a few weeks tracing through the technical reference manuals for the PRU along with misinformation on the internet to understand the pinmux and produce a table which actually made sense. Along with actually being able to share a document properly via Google Docs, hopefully this is now published and the file is available : PRU PinMUX Tables for reference.

 

This helped Paul along to do the code; which is on github: Paul's Python binding for PRUSS code for loading the PRU assembly and Paul's BeagleBone Football Code (PRU/Python/OpenCV) for ball tracking (OpenCV) and motor control.

 

The motor control was effectively working as a shield with a custom pinmux table hacked together (we didn't bother using the dtc -@ to have a proper shield configuration and just hacked apart the default dtc because that worked) so here's the Circuit Design for Motor Control where the BeagleBone Black plugged into, which may not have the values stated at present along with the 12-20v Charge Pump for part of the Motor Control. The Playstation Eye (not Eyetoy) was used as the camera for the ball tracking.

 

Beautiful BeagleBone Motor Shield!

 

On the left, hiding underneath is the BeagleBone Black, then connecting to the motor driver circuitry just for ease of use/soldering, which's then connected to the table for the motor movement.

 

There's also a plan for the goal scoring to be tracked by the BeagleBone Black, we installed infra-red sensors into the goals and proto-typed it with a Minimus32 modified with an Arduino bootloader for ease of use; this was going to be passed off onto the PRU but I didn't have (enough) time.

 

Pictures:

Imgur Album

Angus's Flickr

 

Previous blog posts:

 

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/12/beaglebone-black--the-2013-hackerspace-challenge

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/18/hackerspace-challenge--leeds-week-1-and-a-bit

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/21/hackerspace-challenge--leeds-week-2

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/25/hackerspace-challenge--leeds-week-2-and-a-bit

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/30/hackerspace-challenge--leeds-week-3

 

Edit for More Information:

 

I had glossed over a lot of the detail above, but quite a bit of work went into doing this project, mainly because we weren't 100% clued up on how to use the BeagleBone Black best.

 

So for this build we didn't use the default Angstrum (sp?) linux on the BeagleBone but went with a distro we were familiar with, Debian. This was mainly because we intended on using SimpleCV as opposed to OpenCV because we thought it was a package that had been used before and were familiar with. Turns out it was actually OpenCV we'd used but we decided to stick with Debian anyway.

 

The custom build of Debian which was modified for the ARM processor didn't have an up to date device tree compiler (PinMUX file creator effectively,  dts/dtc/etc) until a few weeks into the project, so we didn't focus on using the proper method for modifying the PinMUX settings and just looked at disabling the shields that are created by default. This's mainly for the HDMI, etc.

 

This tied in with finding out how the PRU actually worked; there was a lot of good examples on element14 and Hipster Circuits about how to interact with it but many were confused about how exactly to set the pins as input or output and not many good examples for the actual assembly code for using the PRU. After reading through the technical manuals for the chip on the BeagleBone Black, which mainly was the original version 'c' of the main ARM chips documentation we found the assembly commands and discovered about the registers, such that r30 is mainly hard wired/coded as output only and r31 as input. However these still had to be reflected in the PinMUX so the correct hex values had to be put in place, again discovered by further reading and hopefully the google doc I created will clear things up for people.

 

Though we've now learnt that you can pass kernel parameters to disable the shields, we hadn't found this information at the time and so rebuilt the kernel to have them all disabled by default. Paul Brook also found that there was a limitation in using OpenCV with an external USB Webcam, a problem I think with handling images from the Webcam, that could potentially be fixed in the kernel.

 

The cogs and braces for holding the poles and the motors to interface with them were laser cut at the Hackspace, this's a laser cutter that's on loan from NottingHack. Other parts were either sourced from our current stores or from our own pocket when visiting the Farnell trade counter and gleefully heckling the staff with some polite banter. Jon Stockill put the majority of it together and wired it up, along with the wood cutting for the desk and attachment to the table itself.

 

For the motor control the mechanism utilised endstops so that it didn't try to ram the table repeatedly or shoot off, we had to create a driver board for the motors because the nature of them and with them being 12v required a bit of adaptation to use them effectively. Basically this is an area I'm not entirely familiar with as Paul and Jon handled it so they can answer it better. We had devices attached to them so we could check how far they had moved/their location because we wanted the BeagleBone to be able to adjust the 'person' on the rod to where the ball was, etc.

 

With the ball tracking we discovered that it was best using two white LED strips above the table to help to illuminate it, while we 'blacked out' any unwanted white marks on the table and used an orange ball for high(er) contrast.

 

There really is a lot of code that went into this; so make sure to visit the github links above and check them out!

So after breaking a BeagleBone Black by putting 5v onto the breakout pin on the P8 side... we were supplied with a new one! (thanks!).

 

This meant that I could go back to coding for the scoring system. After working out the pinmux, from various confusing (inaccurate) sources and cross-referencing with the technical reference manual(s), for the mode and setting the pin for input,  I had something which, when the infra-red beam is broken, turns a green LED on. I've created a nice spreadsheet which has the values in, which I'll post up later. Probably to Google Docs.

 

Ball Sensor

 

The transmitter and receiver are a little difficult to see on there (so, Drew, this is my setup!) and we're not using any capes or such, just plain breadboard and wires. Funnily I didn't find any examples of actually using the PRU to receive data on the pins, just output data on them. The simplest way to handle it, has been just to check if a bit has been set on that pin and then behave accordingly.

 

We also suspect that the Video4Linux drivers were playing havoc, preventing us from capturing high resolution video to do the ball tracking on the BeagleBone Black. Currently it's pretty low but seems to be sufficient for our image analysis to work, so that we have got nice direction prediction.

 

 

OpenCV table football ball tracking using a BeagleBone Black from Jon Stockill on Vimeo.

 

 

P.S. We found a use for our catalogue...

 

Farnell supports us!

This week I intended on blogging about working and programming for the PRU in assembly and working with the GPIO.

 

Until I bricked the Beaglebone Black we were given.

 

Usually when you brick a device you can get it back up. Typically, it is the instructions/firmware on the flash chip that have corrupted or it's the operating system you're running on the board.

 

However, when you're wiring up the breakout pins (P8 / P9) and you accidently cross-wire the 5 volt line through a button to an input pin socket, or you accidently short the pin out across ground and such.

 

That's when you kill it. The Power LED flashes briefly and nothing more happens.

 

So yes, I killed the challenge BeagleBone Black that we were donated.

 

Sorry. Can we have another pretty please?

 

Let this be a lesson to everyone else..

 

Oops.

We were not sure whom had time to work on the challenge, the majority of the members have full time jobs and other obligations, so evenings on weekdays and some weekends are often the best bet.

 

Paul Brook (pbrook) decided to head the challenge project, directing three other interested members; myself (Christopher Stanton / Stanto), Jon Stockill (nav) and Angus (ajtag).

 

We really needed a way to control the arms of the foosball table, and it was decided between PBrook and Nav that the best way to do this may be with the BeagleBone Black (BBB) controlling a set of servos. These would help to drive a rack and pinion type of system, which we have constructed by using the 40W laser cutter that we are renting from ChickenGrylls at NottingHack. It produces something that looks like this:

 

Laser Cut Rack and Pinion
Laser Cut Rack and Pinion

 

It's probably difficult to imagine what is going to be done with it, because there will also be modified tubing to grab the arms/rods to rotate the foosballers.

 

This isn't the only development that has been progressing, we need a way to be able to track the ball and this has been done in many different ways already with other systems. The most common way is to use a camera to watch the play field and then perform operations based upon it.

 

Now since the BBB is going to be using linux, then PBrook and AJtag have been looking at using OpenCV/SimpleCV interfaced with a camera to help track the balls movement and feed it into the BBB. The version of Linux that HackSpace members are most familiar with is Debian, while the BBB comes with Angstrum there is a Debian build out there.

 

So I decided to look at using Debian on the BBB and see if I can make an LED blink with the PRU/PRUSS/PRU-ICSS. Examples and guides on this are confusing for an amateur such as myself, working with the PRU requires loading compiled assembly code onto the chip but to work with the pin headers/breakout pins on the BBB needs the GPIO pins to be pinmux'd using the Device Tree Compiler (dtc) (as far as I could tell) and then you can play with the memory addresses appropriate to the PRU for input/output.

 

Only this has been made a little tricky, the PRU is not officially supported to the community and has been removed from the latest technical reference manual for the BBB. However, it does still exist within version C of the technical reference manual if you can find it. However, this is mainly mute as a lot (but not all) of the content has been decanted into a github repo'. Most of these can be found by searching for BBB PRU (though not those exact terms and there's an example of working with it on this site).

 

Now I mentioned working with the PRU in Debian, I discovered that at the time I grabbed the Debian build, its dtc wasn't modified, I suspect the kernel was not fully altered either, which makes interfacing with the breakout pins/sockets difficult/impossible. However, I did manage to flash the onboard LEDs which was a mini-victory for myself. As a distraction I found the patches, packages(?) and guide necessary to patch in the BBB modifications to Debian for ARM.

 

Hopefully soon there will be some rods that are moved and rotated by servos and a camera tracking a ball, on top of this, we decided that there should be a way of keeping score...

Some have think tanks or mind maps, we just threw around ideas until something stuck over the course of a few days/weeks. Of course for a while we were introducing members of the space to what the BeagleBone Black actually was:

 

"Well, what can it do?"

     "It's like a RasPi, mixed with a PiFace/Arduino, but faster, and done properly"

"Okay, but what shall we do with it?"

     "I dunno."

 

After everyone that turned up regularly enough was introduced to the BeagleBone and the Challenge, some ideas started to appear.

 

There were two main ideas for contension, one was a fire-fighting robot using a camera of some form with infra-red for light/flame detection and controlling a water gun to shoot at it, on wheels. Then the idea turned to having an automated Air Hockey table, but I think that was considered to be a bit tricky due to the way in which the player(s) piece is able to move around quite freely/some other reason. The alternative was a foosball table that was controlled by the BeagleBone Black, with the ball tracked by a camera.

 

We're English, foosball won, especially when a member bought one from eBay for £50. For an all-wooden table it's in pretty good condition.

 

Foosball Table

 

The table's missing a few handles and the playing field bows upwards a bit in the middle, but with some work it'll be fine. We were already thinking up how the BeagleBone can play its part in controlling arm movement and detecting goals that could be scored by either team, of course, this raised even more questions.