Three weeks of vacation are over. What exiting things did we do?
- Grind the old color of six more windows and doors and paint them.
- Replace the leaking roof of the shed and replace it with a new one.
- Cut the bigger openings for the four new skylights, seal three of them.
- Make the wiring for the three electric ones.
- Build two of the four new reveals. The old ones don’t fit for the new windows.
That doesn’t sound much, but it kept us busy for three weeks. There is still plenty of work to do at the house. Two more reveals need to be made and installed.
After that I am done with construction work. I want to get back working on the Walker.
During the last months you didn’t hear much about the Walker. Well, during New Year vacation I was much occupied with family and 31C3. But development did proceed. After sorting out servos and basic Inverse Kinematic I am now focusing on setting up the full framework of components communication between them.
I wanted to have the framework in place before getting deeper into motion control and sensor reading because:
- I want to avoid heavy porting from a test environment.
- I want to make sure the design fits to an environment with multiple modules.
- I want to experience any issues because of delayed communication as early as possible.
- I want to develop a framework that allows tracking of joint and sensor values in real time. I’ll have to develop some test functions at all, so make sure to keep them for testing in later stages.
The walker has a core module connecting to sensors and controlling body and movement. Each pair of legs is controlled by it’s own segment module. It controls the leg servos, the tilt servo and reads the contact sensors in the leg tips. Core and segments communicate through serial lines, with the core as master.
On the Mac runs a control application written in Java. It provides a graphical interface for debugging and controlling the Walker. The link between the Mac and the Walker uses Bluetooth. That was the easiest one, the Mac already provides Bluetooth, for the Walker I use a HC-05 Bluetooth module. It provides a standard serial profile and is rather simple to use. It is connected to the core module over a serial line.
I had much fun with Java on Unix talking asynchronously with device files, or rather not. I also did test HC-04 BT Slave modules, but they don’t talk with Macs, which I found out after many futile tries.
This draft document describes the protocols, control lines and message formats.
The frame-work is working, next steps will be a little bit of fine tuning, adding the touch down sensor electronics. The modules are still Arduino based, but the Eagle drawings are already under progress.
I have spent a few days to sort out the Inverse Kinematics formulas. My mathematics skills have been much better in the old days. As I am using an AVR ATmega2560 I did the implementation in fixed point integers. As everyone knows float calculations are much too slow.
It took me days to get atan, acos and sqrt functions working. I need reasonable resolution (<1°) and reasonable sized lookup tables. But generally flash isn’t an issue, the ATmega2560 has 128 kByte of it.
For the automated testing, that I always implement, I did check my integer functions against their double precision counterparts. And as the AVR has timers, I also tracked the execution times. I was surprised.
|min / avg / max|
|min / avg / max
|sqrt||24 / 38 / 56||28 / 31 / 36
|acos||48 / 49 / 52||128 / 160 / 176
|atan||140 / 152 / 160||168 / 184 / 204
|inverse kinematics||544 / 559 / 580||829 / 926 / 976
Ok, double is slower than 16 bit integer. But, the overall difference is only 70%, but accuracy is much higher. The inverse kinematics results calculated with integers differ by 5° maximum, the double results are better than 0.1°. Writing the fixed point functions took about 4 days, the double version 30 minutes. The planning of accuracy and operand length for fixed point integer is a pain.
What do I take from this:
- Never optimize before I have the proof that I need to.
- Double isn’t as bad as I thought. And much much easier to handle.
- I’ll use double for the project. As I am planning to split the control to leg and body control to multiple processors, I should have enough resources to get a reasonable cycle time.
- If not, I can optimize later.
After some debugging here, cutting away code here and there, recovering from frustration, and some other magical moves, I found … a buffer-overflow of an itoa(). I love it. It did garble the stack, resulting in a restart loop. Pure magic, dark magic. I hoped for something honorable, like a compiler bug.
One of my favorite from http://natashenka.ca/posters/ seen at 30c3. There are more!
Microcontroller code is simple. No memory allocation, very few pointers, simple structure. Ok, there are interrupts, but they can be managed.
But why does it always end up in hunting strange bugs? A few weeks ago I started writing the code for a smooth linear motion. I thought that would be a good exercise for more complex motion code I’d begin with soon. Then I also wrote a test for this function. I am now always developing formal tests. The time you spend on the tests is much less then hunting the bugs in the production framework. For the microcontroller I am using AceUnit.
Now a few weeks passed by and I still didn’t get much further. The test produced garbled output and did restart in a never ending loop. Strange. Luckily, that happened with a rather simple test case. I did strip it down. The output did change unpredictably. I stripped it down further, and found a few bugs in the serial output code. I use the serial output for debugging, unfortunately the Arduino doesn’t support the standard connectors for an Atmel debug device. I fixed the code, not understanding why it could have lead to a restart loop, but in good hope. After restoring the test framework, I ran the test case again, and it still looped forever. At least the output looks nicer now. It is a Boojum, for sure.
By the way, ‘The Hunting of the Snark’ by Lewis Carroll is a wonderful poem, worth to read. With brilliant ideas, as you would expect from him. I have a reprint with the original steel engravings, like the one on the left.
I have been on a business trip for almost 2 weeks – Guadalajara, Orlando, Reston. Audits, audits, audits. It’s not relaxing and there isn’t much site-seeing, but meeting so many nice colleagues around the world gives me a huge push. You are aways welcome, get help and have a chance to peek inside the live in their countries. That’s very different to just an touristic holiday trip. And after you have met someone in person it is so much easier to communicate later on phone.
Installation in front of the Instituto Cultural Cabañas
I had a weekend to spend and decided to take the Saturday in Guadalajara and fly to Orlando on Sunday. A workmate showed me the town center and we did visit two museums, a historical and one with modern art. Great. Guadalajara is a nice and vivid town with plenty of public art. The Mexicans seem to love this. And the food, and the jugos, I love fresh juices.
Now most of the year’s travel is done, only a short trip to Bucharest left in October.
I took a few days off, to get a a little bit of something different before the up-comming stressful weeks.
After a nice party with old friends I had to face the fact that the week would not be as nice and sunny as I had hoped. What else to to than to work a little bit on my Walker robot.
The software can now reliably control the servos, next I am going to get motion and inverse kinematic in place. I have started to implement a linear motion in integer arithmetic. Tricky.
And I spent some time drawing the force sensor for the feet. I have stripped the design down to one force sensor just measuring the force in the direction of the Tibia. The sensor changes resistance from 10MΩ down to 1kΩ. I have to check the range I am interested in, but these values should be easy to interface with the Arduino.
The components are again made of acrylic glass. They are milled out of raw blocks. They fit into the tibia leg tube with an diameter of 15mm. The piston with the axle pushes onto the sensor mounted into the holding block. I am planning to use bouncy balls as feet. Let’s look if this works.
I’ll start this site because different people did ask me about details of some projects, pictures, …
And I am of course someone who would like to share my more or less finished projects. I think a blog might be a good way to do this.