- Written by Kyle Granat
Interfacing a PhantomX Hexapod with my IR Sonic Screwdriver via a little IR receiver. More details soon.
For a long time I've been trying to come up with a reliable way to have one of our PhantomX Hexapods follow me around autonomously. The dream would be to have some kind of cheap/easy/effective way to track an individual. I'm still playing with some vision tracking ideas, or using a Wii-mote camera, but that's for another post.
While trying to come up with a cheap/easy/effective way to implement person-tracking, I started thinking about alternative control options. I realized that a joystick like in the ArbotiX Commandercould be mounted to the Chassis of the Hexapod and pulled from a string or a leash. By tying the analog input from the joystick to the inverse kinematics engine in the crawler, the movement of the joystick will directly control the movement of the joystick. Whichever way you pull the leash, that's the way the crawler will go.
Now it's not quite as easy as just slapping any old joystick onto the Hexapod. I've been using our RobotGeek Joystick since it's got nice mounting points and are pretty plentiful around here. The size was just right for being able to control the hexapod. For the longest time I was using some washers and the mounting points for the turret on the main chassis of the hexapod. This held up pretty well, but wasn't really ideal. Finally I asked our production manager Kevin to cut me a custom plate with the 2x3cm pattern so I could just fit the joystick mountin holes on correctly.(If you're a hexapod user interested in a plate, drop me a line, include your order number, and I'll get you one)
Early on we didn't have the tall-stick add on for the joystick, so I made the small mushroom style stick cover work. I would use a small zip tie around the thumbstick, leaving just enough slack to put a leash clasp through. This worked pretty well, but sometimes it would get stuck around the zip-tie. Also, there were definitely some angles that worked much better than others - very steep/shallow angles worked well, but ~45 didn't always get the crawler moving. However now with the tall-stick add on, things are much easier. I've drilled a small hole in the stick, allowing me to thread a twist tie in - this then connects to the clasp, and movement is much easier.
I've taken the leashed cralwer to a few events, and it's always a big hit. Kids and adults love it, and it's a great ice-breaker into explaining robotics to people. Almost every kid I meet asks 'is that a playstation controller?!' when the look at the joystick.
The PhantomX Quadruped can function in the same way. I find you have to be a little more gentle when you start the quad moving, but it's fairly stable once it gets rolling.
I'll have more photos and a video up by the weekend's end.
Code is available here. If you've found this post before setting up your cralwer for some reason, check out the cralwer Getting Started guide for getting setup with the ArbotiX-M Hardware, software, etc.
Thanks to my sister for all the great photos!
These arms are controlled by the ArbotiX Robocontroller. This microcontroller handles the low level communications with the DYNAMIXEL servos, and the inverse kinematics engine. The goal is to be able to send a serial packet from the computer to the ArbotiX Robocontoller (using a USB-to-FTDI deive) and have the arm move to a position in space.
However before the program can start issueing commands, it must connect
The last two parts of this can be acomplished by sending the ArbotiX an ID request. If this packet is sent on serial connection that an ArbotiX (running the ArmControl code)0 is on, the ArbotiX will send a return packet with the Arm ID. Originally the arm's initial control structure looked something like this whenever the ArbotiX is powered on/reset
Start Serial Port -> Wait 50ms -> Put Arm in Sleep Mode -> Start Accepting Packets
The problem with this structure is that therer can be a significant delay from when the ArbotiX is reset until the ArbotiX starts accepting packets. Putting the arm in sleep mode involves noving the arm to a pre-defined position, then turning the servo's torque off. Sleep mode can take several seconds if the arm is not near the 'sleep' position. Now for connecting to a serial port where you are certain of which port you are on, this delay isn't too terible - maybe 5 seconds in the worse case. But what if we want to implement Auto-Search? If we have 4 ports available, it can take 20 seconds just to connect to the arm! So I suggested a change to the control structure to this:
Power Arm On -> Start Serial Port -> Wait 50ms -> Send ID Packet -> Put Arm in Sleep Mode -> Start Accepting Packets
Now in this case, whenever the arm is reset, before it goes to sleep, it broadcasts the ID packet.
I thought I finally had a elegant solution to my problem - whenever the serial port was connected to, it would reset the ArbotiX, the ArbotiX would send the packet within 60ms - meaning I would only need to wait 60ms on any port to watch for a response. But after a bit of testing with different hardware and software I found something very odd: My FTDI-USB cable (that ships with each arm) was acting very stangley on windows 7 - after I initially connected to the arm, I could not reconnect. It seemed that the java drivers would reset the FTDI-USB device when it first connected, but not sunsequent times it was connected. Here are some of my findings.
|OS||FTDI Hardware||Software Driver||Resets on first connect?||Resets on consequential connects?|
|Mac 10.8||UartSBee||Java RX/TX Library(Processing)||Yes||Yes|
|Mac 10.8||UartSBee||Java RX/TX Library(Arduino)||Yes||Yes|
|Mac 10.8||FTDI-USB Cable||Java RX/TX Library(Processing)||Yes||Yes|
|Mac 10.8||FTDI-USB Cable||Java RX/TX Library(Arduino)||Yes||Yes|
|Mac 10.8||FTDI-USB Cable||Other(Terminal)||Yes||Yes|
|Windows 7||UartSBee||Java RX/TX Library(Processing)||Yes||Yes|
|Windows 7||UartSBee||Java RX/TX Library(Arduino)||Yes||Yes|
|Windows 7||UartSBee||Other (RealTerm)||Yes||Yes|
|Windows 7||Arduino Uno||Java RX/TX Library(Arduino)||Yes||Yes|
|Windows 7||Arduino Diecimila||Java RX/TX Library(Arduino)||Yes||Yes|
|Windows 7||FTDI-USB Cable||Java RX/TX Library(Processing)||Yes||No|
|Windows 7||FTDI-USB Cable||Java RX/TX Library(Arduino)||Yes||No|
|Windows 7||FTDI-USB Cable||Other (RealTerm)||Yes||Yes|
This problem is somewhat exacerbated by the fact that there are no good ways to turn on/off the reset behavior using the java libraries. So the lesson here is that you really can't rely on the reset behavior of FTDI devices. I was struck by the fact that this problem was only with a certain kind of FTDI-USB device, on windows 7, with the java libraries.
The idea for this project is pretty straight forward - put a small bluetooth headset into an antique phone headset.
After scrounging the local antqiue dealers. I came across a great candelsitck headset. It was in fairly good condition (some chips on the ceramic parts, but surprinigly no rust) and it even had an external button!