08 Jul 09 The Linux Robot – In hindsight

Having written 3 major programs for the robot:

1. Move about randomly avoiding objects using proximity sensors as well as stall detection. The stall detection is simple in so far as it’s just a detection of a current spike during continuous motion a certain percentage threshold above existing current consumption.
2. Move randomly to a bass beat of music.
3. Follow a light. The logic for this is simply to rotate all wheels in the direction of which of the photoresistors shows the lowest resistance until they are both equal +/- 5%. When this occurs, assume you are looking straight at it, and move forward until they are no longer equal. Then readjust using turning logic and continue. It works surprisingly well!

What would I do differently next time around?
(more…)

Tags: Linux robot, the robot

21 Jun 09 The Linux Robot – Dancing Beat Recognition

I haven’t had a chance to post anything here in quite a while now, partly due to lack of time, and partly due to lack of interesting or original material.

SEE VIDEO BELOW! I found myself with some spare time over the past few days and decided to try and get the robot to dance autonomously. I initially started looking at software algorithms to detect BPM (beats per minute) in music, either by using phase shifting which is challenging to write and not hugely accurate, or by analyzing amplitude peaks at a given [usually bassy] frequency, which is easier to write, and even less accurate.

(more…)

Tags: amplitude, amplitude peak, CPU, ground, input, interrupt, left channel, Linux, Linux robot, phidget, right channel, Robot, sample, usb sound

26 Dec 08 The Linux Robot – Progress, Software & a Video

Over the past week I’ve made a couple of hardware improvements, as well as building the majority of the software library, a TCP server and making a good start on a client.

The camera draws over 350mA@12V and there’s no reason why I need it permenantly on. I’ve connected one of the Phidget Kit’s outputs to a simple transistor/resistor/LED circuit, with a 12V supply passing into the transistor’s collector pin, through the transistor, relay input and resistor. Then I’ve connected the camera’s power over the relay’s output. The power on and off for the camera/LED are now through setting the board’s digital output 0 to 1 and 0 respectively. Power consumption with no movement has now dropped from 1.25A to just under 0.90A. I’ve also put all essential USB hardware on one usb hub and all optional hardware on another (USB to TTL adapters, sound adapter) on the other. The optional hub is also on a relay now on the opposite side of the robot, and this now reduces idle power consumption from 0.90A to about 0.50A which I’m happy with.

I’ve spent a while working on the software site of things. I’ve written a ‘library’ in C which interfaces with the various hardware that we’re interested in. The library provides a number of functions, I’ve listed the useful ones here, and they’re hopefully pretty self explainatory: (more…)

Tags: 12v, beej, C, camera, collector, cvoiceengine, digital output, LED, Linux robot, phidgets, phidgets sensor, port settings, power consumption, relay, resistor, software library, speech to text, struct, tcp server, termios, transistor, usb hub, usb to ttl

30 Nov 08 The Robot – Progress and a Video

Well finally, here is the promised video…

The majority of the previous hardware issues have also now been solved which is good. The degrading CF cards was caused by a bad Alix board (I’d probably blown a resistor somewhere at some point). A replacement Alix board has arrived while I sell the other on eBay as faulty for any enthusiast who may wish to try and repair it. I am also using a SanDisk genuine SD card in an SD to CF adapter rather than some unbranded CF card. No filesystem errors and the disk now behaves as it should.

The motor controllers sometimes dropping/misinterpreting commands during heavy load was solved by a number of different fixes. Firstly, I believe with the USB to TTL converters the data lines are pulled up to 5v with a 4.7K resistor. I added a second 4.7K resistor in parallel to Tx to give the controller more of a chance against interference. I also added various smoothing capacitors, and edited my serial port byte transmit tool to restore the serial port settings graceefully on exit. Oh – I also cut the cables from their default 1m to the 12cm that I needed.. No more dropped commands.
(more…)

Tags: 4.7K resistor, alix, Alix board, DC to DC adapter, degrading CF, Linux robot, motor client, motor server, nc, netcat, parallel, sabertooth motor controllers, SD to CF adapter, smoothing capacitors, usb to ttl

22 Nov 08 The Robot: Independant, moving, talking, and controlled via WiFi

I’ve made some excellent progress over the last week! The Robot is now independant, and it moves freely. I’ve written a simple shell script to take the following characters as control:
a – left
s – stop
d – right
w – forward
x – back
q – hard stop
k – turn anticlockwise
l – turn clockwise

This sends a single byte to the serial port. I am using 2xUSB to TTL converters which show up as

/dev/ttyUSB0 and /dev/ttyUSB. Each serial port controls two motors through the sabertooth controller. As we control two motors with only a byte, each motor has a 7 bit resolution from full reverse to full forward. For motor 1, 0 is stop, 1 is full forward, 64 is stop, 127 is full reverse. Motor 2 starts at 128 for full forward, 192 for stop, and 255 as full reverse. Although 7 bits of accuracy, speed changes only seem to occur at roughly 4 intervals, so we technically have about 32 different speeds, 14 forward, 2 stop, 14 reverse. We’re only using 3 speeds though as I can’t see the benefit in programming for any more right now.

The movement now seems to be working well. Smooth, controlled and straight which is something of a miracle

The battery is a 12V/7.2Ah sealed lead acid battery. With USB devices active, the board running and the processor 100% active, as well as peripheral fancy LEDs, digital outputs high, wifi active, etc, it uses 12v/800mA.

With all four motors moving at full speed, it uses 12v/6A. Seeing as the motors will be in action for short periods only, I would expect 6h+ battery life.

I have tested the sensors, and they are all working and reporting data except for the top back one which I’m going to have to investigate. Here are some more pictures:

(more…)

Tags: digital output, espeak, Linux, Linux robot, motors, sensors, serial port, the robot, usb devices, usb sound, usb to serial, usb to ttl

20 Nov 08 Linux: AVIT Research USB to TTL Cable

I ordered a USB to TTL Cable to control two Sabertooth 2×25 motor controllers as part of the Robot project.

I plugged it into a Windows PC, and used ‘RoboRealm’ to control the motors via the COM port that appeared. Worked perfectly. Motors, controller, USB to TTL and virtual COM port – excellent.

I then plug the cable into my Linux board and guess what, no driver claims it and I have every standard USB Serial module compiled. AVIT Research’s website also gives no help on Linux support.

The device shows up under lsusb as:
Bus 002 Device 002: ID 10c4:818b Cygnal Integrated Products, Inc.

The solution was luckily simple. After prising open the cable and doing some research, the ‘cp2101′ driver is the one that we want. I’m using 2.6.27.6 but this should work for any cp2101 version.

(more…)

Tags: 10c4:818b, 2.6.27.6, AVIT Research, com port, cp2101, cygnal integrated products, diff, Linux, Linux robot, lsusb, motor controllers, roborealm, Robot, sabertooth, usb to serial, usb to ttl, virtual com port

16 Nov 08 The Robot: Base, Wheels, Motors, and Sabertooth Motor Controllers

After attaching the 4 motors and brackets to the acrylic square, I found that it started to dip slightly due to the weight, and as I’d planned to put a 1.5kg lead acid battery in the center and I realised that this needed to be addressed. Rather than another visit to Homebase for some steel reinforcement, I just stuck (melted) two pieces firmly together with polycarbonate acid glue and then trimmed the edges with an electric saw.

Here is the base, the insulation tape all over the place is to hold down the connectors that I won’t be needing. The motors all contain encoders which I didn’t just want to rip out, so I’ve preserved the connectors for future usage, and just cut the – and + cables in a way that they can easily be reconnected to the connector if I ever want to. They were expensive motors so I didn’t want to ruin them!

If anyone is wondering why I didn’t attach standoff cylinders to the controller’s super large heat sink rather than attaching it directly to the acrylic base [which would normally be a bad idea], it’s because I didn’t have any standoff’s left, and the controllers are capable of 25A per channel. I will never drive them at higher than 4A, and the motors running on 4A for 30m or 2A for 2 hours solidly as a test didn’t generate any noticeable heat on the heat sink at all. At first I had also predicted the use of a fan to suck air in from the base, but I’m not sure it will be necessary, as nothing seems to get remotely hot so far..

I’ve also slightly indented the 4 points where the acrylic cylinders will be glued, just for extra stability. The motors are all wired to the two motor controllers, which has a junction box waiting for 12v now. The picoPSU should arrive some time this week, so hopefully I can get on with it.

The wheels are omnidirectional as they contain rollers. It’s a clever design and it seems to work well. Infact, I’m pleased with the way the motors and wheels ended up. Instead of having to work with two wheels and spending time on calculating angles for servo motors and turn radius, I can just attach 4 motors instead in the configuration that I have and using omnidirectional wheels. The motors will pull a lot of weight and I only have to concern myself with backward and forward for each motor, which in any combination will allow it to move in any direction. Hey, I’m not saying that I ‘invented’ this ingenious combination, just taking the credit for a smart move in implementing it! I have connected a power source directly across each of the motors to test. They are straight, and when I turn them all in the same direction, the board rotates around a ‘very almost perfect’ fixed axis which is great. I had in mind when I was positioning these, that I didn’t want to spend a ton of time in the software compensating for wheels that aren’t straight.
(more…)

Tags: 2x25A, analog voltage, battery, ground, lead acid, Linux, Linux robot, motor, motor controller, omnidirectional wheels, packetized serial, picopsu, rc input, sabertooth, simple serial, the robot, tx pins, usb to ttl

14 Nov 08 The Robot: A body, Sensors and Good Progress

Progress is going really well and I’m happy so far. Unfortunately I didn’t want to show the body yet as it is so far from finished but as I haven’t posted an update in a while I decided to just go with it.

The body is ever so slightly lop sided by a few mm here and there which is a shame however from a short distance you wouldn’t notice, it stands up straight and weight distribution is equal throughout the base plate so I’m happy with it. Ok, ‘professionally’ the body’s a mess however for my zero experience in that kind of work, I’m reasonably happy.

This is the front of it, top is a mounted webcam, to the left of that is a phidgets temperature sensor and top right is a phidgets light sensor. I am waiting to add 8 colored status LEDs around a small flat panel 5v stereo speaker as a ‘mouth’ (I got it from a Nokia phone bundle).
(more…)

Tags: battery pack, distance sensor, IR remotes, irda, LED, light sensor, Linux, Linux robot, MAX232, motor controller, nimh, phidget, phidgets sensor, picolcd, picopsu, polycarbonate glue, sabertooth, serial port, stereo speaker, temperature sensor, the robot, usb phidgets, usb sensor kit, webcam

10 Nov 08 The Robot: More good progress

Some more hardware has arrived! Very compact USB hub with external power input, Startech USB sound adapter (line out/mic), 4Gb USB mass storage, USB Trust Webcam.

All plug and play, all works out of the box. I’m using Alsa to drive the USB sound adapter, and v4l for the webcam. Works great and the majority of the hardware works.

Now I haven’t added any pictures to this entry, as I don’t think there’s much point in looking at more pictures of a messy table! I hope that my next post will include pictures of a (reasonably) cool acrylic body. I’m still waiting for the acrylic sheets to arrive though.

The two remaining parts of the hardware to get working are wheel movement and power/battery.

With all board hardware working excluding motors, we’re on 12V/600-700mA which I think is pretty fantastic.

I’m going to go for a NiMH battery pack (12V/10Ah) and not plan to generally discharge more than 12V/2A. The motors will realistically be in use rarely as it’ll be making short slow and unfrequent movements, rather than racing around at full speed!

The battery pack will connect directly to both motor controllers, as well as to a PICOPSU and then to the board.

So.. next stage is to get all the hardware off the table and into some acrylic casing with a 12V DC power source. Once that’s done I can look further into the motors and battery!

Tags: acrylic, alsa, Linux, Linux robot, nimh, usb sound, v4l, webcam

07 Nov 08 The Robot: Phidgets USB Interface Board Kit works

The Phidget interface kit arrived and so did a few of the analog sensors that I ordered. I can’t believe just how simple they are to use and just how friendly and comprehensive their SDK is!

Here are some pictures:

This is the interface kit itself. It’s a regular USB device and draws minimal power. Along the top of the board are the analog sensor inputs. Each is connected via a simple 3-pin wire, ground, data and +V.  Along the right hand side are 8 simple digital on/off inputs. Along the left hand side are 8 just as simple digital on/off outputs. In this case, I have connected the Phidgets analog light sensor which you can just about see on the left of the picture. Download the Phidgets Linux SDK from their site, compile, and run the examples. The range on the light sensor is fantastic. It advertises 0 to 500 range and does indeed live up to the promise. Pitch black and the sensor reads < 5, and pushed up close against a 400W light, the sensor reads > 480. Normal light conditions and the sensor reads between 30 and 180 – very very useful.

The SDK comes with plenty of examples and is incredibly user friendly! I would recommend these all day long.. it really is plug and play.

And here’s a distance sensor. It’s a simple IR mechanism that ranges from about 1m to 10cm. There are also 10cm to 5mm sensors available. Again, works great, really reliable.

So now these work, I’ve ordered some more and they’re on their way. One temperature sensor, two voltage sensors, some sonar sensors and more IR sensors – fantastic products.

In the mean time, I’ve ordered a load of clear acrylic and plan to start putting a body together shortly.

I’m still having a little trouble talking to the motor controller so if anyone has any I2C knowledge, please please let me know. I don’t want to buy a prebuilt base.. I think it’s cheating.

Tags: Linux robot, phidget, phidgets, Robot, usb interface board