Further to a comment I received http://www.adamsinfo.com/the-robot-phidgets-usb-interface-board-kit-works/comment-page-1/#comment-490 I thought that it might be a good idea to write a quick high level overview of getting the USB Phidget Interface Kit working under Linux. In my case I am of course using 32bit Debian, however these instructions should mostly be portable to any other Linux based OS
Tags: debian, gcc, Linux, phidget, phidget interface kit, usb
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.
Tags: amplitude, amplitude peak, CPU, ground, input, interrupt, left channel, Linux, Linux robot, phidget, right channel, Robot, sample, usb sound
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
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
Progress has as always been good lately. The robot boots up quickly and appears on the wireless LAN, with openssh running. The internal Atheros miniPCI wasn’t doing the trick and wireless performance was shaky at best. I’m using an Alfa Networks USB adapter (r8187) and an 8dBi gain antenna now, so this has some distance now!
I was also getting frustrated with the laggyness of the board while VLC was running for streaming audio and video and so I decided on an IP Camera (Edimax), which is connected directly to the LAN port on the Alix board (I don’t have any reason to use it for anything else).
The motor control script works well and the device is responsive. At this point I can drive the device around
relatively easily and accurately, stream video and audio back to my laptop, which again is connected wirelessly.
Using ‘espeak’ you can easily generate a synthesized voice to provide easy text to voice:
Everything is working great and I’m pleased so far. The only reason why there isn’t a video up yet is because I haven’t had the time! There will be one up shortly.
(more…)
Tags: 8dbi, alfa networks, alix, antnna, atheros, cf card, distance sensor, edimax, espeak, gain, hardware sensors, ip camera, Linux, motor control, phidgets, picolcd, power consumption, r8187, SD card, serial, usb, usb to ttl, vlc
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:
Tags: digital output, espeak, Linux, Linux robot, motors, sensors, serial port, the robot, usb devices, usb sound, usb to serial, usb to ttl
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
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
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
Some hardware has arrived!
So my working space is a little bit of a mess at the moment. There’s no better way of getting started than just getting straight to the point.
The Alix 3c2 main board arrived in good health and works well. On the underside is a 512MB CF card and an Atheros MiniPCI Wifi. I’ve soldered single core wire to the I2C bus pinout. GND, CLK, Data & +3v.
I’ve also soldered bell wire across the power input. It accepts a wide input and so I’ve decided on 12v.
This is my prototype “power distribution board”. Currently it consists of 2 12V/2A regulators, some resistors and a 1000uF/30V smoothing capacitor. It provides 12v to the Alix board, and 12v to the motor controller. If both motors stall, they can use up to 6A, so whilst this is fine for testing the controller board, I’m going to have to replace one of the regulators with a transformer system to provide the necessary power to the motors.
(more…)
Tags: 12v, 38400 8n1, 3c2, 512MB CF card, alix, alix 3c2, atheros, atheros 5212, capacitor, card reader, clk, data, debian, debootstrap, gnd, Hardware, i2c, i2c bus, i2cdetect, Linux, minipci, motor, null modem, power distribution board, prototype, pxe boot, regulator, resistor, serial cable, serial console, smoothing capacitor, solder, transformer, wifi, wire