Leashing your PhantomX Crawler's Potential

Read more: Leashing your PhantomX Crawler's Potential

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.

  • When I went to RoboGames last year, I needed to switch back and forth between having the joystick mounted on the top of the quad to having a pan/tilt video turret mounted on it. I didn't want to reprogram the 'bot every time, so I used a jumper and the ArbotiX's internal pullups to give me an easy way to switch the behavior of the cralwer.
  • I'd like to come up with some other ways to change the gaits and speed of the cralwer. Buttons would be an easy choice, and it might be possible to make it change speed based on objects around it. I'd really like to have some code that would slow down/speed up depending on the number of tugs on the joystick - tug twice and it goes faster, tug to many times and the crawler resists! This mighe lead to more complex behaviors ( the quad follows the leash when it wants to, but not always - it would be cute if multiple crawlers could 'recognize each other)

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.

Read more: Leashing your PhantomX Crawler's Potential Read more: Leashing your PhantomX Crawler's Potential Read more: Leashing your PhantomX Crawler's Potential

Thanks to my sister for all the great photos!

Never trust your Hardware. Or your Software.

Read more: Never trust your Hardware. Or your Software.

I've been developing a small application in Processing to control our three robotic arms.

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

  1. Connect to a Serial Port
  2. Check if an arm is present on the port
  3. Get the information about the arm (the arm type)

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 UartSBee Other(Terminal) 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.

Search