It has been a full two months since the last post here, it has been difficult to find much time recently to work on the Quadruped4 robot.

Finally though I reached a point where I felt I had achieved enough progress to warrant a blog post. I have written enough firmware for the two Atmel processors on the Dynamixel Robotics Controller to get AX-12+ servos moving under control of a laptop connected via WiFi.



I also had to change the small test application I had written to send AX-12 commands via serial to use a TCP/IP socket connection, but once this was done, I had a servo happily moving back and forth as I dragged the mouse over a dial control. May not seem like much, but this is a pretty important milestone I think. If you look really hard at the fuzzy video, you can see the temporary wires tacked on to add a JTAG interface on the secondary micro (secondary micro handles the 1Mbit/s servo comms). I had a fair bit of trouble getting the SPI link between the two micros going well, and a borrowed JTAG debugger was very handy.



On another note, this week Honda's ASIMO robot appeared in Melbourne as part of an Australian tour. Of course I had to go see it even though the show would have pretty much zero technical content! Here is a bit of a sample of some video I took during the show as I sat among all the kiddies.


Back to the Quadruped4 robot, and the next step in construction. Now I have enough electronics and firmware going to move servos over WiFi I think it is time to start on the physical build. I have the design finished to a buildable level I think, and in the interests of getting something going sooner rather than later, I will start on construction. I am quite happy with the attached render of the latest cad model - it looks kind of like it is on the surface of Mars...

Today the Lantronix WiPort wifi module on the Dynamixel Robotics Controller board was successfully tested!

Initially I had quite a time getting the wifi module going - mainly due to confusion regarding the two serial ports (3.3V logic level) the WiPort provides. On the controller board I had designed port 0 to run directly into the main AtMega2560 micro, and the secondary port 1 to run through a RS232 level converter IC and to a DB9 serial connector on board. This port was intended to be used as a serial configuration port only, a means to initially configure the wifi module, and to act as a fall back connection for fault diagnosis if the wifi link was not working for any reason.

Unfortunately the Lantronix documentation for the module, although it mentions both serial ports, doesn't really draw any distinction between the operation of them - as I read the documents, either port could support their serial configuration console.

So, when I fired up the board and tried to enter the 'xxx' required to drop the module into console mode from the DB9 connector - nothing. I went through all sorts of debugging steps because I didn't know whether module, my pcb or the RS232 level converter circuitry was at fault, all to no avail. I did think that perhaps the serial configuration console feature was only available through port 0 (which is connected to my Atmel micro, which currently has no firmware in it to speak of...), however this was harder to test.

I resolved to write some firmware to just pass through a connection from the FTDI USB chip on board to the WiPort module transparently. This way I could use hyperterminal to talk to Port 0 of the WiPort as if I was connected directly to it. I then ran into more difficulties - the USB port was not working - not even getting recognised on the PC at all!

Eventually I found an incorrectly loaded resistor (wrong value...) in the USB circuitry that was preventing the FTDI chip from functioning correctly. Once that was fixed, the USB sprang into life, and I could open Hyperterminal connected to com4 (assigned to the USB serial). Wrote some quick firmware for the transparent link from USB to the WiPort - basically any characters received from either port are passed across to the other. Turned it all on, entered the 'xxx' to jump to the WiPort console, and voila! Success. I could access the menu setting up all the parameters in the WiPort. Next came some rapid learning about AdHoc and Infrastructure modes in wifi networks. I had initially wanted to use an adhoc connection between my laptop and the robotics controller so the whole setup would be portable outside my house, however I couldn't get this to coexist with the infrastructure mode I use at home with my wireless router. Basically I would have to reconfigure my laptop wifi everytime I wanted to use the robot... not very satisfactory. So I ended up just configuring it to use the home network router, which I suppose I will have to take with me if I want to demonstrate the robot elsewhere.


Now I had the WiFi module basically going, I thought of the next test... Since I had firmware in the Atmel to pass through comms from USB<-->WiPort I could telnet from my notebook using hyperterminal to the WiPort Port 0, which would get passed through to usb, which I had open again in hyperterminal on the laptop. This worked! I effectively had an elaborate loopback between hyperterminal windows, and could type in either window and see the results in the other. I then wanted to see whether the WiPort would support simultaneous connections to Port 1 at the same time as port 0, so hooked up a serial cable from the laptop to the DB9 connector on the board, another hyperterminal on com1, and a fourth hyperterminal window telneting to the WiPort Port1. Amazingly, all this worked as well! The image above has this crazy scheme illustrated, two simultaneous telnet sessions, one looped back through an FTDI usb serial connection, the other looped back through the DB9 connector onboard the controller to the laptop com1 serial port!

So now I have tested some large slabs of the Dynamixel Controller, it is time to get it to actually do something halfway useful. I think the next step is to write firmware to link to the Robotis Dynamixel AX-12+ servo network, and then get some software on the laptop to move a servo over the wifi (or even the usb) link. When that happens I am sure I will have to post an blog entry (even though others may not be as excited about the event as I am...).

The last of the parts have been loaded onto the Dynamixel Controller board now, and suddenly the Quadruped4 robot design takes one more step closer to realisation.

Here is an image of the loaded board, with the various main functions described;


The first power on for the board required me to hold my breath a bit, some of the parts are quite expensive (and I don't have spares) so any smoke could have been disasterous...

The WiFi module (a Lantronix WiPort) is able to be removed from its PCB connector, and I haven't soldered in the tabs, so I removed this expensive module in order to check that the 3.3V rail was ok first. The board draw no current to begin with, which is ok since the soft power on/off circuitry would be off unless the push button is held down. Once the micros are programmed with firmware, the system will latch power on after the button is pressed so the button can be released, but for the time being you have to hold the button down. Holding the on button down, the circuit drew only a small amount of current which is a good sign! I checked the two power rails, 5V and 3.3V were both ok. Next trick was to use the two ISP (in system programming) connectors and AVR studio to read and write the fuse bits of the AVR AtMega128 and the AtMega2560 on board. I was able to talk to the AtMega2560 ok, but the AtMega128 was unresponsive. A short time later I discovered the first pcb error... not too bad, cutting two tracks and two small wire mods later I was able to communicate with the AtMega 128 processor.

Once I was sure I wasn't going to blow anything up, I powered up the system with the WiFi module on board as well. The wifi activity led flashes a few times as the module boots up, then the current draw (at the 12V supply to the board) goes up to a significant 300mA or so. I haven't yet tried to configure the module with the RS232 config port yet, so that might be the next step.

I have a lot of firmware already written for an earlier board (the PWM Servo Robotics Controller, see description on the Earlier Work page), so hopefully it won't take to long to cobble together a basic framework from that earlier code to allow me to test the various communications options into the board, such as the USB connection and the WiFi link. I hope the next post here will be able to report that the WiFi link is functional! Following that the real work of designing a suitable protocol and writing code to buffer the serial streams to/from the servo networks and the serial cameras etc. will begin, before the more exciting step of plugging in actual servos, and getting real robot hardware to move!

Time to post an update on what has moved forward with the Quadruped4 robot design. The PCB for the Dynamixel controller has arrived, and all parts for it as well, and also quite a bit of cad work has been done playing around with various options for the mechanical design of the robot.

Here is a photo of the PCB partly loaded. You can see the two Atmel Atmega micros, one is the AtMega128 and the other is the AtMega2560. On the far right is the outline where the WiPort WiFi module will go, with a few parts carefully fitting underneath it in just the right spots where there is some room.

I have also been working on the mechanical design of the robot, and although there is still much to do, and I am not fully happy with several areas, I think the robot will eventually come out something like the design pictured here. Note the WiFi antenna naturally positioned as a tail...

Earlier images I created for this robot didn't have the right cameras on it, whereas I have created a somewhat hasty model of the C328 serial camera modules I actually intend to use for this model. Also check out the shoulder joints for the legs, these use a custom bracket I have designed for the Dynamixel AX-12 servos which forms an offset hinge between two AX-12 servos. This function could be served by the Robotis offset hinge and flat plate bracket put together, however that would be bulkier and would not quite have the configuration I am after. There is a view of just the specially designed brackets and the AX-12 to the right. The brackets form a left and right pair, and attach to each side of the AX-12. I will machine these out of nylon or similar material, and although the machining will be a bit tricky, I think I should be able to achieve it.

Here is another view of the design as it stands. I'm not sure of the top cover, it is really not needed, and I kind of like the idea of seeing the electronics etc, but it will offer some protection I suppose. I need to make plenty of asthetic improvements to the shape of some of these panels as well, the whole thing looks a little like a skateboard deck at the moment.

Anyway, this will be the last post for a month or so, as I am travelling to Italy for a holiday, so robot work will take a break too! When I return, I shouldn't expect it will take long before all the parts are loaded onto the controller and I can attempt the all important critical first turn on...

While I wait for the Dynamixel Robot Controller PCB to arrive from the board manufacturers (update: they got here this morning! looks great!) I have returned to the mechanical design of the Quadruped4 robot.

I was never really happy with the look and function of the leg and hip design I have to date for the little creature, and thought I would create some alternate concept simplified cad models to look at other possibilities.

Original
This is how I last left the mechanical design of the legs. The two axis shoulder or hip joint is implemented by two Dynamixel hinge brackets end to end bolted, at ninety degrees to each other. The thigh is made up of the two AX-12 servos end on to each other.

My main complaint about this configuration is the distance between the two axis making up the shoulder, which tends to make the upper part of the leg look out of proportion if it is fully extended downwards.


Alternate Concept 1
The first thought was to perhaps mount the forward swing servo onto the horn of the other hip servo, this allows really good thigh range of movement, but the bushes in the servo probably won't like all the load on the horn. Better to use the passive hinge point on the other side of the servo as well with one of hinge brackets.


Alternate Concept 2
Robotis manufacture an offset hinge bracket which I thought might be more useful than the straight bracket in allowing a greater range of motion of the joints given horizontal mounting of the thigh servo (as shown left). The image shows crouch and full reach (both dimmed) with standard stance pose undimmed.


Alternate Concept 3
I turned the offset hinge joint around on the thigh to hip joint to see if that improves the range of motion. I don't think it does (see the dimmed forward reach motion in the picture to the left) as the limb can't reach forward particularly far. The crouch pose does look a bit more 'natural' I suppose.

I can't say I am really satisfied with any of the options thus far; more cad experimentation required!

I have been grabbing the occasional hour here and there and have finally finished the layout and routing of the Dynamixel Robotics Controller PCB. A little bit of clean up and it will be ready for submission to the board manufacturer. I have to get going on ordering the parts for it while the board is getting made.

On the web site front, I have put together some info for the page about the Quadruped4 design which uses the Dynamixel Robotics Controller. Hopefully it can help other experimenters find suppliers or gather useful information from the approach I have used.

I have been tackling the Earlier Work page, and have created a lot of content about the investigation into low pressure pneumatic cylinders from MUTR, and the evolution of the Quadruped4 design from its early beginnings as a big heavy cordless drill motor driven creature.

Robots Australia now has a blog!