Pico-Kubik quadruped robot

Camera and battery problems aside, I finally got this little fellow to walk on its own, without a cable connecting it to the computer. It still uses the serial interface to talk with an Arduino Pro Mini, which is its spinal cord, but this time the signal comes from the VoCore board mounted under its belly.

As you can see, it's far from perfect. There are a lot of spasms, which I suspect come from noise on the serial line (although they are suspiciously regular). I will try lowering the baud rate of the connection next, to see if that goes away.

I also have some progress on the camera front. Turns out that an older version of mjpeg-streamer doesn't segfault in the YUV mode, so I'm going to use that. Unfortunately, the battery accident left me without a working camera, so I'm waiting for a new batch of them to arrive (I get them cheap from junk laptops). In the mean time I made a proper plug for the camera module, so that, hopefully, I will break fewer.

Today is a sad day for this project.

I decided to use a new battery that I bought specially for this robot, instead of using battery packs from my Walkera RC helicopter. Taught with previous mistakes, I have a socket for the battery that only lets you insert the plug the correct way. Being assured by this, I didn't really look carefully when I connected the battery... Alerted by the hissing and smoke from the power switch, I immediately disconnected it but... too late.

What happened? Look at this:

See? Battery packs from different manufacturers have the plugs in reverse... I suppose that increases their sales.

Unfortunately, this time not only the power switch is fried -- also the VoCore. The Arduino Pro Mini and the camera module seem to be fine, though.

While I still didn't get to get the camera modules to stream any video, I worked a little bit on the servo controller and mechanical parts of the robot.

For one, I discovered why all the frequencies were half what I expected from the code -- I selected the 5V, not 3.3V board in the Arduino IDE, so the code was compiled for the wrong model. Selecting the right board fixes all those issues.

Another thing is the voltage monitor. I added a simple voltage divider on two resistors, and connected it to one of the analog pins on the servo controller. Now I can shut down the servos if the battery voltage reaches a critical level.

I also painted the servo horns at the ends of the legs with some rubber paint, hoping that will let them get a better grip on the floor. Unfortunately, it seems to have very little effect.

Finally, when testing the new servo controller code, I must have shorted one of the cables, and my servo controller released blue smoke. As you all know, those electronic components are actually powered by magical blue smoke inside, and if you release it, they stop working. I'm considering using a 5V one now, because I've run out of 3.3V replacements...

Update: So, after some research, it turns out that the part that got fried is... the on/off switch. Phew. That's literally the cheapest part, so I'm lucky.

I decided to get the mjpg streaming working by using a different camera module. This one comes from an Asus laptop and is called MT9M112. The cables didn't take long to figure out: the black and brown are VCC, the silver and green are GND, and the orange and red are USB+ and USB-, respectively. The camera needs the gspca_stk1135 kernel driver, which means that I will have to compile a new kernel for VoCore again.

The first surprise -- the OpenWRT's menuconfig command doesn't let me choose the gspca_stk1135 module. I suppose it's a recent addition, and needs to be enabled manually. We'll see if it works on this architecture at all.

Second surprise -- I forgot that flashing OpenWRT image resets the root password to "unset", and since I disabled the serial console to be able to use the serial for the servo controller, I have no way to log in. Now I have to flash a new image using the slow method, over kermit.

At least the camera is slightly shorter, so it will fit better on the front of the robot.

UPDATE: Nope, the new camera doesn't support mjpg either, and the YUV mode also segfaults with it.

Finally all the parts come together: 12 servos, Arduino Pro Mini, VoCore board, camera module and battery. I was a little worried about the battery handling this load, but it turns out it is around 400mA together (VoCore is up to 200mA alone). It will probably be more when the servos work, but the battery should still handle that.

Of course I initially connected the serial line from VoCore to Arduino backwards, but fortunately no other problems. The serial line works, but I still need to build a custom image for the VoCore to disable logging to console on it -- otherwise it interferes with the servo commands.

The UNIX version of Micropython works nicely on VoCore, and can write to the serial just as to a normal file. The example program I run just shifts the whole body around a little, and it went a little crazy because of the console logging, but it will work just fine.

The camera only works in the photo mode, with fswebcam, and I can't get it to stream, but I think I will leave it for now. I might get it to work later on.

What is left now is all the software, as well as holding all the parts together in a better way than with a rubber band. I also might add a voltage regulator later on, when I get one small enough.

And how about a paper chassis, making it look like the robots in Uber's failed Human Resources? I will have to think about it!

With very little progress with the camera (I can make shots with fswebcam, but when streaming with mjpg-stream, all frames are empty), I decided to go back to the mechanical part and see if it actually walks. I measured the legs, put it all into the inverse kinematics and copied the code for the creep gait from µKubik. Turned out I need to do some more fine-tuning of the trim and reverse settings in my servo controller, but it finally walked:

It's still pretty slow, and the cable makes it unbalanced, but the basic idea is there.

Now back to getting the camera to work. In the worst case I guess I will just stream the shots made with fswebcam... I wish I had OpenMV for this robot brains.

I have the servo controller working, with all the servos trimmed and reversed to the right base positions. I should be able to get it to walk by controlling it over TTL2USB from the computer.

In the meantime, I got the UART on VoCore to work the way I wanted. Next thing is to get it to work with the laptop camera module over USB. Right now I got it to actually see the camera device and load the right kernel drivers for it. Running mjpg-streamer switches the LED on the camera on, and I can go to the website to see the stream... Except all the frames have 0 bytes, and the driver crashes as soon as I stop the streamer.

No walking video yet (I need to update the dimensions and leg order in my walking code for this robot), but here's the start-up sequence:

I starts up the servos in sequence, not all at once, to avoid a sudden surge of power drain and a brown-out.

After looking at the PWM library for Vocore (http://vonger.cn/?topic=pwm-is-running-at-gpios) and trying to actually solder more than 2 wires to its tiny 1.27mm headers, I decided that I don't want to drive those servos directly from Vocore. I need a servo controller. A 3.3V Arduino Pro Mini clone will do quite well for that, with a very simple sketch for setting the servo positions by TTL (https://bitbucket.org/thesheep/pkubik/src/tip/controller/).

This way I can test the mechanical part of the robot already, by talking to it over USB2TTL from the computer, and then add Vocore and use one of its two UARTs for the same thing. Writing to a tty file should be easier than a PWM driver.

One problem now, though. Arduino's Servo.h library worked perfectly on the 5V Pro Minis that I used before, but it seems to have some problems on the 3.3V one. Either the library is sensitive to the CPU speed change, or the board is simply not fast enough to drive all the 12 servos. Or I simply have some silly mistake in there.

Update: Seems like just halving the pulse width does the trick.

My vocore boards finally arrived. They are so tiny!

So far not much done. I have tested one of the boards, ssh'd into it, installed the Micropython packages on it from the OpenWRT repositories, got TTL to work, tested that the interactive shell works.

Next I will need to experiment with GPIOs and PWM on it, see if I can get it to control the servos directly. In the worst case, I will just connect a 3.3V Arduino Pro Mini over TTL as the servo controller, but I'm optimistic.

The PyBoard will probably get moved to a slightly bigger robot body.