Archive for the ‘Robot’ Category

June 1st, 2013 @ 13:20

Back in 2011, we did not build our first 3D printer just for the sole purpose of doing it, we also did it (and probably mostly) to be able to build other things, and more specifically robot parts. Taking part to the French Robotics Cup had been a project some of us had even before creating the club, but we were lacking momentum and tools. One of the main issues is that ENS is not an engineering school, but rather a pure theoretical science school, which left us with no prior experience and almost no access to proper hardware tools (the only ones we could have access to belonged to Physics labs and were securely locked).

Thus, being able to create our own parts and build them from the bottom up (as opposed to machining from top down) was a huge thing. With our custom-designed plastic parts and a few pieces of wood, we have been able to build very light yet sturdy robots (as opposed to the huge all-metal ones most engineering schools teams bring to the Cup).

Webcam holder used on our 2011 robot

Webcam holder used on our 2011 robot

We used stepper motors for propulsion. While this might sound like a weird choice, using steppers let us not spend a shitton of money (which we did not have anyway) on odometry and buy some servomotors and electronics instead. Indeed, as a stepper is controlled by sending steps which increment or decrement the motor axis rotation angle, we could move with a very decent accuracy by just trusting that our system worked, which implied calibrating things well so that tires did not skid and that we were not getting bumped by other robots. Sadly, while the second part was mostly verified in 2011 and 2012, it seems that in 2013 robots were getting more and more agressive, and we might need to add some form of odometry for future years.

We also tried to stay KISS (Keep It Simple, Stupid) for the actions and strategies. For instance in 2011, after spending a long while trying to write a super awesome AI that would user computer vision to understand the game board and act upon the other robot actions, we moved onto first following a scripted plan with hardcoded positions and actions and then running a simple IA which would try to detect game items and correctly act on them. Using this very simple technique scored us the 24th rank, which was an awesome achievement for a team with no prior experience and no engineering support (and I’m not just boasting there, that was other teams told us :)).

In 2012, the global theme was Pirates, and the main goal was to grab CDs (which pictured coins) and wooden blocks (picturing gold ingots) and bring them into a predefined area. A bunch of ingots and CDs were placed on towers called “totems”:

"Totems" full of monies !!1

“Totems” full of monies !!1

We decided that our main goal would be to simply get everything from one of these totems, not by using some fancy robotic arm, but simply by making a hollow robot which could go over the totem, with appropriately cut doors to capture the game items. I guess we were the only team to use this fun strategy, which paid quite well (we ranked 56 even though 3 or the 5 games went very bad because of hardware issues). Here’s a video of the robot beautifully performing its script:
[vimeo width=”600″ height=”400″][/vimeo]

To conclude, the main take home message of this post is: KISS. Don’t shoot way too high before having a simple prototype that works. Many teams coming to the French Robotics Cup bring heavy and super complicated robots with dozen of sensors, but this complexity kills everything and they can’t correctly move or perform their actions, because the robot is too heavy, because writing software is super painful when you have to deal with dozens of inputs and because debugging (both software and hardware) is close to impossible. Don’t try to be too smart too. Writing an efficient AI is totally non trivial, especially when you have to rely on noisy signals (such as computer vision and whatever technique you might use to locate the other robots). A simple hardcoded plan might work just as well and be 10 times easier and shorter to develop. So yeah, KISS.

February 16th, 2011 @ 12:18

Yesterday we at hackEns received our BeagleBoard-xM, ordered from DigiKey during FOSDEM. Let’s first note for French people interested in getting such boards from DigiKey that we had to pay 39.15€ of VAT and similar fees to the UPS guy upon delivery. Now let’s move onto some context and tips about getting it to run.

The BeagleBoard-xM is a 8.25×8.25 cm board, powered by an ARM Cortex A8 CPU and relying on 512MB of RAM. It features, among other things, a microSD slot, a serial port, an ethernet port, an HDMI output, a S-Video port, 4 USB-A ports, 1 miniUSB OTG port and stereo input/output. There is basically all you need to build a simple desktop computer. Just plug in an USB keyboard, an USB mouse, an RJ-45 wire and your HDMI wire and boot it. Well, almost.

Before being able to run anything useful, you have to first power the board and then build a microSD card with an useful distribution on it.

First tip : connect your BeagleBoard-xM to your computer through the serial port. Buy an usb-to-serial adapter if needed, buy the serial wire if needed, but do not try to get things working blindly. You definitely won’t be able to debug any bootloader problem without a working serial link, and you’ll most likely waste much more time than you’d need to go to your local hardware shop and buy the required bits.

Now, let’s insert the provided microSD card into the slot, and move on.

TL;DR here : don’t try to power your BeagleBoard using USB OTG, use a regulated 5V DC power supply instead
Powering the board might seem easy, given that there is an USB OTG slot through which you can definitely feed power to the board to get it running (LEDs blinking), but there are two caveats. The first issue is that a single USB host port cannot supply enough power to the board to get it running smoothly. The most obvious symptom of this problem is that the board simply won’t boot (the bootloader will load the ramdisk and uncompress the kernel and hang there, or it might even start the bootsequence but will fail at some point with no obvious reason, or it might even reach the second issue, but even without the second issue it won’t be able to finish the bootsequence). As advised on some forums, you can use a Y-shaped USB wire like those you can get for 2.5″ USB external hard drives. This will enable you to give enough power to feed the BeagleBoard.
Yet, you will still encounter the second problem, which is that the kernel will panic at some point during the bootsequence, exhibiting a problem somewhere inside a musb_interrupt call. This seems to be because of a bug in the OTG module of the kernel used on the test system, which makes it impossible to boot with something plugged into the USB OTG port, so you’ll have to power your BeagleBoard using an external 5V power supply. We used a 2 amp regulated DC power supply for that purpose. Since it could only deliver 4.5V and 6V outputs, we had to use a 5V/1amp voltage regulator.

We were then able to boot on the test system, got a nice prompted, logged on, assessed the fact that we had a basic system, ran the mandatory testled tool, and halted to move on to the second part : setting up a complete system.

This is where the fun really begins, because most howtos are about the original BeagleBoard (non -xM), especially on the eLinux wiki, and that can be quite confusing. We’ll use Ångström distribution, which is a simple GNU/Linux distro targetted at embedded hardware, such as the BeagleBoard. This choice was made based on the fact that the Debian ARM packages are compiled for a more generic kind of ARM CPUs, on the fact that the current Ubuntu poorly performs on BeagleBoard-xM (it does not fully support the board’s CPU and downclocks it badly), and that the other competitors (Android, Maemo/Mer, Meego) did not look that great.

Basically, all you have to do to setup the microSD card is to follow the excellent instructions from Trey Weaver, with a few extra tips.

First, to be on the safe side, you can get all the files you need from the Ångström BeagleBoard demo fileserver : mkcard.txt, MLO, u-boot.bin, uImage, modules.tgz and the Angstrom-Beagleboard….tar.bz2 rootfs. You do not need to go through Narcissus.

Next, make SURE that the first file you copy to the boot filesystem is MLO, otherwise it won’t be able to boot (the bootloader has to be the very first bytes of the filesystem).

Next, when looking at other howtos, ignore all the bits about pressing the USER button, or about halting the autoboot to set the bootloader options : you do not need either. Indeed, the BeagleBoard-xM has no NAND flash to store the bootloader options, so doing the saveenv command of the bootloader will just make it hang. Instead, if you want to specify your own bootloader options, you have to produce a boot.scr file. To do so, install the mkimage tool (it’s packaged in debian and ubuntu as uboot-mkimage, it originally comes from OpenWRT bootloader u-boot which we use here). Then create a file (let’s call it boot_cmd for instance) containing the boot commands you want ; a basic command file is the following :
setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait'
mmc init
fatload mmc 0 0x80300000 uImage
bootm 0x80300000
Build the boot.scr file from it :
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Beagleboard-xM boot script" -d boot_cmd boot.scr
Now all you have to do is to copy boot.scr to the boot partition (i.e. alongside the MLO, u-boot.bin & uImage files) and reset your BeagleBoard.
This can be useful to specify the video mode to use, for instance I use the following bootargs to get correct rendering on my LCD :
setenv bootargs 'console=ttyS2,115200n8 omapfb.mode=dvi:1360x768MR-16@60 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait'

You should now be able to put your microSD into your BeagleBoard and get it running fully (I have a few initial hiccups with the microSD not being recognized or so at this point, I just moved it back and forth to my laptop and it worked beautifully since then). You should get a working GNOME environment (after a nice gdm prompt).

Let’s note that Ångström uses opkg package manager, which works in a pretty straightforward way, with install/remove/update/upgrade commands. Note that you have to use the list command to search packages, i.e. you need to do opkg list opencv to look for opencv-related packages, and not opkg search opencv as you would do with apt.

I was very pleased to see that opencv was installed by default (I guess, or at least I did not have to install it after performing an initial opkg upgrade), that my Logitech webcam was recognized from scratch and that I could use mplayer tv:// without any more tinkering to use it.
The current image does not come with a build chain, so you have to install the required bits to build your own apps. I believe all you need is to install the task-native-sdk package to get everything (gcc, g++, make, binutils…) setup. I guess I only had to install git, vim,pkgconfig and cmake by hand to feel home once that was done.

I am now investigating some issues related to building stuff using OpenCV, similar to those described here on Stack Overflow. I’ll keep you updated.