TIRDNKWIIT

Mine is rock steady now.

First; The Picaxe (running at 4 Mhz) had to do 8 servos, and the code for them. That is known to give hiccups that usually does not matter in steering etc - but every jitter matters when the stunt is balancing.

I knew this, but just throw it together, knowing that board so well. The servos just clip on, and so did the accmeter, 1 minute job. I was actually surprised how well it handled it, also with crap code, see video. But.. I would need total servo control.

 

So I am now using another board (AXE031) with a Picaxe 18 and a dedicated servo-controller by i2c.

That is first half of the fix: Someone to just give out steady pulses.

 

Second half is the code. I have read what you wrote, and this is hard to write in english for me, so please read twice or something.. :)

You know how every motion gives a kick-back motion? It goes for materials that bend, it goes for motors that continues after they should stop, it goes for joints on a robot that always will be loose, and it goes for the accmeter that first thinks things are one way, then gets a correction from the mechanics, and then thinks it is opposite..

All this means that if the code - even if it is at steady intervals - should never be able to jump a servo´s position from A to C to B.

 

What I did was to make "a second layer of variables", I call them "pointers":

A servos position is NEVER dictated from "the code", from the sensors, or from an algorithm. These things ONLY alters "the pointers", and always only with a step of 1 (one, uno).

AND

When ever a pointer is changed, it always happens only once in a cycle, and then the servo-controller is updated with the pointer's value.

 

Result is some sort of semi-average position of what the code & sensor dictates.

You could think this would slow down the response, but:

• If code dictates A, D, B.. What you really want is A, B, B, as the servo cannot move that fast.
• The pointer is changed every cycle, so if code dictates full throttle to one direction, the servos speed will be the bottleneck, not the pointer - it will move way faster than the servo.

 

---

Last, to really avoid "self-swing" (you know: Oh I am leaning forward, must correct, OMG, I am on my way to fall backwards, must correct even more, OOOHH I AM FALLING FORWARDS) - I "damp the code" all the time:

 

• Pointers only are allowed to change if matters get "worse" in respect to "where we are". This means that if we are tipping to the X-side, correction can only take place as long as we are tipping more to the X-side than in last cycle.
• If we are in fact tipping less, "half a bit" is even added in order to get back.
• "Sharp tipping over- edges" (Like "on this side of 150 do this, on that side, do that") are avoided, and replaced with Like "on this side of 140 do this, on that side of 160, do that".

*) "Half a bit": I take a bit, and adds it to the vaue. Then I add one to the bit; Every second time the bit is 0/1 :)

/ Fritsl