Hexapod Makeover

[Matt Denton]

I can't remember the exact function I used, its been a long time since I looked at iC's code however, it would have been the what ever the sample face detection code used. What I will say is I spent ages tweaking image size and code to get good results, plus I seem to remember using a call back version of the video capture instead of the suggested (grabframe) method.. its all a bit of a blur now.

Initially it ran on a mini ITX 1.7Ghz Pentium M processor, now it has an 2.0Ghz Pentium M processor.

[blegas78]

I see, I understand that you use a callback version of the grabframe function. My initial test used the logitech communicate deluxe, but there seems to be a frame buffer that holds three frames, causing a massive delay in control, especially when dealing with only 5 fps. Instead I used the machine vision camera which captures an image immediately, but the current resolution is 1280x960. Fortunately it has the capability to have settable resolution, but it does not work with the OpenCV library, so I have to create my own functions to capture images to the Iplimage format. Currently the function only works at the maximum resolution

I think I'll be working on it this week to get the parameters and functions running faster. Do you have problems with people tilting their heads?

[Matt Denton]

Do you have problems with people tilting their heads?

Yes, after a certain angle the face recognition falls over.. but then so does the person tilting their head

[blegas78]

Fortunately after tinkering around with the code and the machine camera's capabilities, I am now able to achieve 15fps of face detection. The largest part that affected the rate was the machine camera being set to a resolution of 1280x960, but I was successful in lowering to 640x480, which doubled the frame grabbing speed. Currently the face detection is a bit rough, so I may lower the frame rate to around 12-13fps to get better measurement data. It certainly is working much better though!

I have another event on Thursday, involving many of the major donors to the University of Arizona, so I want to make sure it runs well. Again, if I'm happy with the results, I'll post a video.

[wuselfuzz]

This is quite an impressive machine you made.

You're writing that you can do IK at up to 400 Hz. The 200 MHz ARM9 CPU on my bot manages to do an IK run in about 900-1000 microseconds, that's almost 1kHz.

However, that's just the pure ik() function running with no other processes in the background.

How did you implement the servo controller and ik engine anyways? How do they interact with the computer vision system?

I'm currently at the stage where I have to find a concept for ipc, because the cv functions are obviously too slow to do them just in time before the next servo update happens.

So I'm planning on creating some daemon that runs a simple sequencer that does ik and servo updates via spidev in realtime and listens for commands on a tcp and a unix domain socket.

A control utility can then connect to that daemon and issue high-level commands like "translate body by (-10,0,0) with a movement duration of 15 frames" or "walk forward with a step vector (10,0), step height of 20 and step duration of 5 frames" (my sequencer can already do this).

Naturally, this daemon would also gather simple sensor inputs (feet pressure sensors, other GPIO) periodically and allow a client to query them.

I took a peek at ros, which seems to address these issues.

I'll also remake the FPGA design soon, that thing is a mess. There's still the old cpu running there, filling memory mapped servo registers with data received from software-handshaked SPI. The new design will feature double-buffering for the PWM values and a frame microsecond counter that will run down to 0. So the process running on the linux side can send servo data to the servo controller, do ik for the next frame and then query the time it's got to sleep until the next frame actually starts.

hmm.

*rushes off hacking some VHDL*

[blegas78]

wuselfuzz, thanks for the compliments!

400Hz includes the sending of the motor control protocol to the servos, so an actual loop purely with IK would be just fine, but the loop includes the sending of the protocol. The protocol includes up to 157 characters at 1Mbps, with one stop bit, one start bit. This is the part that's slowing things down.

I built a simple circuit with the PIC18F4550, where I use the USB hardware peripheral. I could just have easily used an FTDI chip, but the PIC allows me to take advantage of the other hardware peripherals. This is perfect for reading any sensors, whether they use I2C, UART, ADC, etc.

I have two main threads running, one for vision and the other for kinematics. The vision thread processes how to control the body based on whatever behavior I want to implement. I have a couple of other threads running as well, depending on application. The Sixaxis controller runs in a separate thread. I was also thinking of splitting some of the vision code up into a frame grabber thread and processing thread.

High level control is certainly very nice, and I have implemented this on the hexapod. I can very easily change high level values like body velocities, angles, balance gesture enabling, etc. I plan on building a web interface, so that anyone can control the hexapod through any computer. The fit-PC2 works as a nice little WIFI web server.

Also part of the reason to build a web server based controller is to be able to control it through the internet, and my coding experience is far too minimal to do anything as complicated as what you can do! I'm still struggling to put everything into a debian package so that anyone can install my libraries on their system.

[blegas78]

I have been working on replacing the controller inside of the Robotis motors. Last semester I took an automatic controls class (ECE 441) where we learned to design controllers for various systems. This semester I am taking the followup class, digital controls (ECE 442), where we learn how to deal with the complications involved when implementing controllers digitally. I am now applying the ideas presented in the class to the hexapod.

I will be printing some PCBs, using the dsPIC3012, which is a 16-bit PIC with a 12-bit ADC, in a very small package. So far you can see the prototyping electronics, which uses a simple h-bridge chip, LED, and voltage regulator. I am using the internal RC oscillator in the PIC with a 16x PLL, running at nearly 32 MIPs with the use of the RC tuning registers. With this I am able to mimic all of the availably baud rates of the Dynamixel bus.

So far an improperly tuned PID is implemented, but most of the Dynamixel protocol has been reverse engineered, and the available programs from Robotis to operate think that my controller is a standard Dynamixel motor

[wuselfuzz]

Interesting.

I also thought about hacking my servos so I can use SPI, I2C or another protocol instead of the clumsy PWM.

In other news, I damaged a HS-225MG gear, some y-translation variable went into z-rotation (typo), and that y value had an order of magnitude of about 10... It's still working, but doesn't run freely if I try to turn the leg. Meh.

[Matt Denton]

I have been working on replacing the controller inside of the Robotis motors. Last semester I took an automatic controls class (ECE 441) where we learned to design controllers for various systems. This semester I am taking the followup class, digital controls (ECE 442), where we learn how to deal with the complications involved when implementing controllers digitally. I am now applying the ideas presented in the class to the hexapod.

Nice work! As you know I have had many a rant about these servos and their lack of resolution and decent control! I hacked them to increase resolution by amplifying the signal from the pot to reduce operational range to 150 degrees. However, I much prefer this solution, and at one point considered doing exactly this. Once you have your board design/code sorted, I would be happy to try the hack out on my servos, plus help with the PID control. I have done quite a bit of pic based PID controllers.

[blegas78]

I also thought about hacking my servos so I can use SPI, I2C or another protocol instead of the clumsy PWM.

I strongly prefer serial communication over PWM as well, and makes wiring much easier as you don't need to connect each servo to a specific place. Fortunately the board I'm designing will work with other servo motors too, and I can then use any hobby style servo motor directly with the Robotis motors.

Have you heard of OpenServo? Might be a simple option for you to integrate I2C.

Once you have your board design/code sorted, I would be happy to try the hack out on my servos, plus help with the PID control. I have done quite a bit of pic based PID controllers.

Sounds like a plan to me! I hope to implement self-tuning, so the motor would measure itself under a certain applied motor current, then pick the PID coefficients according to the measurements and some desired parameters like a settling time and certain percent overshoot (most likely zero all the time). The cool thing is that these parameters change for different applied rotational inertia and voltage inputs, so the motors can tune themselves automatically Part of the modified protocol will include setting manual parameters for the PID through the standard Robotis protocol, so the PIC doesn't need to be re-programmed every time.

When I get the boards made, I'll try to order some extra and send a couple to you. Hopefully I'll make use of the pick-and-place machines from the PCB manufacturer as well.