Ubuntu 11 (Natty) on Beagleboard

I have no idea what messed up the microSD that had Ubuntu 10.10.  I loaded up a new SD with the latest 11.04 image (zcat and dd) and that went pretty smoothly.  Meanwhile, I decided to put Angstrom back on that corrupted DS card (worse case it wouldn’t work) withmy development PC (used Linux Mint presently).  Worked fine, but went blank after firing up gdm.  I got the image from the Narcissus site and custom made it with gnome and other extras.  I probably should have stuck with the console version.  Fired up good when I redid it with just the console bare bones version.  Then I made the mistake of adding the gdm package.  I wasn’t sure at the time if that was the issue.  It was.  I can’t remember if the SED card that came with it ever got to the gnome desktop.  I’m betting it has something to do with fact it is using HDMI, but not that concerned as I have Ubuntu working like a champ.

I was hoping with version 11 that the clock speed issue with the XM board would be solved.  Apparently the new kernel also chokes with the 1GHz beagleboard.  I had to go into the boot.scr in the /boot folder to change the boot parameters from 1000 to 800 for the CPU.  After doing that the speed came back (it was appalling before changing as it literally took 5 or 6 seconds for the prompt to come up after opening the terminal.  Before I made the boot script change, the USB cam was hardly working – it was extra grainy and barely moved fast enough to have a frame rate.  Focus was effected too.  After the fix, the cam worked as it should.

One thing that must be done if you are trying to interface with a serial port with Ubuntu 11 – change the parameters for the ftdi device you use.   For some reason, the probe of the the USB serial device (in this case an Arduino Nano) came out wrong.  I could get an arduino sketch uploaded once after choosing /dev/ttyusb0, but then it stopped working.  It repeatedly said there was no such device.  Well there wasn’t – nothing resembling that in /dev folder.  What had to be done is a modprobe to the device with proper hex numbers.  If you do an ‘lusb’, you will get all your devices listed on the USB bus.  You need to pay attention to the vender ID and product ID.  Most likely the vendor ID is correct.  The product ID for me was off.  I had a 6001 for my product ID and I thing dmesg reported a different number.  Regardless, it is a good idea to run modprobe again with correct numbers.  Mine was:

sudo modprobe ftdi_sio vendor=0x0403 product=0x6001

After that, I could communicate with arduino and there was a ttyUSB0 entry in the /dev folder.  Now I just have to work on my flowchart and coding before I starting piecing things together.

Posted under Operating Systems,Robotics

Back to Sensing

Finally had some time to tinker again.  This time working on the distance sensing function of eventual autonomic robot.  I turned to a good ol’ Arduino for the physical IO.  I got a Nano, and this is a sweet little microprocessor.  All the functions of an Uno crammed into a little DIP from factor.  For testing things out it is stellar.  Just plug into USB port of PC and run your IDE of choice and your off.  I decided on a Seeed Studio ultrasonic rangefinder.  This is pretty much the same as a Parrallax Ping sensor, or the SRF-05 rangefinders.  This Seed studio unit has 1cm resolution and pretty inexpensive.

My goal is to get the forward focal point more resolution (like a telescopic lens vs. a fisheye).  Ultimately I could and should use a laser rangefinder, but this approach is quick & dirty and ripe for tinkering.  My thinking was that perhaps I could narrow the dispersion of the ultrasound at least on the transmitting side.  I knew that because the sensors are separated by about an inch, narrowing the input or receiving side would reduce the amount of echo reception perhaps too much and give haphazard results.  Ultrasonic waves travel in a more focused pattern compared to audible waves in the first place.  So by creating a smaller source of waves, I believe the “beam” will be narrower.  My thought was to cover up the exposed area of the transmitting speaker  – they are little speakers in there (like whizzer cones in old automobile full-range speakers).

Nano-focused SONAR

Upon testing, I found that the stream of data (microsecond time) was pretty consistent with stray numbers that were off the chart determined to be the reflected ultrasound inside the chamber getting out through the hole.  By filtering that out in the Arduino sketch, I could get reasonable results.

SONAR Output

Since the above output was centimeters, I think the resolution is decent enough.  Before the lens mask and filtering, I had all kinds of values in a pretty wide range.  My guess it was from the transducer dispersal pattern catching an object behind or to the side of what I thought was in front of the rangefinder.  I will modify the code to test output in a graph to test the narrowness of the beam on real world objects.  I will either grab the values and put in Excel or write some code using Processing  (www.processing.org) to show the graph realtime.

Speaking of Processing – I love that software suite, platform, IDE or what ever you want to call it.  It uses the same format and syntax as Arduino sketches right down to the graphic interface.  So if you know “C like” sketches, using Processing will come to you quickly.  I found this awesome sketch by Lucky Larry in the UK who wrote a sketch for his pan-tilt rig using a rangefinder.  He wrote a graphical radar-like realtime screen output from the rangefinder and it is pretty slick.  I modified it a bit for my purposes, but kudos to him for the original sketch.

Graphic SONAR output (Processing)

So that is the screen you see while Processing is running the sketch.  Basically, you run your rangefinder sketch on the Arduino – make sure the serial output screen is not open.  Then you run the Processing sketch which reads the serial stream.  I modified the code to show “ping” reflections as dots instead of polygon areas.  I also changed it sweep only 4 degrees on either side of 90 degrees.  I can see a lot of potential with Processing and the Arduino family of processor boards for physical computing feedback.

Posted under Robotics,Sensors

Beagleboard + Ubuntu 10.10…Sweet!

Things are just falling into place with this Beagleboard.  The Ubuntu distro, although slow on installing packages is pretty damn robust.  I have installed a bunch of packages without a hiccup.  X11VNC works without any issues, and can access with ultraVNC without much screen lag.  My UVC webcam (which can be seen in motion in earlier posts) works perfectly due to great kernel library and UVC driver that was already in distro.  I added extras like “gUVCView“, which is an awesome webcam app.  I have installed “motion” and “UVCCapture” as well.  The goal is getting OpenCV on here and getting some video recognition algorithms going.  From what I have seen with Beagleboard, I have no worries.  The video pipeline on this board is pretty spectacular.  There is even a camera header installed on board for those ‘board cams’ which have 15-18 wires connecting them.  I will be boning up on my Python and then OpenCV will be a big chunk of my robot ‘to do’ list.

You can see below the beagleboard and the future enclosure body (torso) with the camera head aimed at the keyboard.  It actually defaults to 640×480 and I reduced the size in the .guvcviewrc file (found in user directory) to 320×200. For my testing and vision processing experiments, this quarter-vga format will be fine to cut my teeth on.

Ubuntu on Beagleboard-XM

Posted under Operating Systems,Robotics

New Tangent – Vortex86SX is History!

OK.  Why spend so much time on a frankly, underpowered system board.  Chalk it up to learning experience I guess.  That Vortex86 may have been the cat’s pajamas (pulled that from nowhere) about 5-10 years ago with 300Mhz, but the lack of FPU or math coprocessor cripples it nowadays.  Less operating systems will use it, and the workarounds for Linux and extra compiling are not worth it for a base system to hang other applications and projects on.  Now there are still many SOC and processor evaluation boards out there that do not have FPU capability, but the processing power (speed, memory) and community support make up for that.  Case in point: Beagleboard

I picked up a revision B XM version of one of these little nuggets and I am quite impressed.  What kept me from getting one years ago was the lack of VGA output.  All the other boards I tried at least had that.  This has s-video (usually crappy at best) and HDMI out.  I got back one of my old monitors which has a DVI input, and then I made the plunge for the Beagleboard.  Glad I waited, as the XM unit has a 1Ghz processor (TI Omap 37XX) and 512M RAM.  Pretty awesome for a board that is 3 inches by 3 inches (smaller than PC104 form factor by a smidge).  Here’s the bonus:  it comes with a 4-port USB Host connector (a hub, technically) soldered to the board, as well as a RJ-45 ethernet connector (smsc95XX), and the serial port is now soldered on as well (DB-9).  It comes with a 4G microSD card which is always recognized as an MMCblk0 device.  Many headers are also part of the board now, so no crazy tight-space soldering if you want to attach a daughtercard!


These ports and connectors make it very easy to work with.  Pretty much plug-and-go!  Important to get a 5V adapter, as this board is flackey if relying on power from USB OTG port.  Still, this 5V supply can power many devices on the onboard USB ports like (in image above) a mouse, keyboard, and 2G thumb drive!  And it still consumes less than 2 watts of juice.  I see a great future with this little board.


The SD card that came with it had a demo image for testing right on it.  This shows that it can boot up.  It is not, however, setup for a working system.  It comes with a recent Angstrom build which worked completely in ramdisk.  The only partition formatted was the 80M bootable fat.  The rest of the card was unpartitioned.  I copied the the contents of fat partition to a safe folder on Vista machine fat32 hard drive (USB) and proceeded to boot up one of my Linux live distros – can’t remember which one, but it was probably Puppy 5.1 or Debian Lenny.  Then I setup the Beagle SD card with Gparted.  I made a bootable fat at 90M, EXT3 at about 3G, and an EXT2 storage for the rest.  I suppose I could have put back the saved MLO and u-boot.bin, but I ended up going to a Texas Instruments site and used the MLO and u-boot.bin from their Android Froyo site.  Yes, I installed Froyo, and it worked, but it was pretty lame on a machine with no touchscreen and a mouse/keyboard.  If I got a touchpanel daughtercard, then perhaps.  Anyway, the packages and layering of the operating system is different (OK for phones, but not so much for a development robot system).  So, I kept the bootloader files and proceeded to test other systems.  I installed Angstrom and it worked great, except the package ‘universe’ was not that large.  i hit brick walls when trying to get things I thought I might need – like luvcview or uvcview.  Sure I could compile them for my kernel, but I was too impatient.  I tried Debian netinstall, but my kernal did not match my rootfs, because there was only one netinstall rootfs on debian ARM site and it was for 2.36.29 kernel, and I had 2.36.34……  You would think it would work (yes it booted and all, but installing modules for devices or adding packages kept spitting out ‘invalid format’ errors).

I ended up with Ubuntu 10.10 (Maverick I guess).  With help of Robert Nelson images, I manually installed the boot images with mkimage in Debian, and the rootfs on the second partition (untarred it).  Anyway, after altering the boot.scr a little and saving with mkimage, the Beagleboard boots right up.  If the serial port is connect to PC with a terminal program running (PuTTY for Windows, picocom for Linux) at 115200-n-8, it displays on both terminal and DVI output (LCD monitor).

Beagleboard DVI

Xserver didnt work after install because the distro image was a ‘minimal’ one – perfect!  I would like to be responsible for my own application bloat anyway.  So I proceeded to install X Windows server (apt-get install xorg) and windows manager – fluxbox (apt-get install fluxbox).

One note:  the ethernet did not work right away, which was really a setup issue.  For some strange reason, the ethernet installed on USB1 instead of USB0 like it always did before.  This might be because I had a thumb drive in the port.  Ethernet is really a USB ethernet.  So using ‘ifconfig’, I set a static ip, and used ‘route add’ to set gateway.  Pinging outside site confirmed working ethernet.  Very next step after that was to update package list (apt-get update), which had to be done before installing anything else like X windows mentioned above.  At last count, on this little board, I had 22,800 files and directories installed (from apt-get feedback).


One mention on performance.  Ubuntu 10.10 is not a speed demon on this board.  Angstrom is much faster.  It is due to a combination of things – sheer file number and system footprint, SD card capability and format, and the fact that the kernel command to restrict CPU speed to 800 from 1000 (this will be fixed in a later update).  But I sacrifice speed for functionality at this point.  Afterall, I was going to be setting up a 300Mhz system before – so this is still like heaven.

Helpful Links:

Posted under Operating Systems,Robotics

Back to Linux

It has been awhile sinced I posted on this.  My wife and I have been travelling and other projects have been sandwiched in between (like a whole diversion into circuit building and green energy, etc.).  Anyway, I am back to hacking processor boards for robot integration. I am blogging about this because it may help others who may have hit stumbling blocks with a certain board for something seemingly simple as getting it to boot a fairly recent Linux kernel.  In the end, and looking back, it might have been easier to use another board afterall!  The board I am referring to is the Vortex86SX.  On paper, it sounds like a packed board, and indeed the DX version is already marketed as a “roboard” for robot building.  But, sometimes the fun is in the challenge and learning experience.  I also picked up the board on EBay for about $70.  It has all kinds of I/O and a regular VGA port and 2 hi-speed USB ports and runs only on 5v.  The problem…….no math coprocessor.  Pretty much cripples it with most OSs.  You can forget WinXP (even embedded version).  Win2K is just too old for getting current drivers.  It looks like Linux is the only way to go here.

It came with X-Linux which works, but the kernel is just old enough so most drivers are not rolled into it.  It seems to have lacked good ceveloper following.  For basic operation and if you want to brew your own drivers, it should be fine.  I wanted a little more main streamso I can get current apps and drivers.  First I started with SliTaz, which works great on my other 386 PC104 board, but it panics because of no FPU.  Then I really wanted Puppy Linux, but recompiling the kernel was tedious and threw all kinds of errors in my multiple attempts, just to get it going with no FPU.  I read another forum where someone had tried for weeks and got it to boot, but then had multiple failures to get a GUI working like X-Windows.  But I found another blog which solved my issues (http://choompon.exteen.com/20100128/howto-compile-debian-for-e-box-2300-sx).

My steps:

  • Downloaded the image (USB flash), which is way faster than recompiling on my own
  • using Puppy Live on my PC (or any other Linux variant)  I dd’ed the img file to a 256M thumb drive
  • using gparted, I set the boot flag of thumb drive
  • tested drive by booting to Linux on PC
  • put that thumb drive and CFlash IDE board (with 512M flash) onto Vortex board
  • booted Vortex board to USB thumb Linux
  • dd’ed partition of thumb to CFlash partition ( sda1 to hda1)
  • rebooted without thumb (Linux debian ‘Lenny’ comes up)

All is good!  I have a working PC104 board with lots of I/O, and the main reason……I plugged in my webcam (seen on previous posts moving with servors), and it recognized it.  It showed the sound portion of cam, which is a good start.  The next major thing I had to do was get the system to be ‘not live’, as the flash drive is essentially emulating a live cd system where the flash drive is like the cd.   I wanted to have apps and settings remain persistent.  This was accomplished by getting a bigger CFlash card (4G) and setting up partitions with gparted.  Partition 1 was 256M Fat32, 1 was 900M Ext3, and rest was Ext2.  I set boot flag to first partition and made it bootable with ‘syslinux’, which I think is way easier than Grub (no hd0’s vs hd1’s to worry about).  Made syslinux.cfg to boot with ‘rw root=/dev/hda2’ which made the second partition function as normal system.  Then I mounted the ‘live’ root system image as a new drive on /media directory, using “-o loop” at end.  Then while logged in as ‘root’, I cp’ed all the directories to the second partition (many are emtpy like /proc).  So now I had a huge user space with standard boot from fat32.

After putting new CFlash drive in board and rebooting, I had Debian system running on a writable partition and ready for app/driver installs.  By the way, the LAN port worked with kernel image, so using apt-get worked great after tweaking source tree and adding a few more like the archived builds from debian.org.  I had to setup network by editing the “interfaces” file – I used “auto eth0 inet dhcp” to get me going, then did network reset.

Posted under Robotics

Main Board Regroup

I am starting to have problems with my underpowered x86 board I had already.  I kind of hit a wall when going further on the integration of cam for vision processing.  Even though the cam is recognized by USB port, the driver stack in Win2K does not handle the cam (I had tested it in a Vista notebook).  Driver on CD needs DirectX 9c – which will not load with this STPC processor (which appears to DirectX as a Cyrix).  I searched everywhere for a Win2K driver on the Web – no go.  If the damn board booted a more robust version of Linux than uLinux (which is bootstrapped on DOS), I would try the generic Linux Webcam drivers found all over the Net.  I tried using a driver for an old Logitec “eyeball” cam I had and ran the setup, only to hit another wall – bit depth of the video.  Since the only driver found with this board is a generic VGA, I only have 16 colors, even though I can get 800×600 out of it.  That was the straw that broke the camels back – Probably a great board for DOS or Win98, but nothing higher.

I have already purchased another PC104 board that will handle WinXP, has all the in-outs I need, as well as standard XP functionality.  I have already created my embedded version using NLite with an XP Pro disc I had before Vista.  Good thing I hang on to these!  I also bid on another board that will handle Debian Linux, so I will have that for possible parallel development.  Although developing in .Net Studio and dropping it into the PC104 board sure will be pretty uncomplicated.

Posted under Robotics

Pan-Tilt and Video Figured Out….

After much trial and error and success with PWM and the neck servos (Hitec), I found I was having problems getting the servos to work together using basic pulse width in the Arduino code. Each servo worked perfectly when singled out, but trying a pan-tilt at the same time caused servos slamming to the ends and losing all coordination. I finally found that downloading the MegaServo library did the trick. It was supposed be included with version 17 of IDE (which I have). Anyway, this library works great! The key is that it will allow all the pins to be used for servos, not just 9 & 10. My Arbotix board stops at 8, so I was out of luck with the default Servo.h library.

I had planned on interfacing a Panasonic CX161 board cam (have one already) to the STPC main board for the vision processing, but that would require a frame-grabber board or a composite vid 2 USB connector. After almost going with that 2nd choice, I remembered I picked up a $12 webcam at Staples around Christmas for goofs – I actually thought I could use it in a project somehow. This choice will cut out the video capture component because it is already built in! I mounted it to the pan-tilt neck assembly and will test interface to the Atlas STPC PC/104 board (with Win2K).


Posted under Robotics,Sensors

Torso Box and Neck

I got the pan/tilt assembly from Servo City on Saturday.  While the unbelievable Packers-Cardinals game was on, I messed with prepping the Styrene box I had for the robot torso.  I drilled the holes and installed the STPC SBC towards the back, and the compact flash and power connector fit (wasn’t sure until I tried).  The nylon standoffs cleared the pins on the back of the board from touching case.  Then I assembled the pan/tilt with my HS-81 servos (less weight than regular servos, but with decent torque) and then cut a rectangular hole in the top of the box for it.  After drilling another hole for the tilt cable to go into the box, I was ready for testing.  Using the Arbotix controller (not yet installed into torso box), I tested the movement with a simple arduino sketch (AVI below).  Now that the  neck is figured out, I will figure out how to get my Panasonic board cam attached with its 5 or 6 interface wires.  I can always choose to use a USB cam and fill one of the STPC USB ports.



Posted under Robotics

Std Servo and Accelerometer Communication

Part of my steps to get the different parts to talk to each other is a basic action/reaction workflow.  With all this tinkering, nothing ever works out of the box!  I soldered header pins onto a 2-axis accelerometer (Sparkfun) and hooked up to my breadboard.  I had two Hitec HS-81 servos for the neck of my robot (for video and sensors), so I wanted to try those first with the Arbotix microcontroller.  Again, nothing works as it should right off the bat.  I created a sketch using the ‘servo.h’ library and the servo did nothing but chatter during sketch upload.  I then found a PWM routine to use with servos online written by Tom Igoe (by the way, I have his book ‘Physical Computing’ – co-authored with Dan O’Sullivan) which used pulse code delay for moving the servo – worked like a charm!  I have already ordered a new 3-axis accelerometer because I don’t know if I got a flaky one, or I hosed it during my soldering.  The X-axis outputs random, crazy numbers even when standing still.  The Y-axis would vary by one digit once every 12-17 outputs even when standing still.  I divided the analogRead value by 10 and that reduced it somewhat, but still happened occasionally.  So for my test, I ignored the X-axis values and simply checked the Y-axis.  When I get my new IMU, it will have pins attached – so I rule out my iffy soldering skills.  Note to self: practice soldering tiny PCBs!  You can see the video below of one axis servo test.

IMU and Servo on Arbotix

Posted under Robotics

Messing with the Microcontroller

Now that I got The STPC working with Win2K and Dot.Net 2.0 installed on it, I started on the other aspect of the project – microcontroller integration.   My plan is to get the PC board [SIC] to do the heavy lifting and the microcontroller to do the nervous system (think sympathetic) stuff, minute-to-minute.  The first step was to get the Arbotix (Trossen Robotics) board communicating.   Once I got a good serial connection going, then the layers for .Net could be assumed to work as well (eventually, one step-at-a-time).   The board did not work with the Arduino IDE out of the box.  The suggestions were followed from the Arbotix web site, but I came up with errors (build.target was “null”, and suggested the preferences was not right).   Nothing on the web directly pointing to this error with Arbotix, but a few with Arduinos – but for different reasons.   Bottom line: pasting the board specs onto the end of ‘boards.txt’ did not work – always threw that error.  After deleting ‘preferences.txt’ and stripping out most of boards in ‘boards.txt’, I decided to replace the parameters for the ‘Mini’ with the Arbotix ones.  I renamed the the first line so I would know “…##mini.name=Arduino (Arbotix)”.   I compiled the ‘Blink’ sketch with pin 2 selected without any errors.   Uploaded the sketch to the board – no errors so far.  Hooked up a breadboard with an LED and resistor to digital pin ‘D2’ and the booger started blinking as it should.  Finally!

Arbotix Blinking with Arduino IDE

Posted under Robotics
1 2