MOVE command limitations

[davidalecmcinnes]

I had the idea of using Genetic Algorithms to improve Robonova's walking gait using feedback from a gyro and accelerometer but I find the MOVE command is restricted in that it can only accept numbers and not variables.

i.e. MOVE G6A, n, 76, 145, 93, 100, 145

will not compile.

Has anyone found a way around this issue, perhaps there's a compiler update that's a bit more flexible?

[i-Bot]

This is not a limitation of the compiler. The byte code interpreter in The C3024 will only take literals, not variables.

The servo command does take variables, but you need to manage the speed and PTP settings.

What timeframe are you looking to modify the gait. I have succesfully written self modifying code, so the literals in the move are changed, but it is complex (absolute memory locations) and slow due to the EEPROM writes.

I have some limited success in disabling the gyros, and injecting varaibles to modify a move. Again very complex.

You may have to go to use C or assembler to do what you want.

[Gort]

I have a question? When does the RN get feedback from the Gyro? All the time or only when it is in the main section of the program. Or should the question be when does the Rn act on feedback from the Gyro?

[Ray]

I have a question? When does the RN get feedback from the Gyro? All the time or only when it is in the main section of the program. Or should the question be when does the Rn act on feedback from the Gyro?

from Digital Control theory,

if Hitec using a common method, then,
The CPU regularly sample the Gyro outputs then it will multiply the output with the Gyro gain and added to the PWM output of the servo.

I had the idea of using Genetic Algorithms to improve Robonova's walking gait using feedback from a gyro and accelerometer but I find the MOVE command is restricted in that it can only accept numbers and not variables.

Its a great idea, but I worry whether the Atmel micro can do the huge amount of computation of the algorithm, well, may be you can use external PC to help. but the sampling rate is still a problem?

[Gort]

So is the RN not already improving its walking gait based on input from the gyro? Should you not be able to improve its walking gait by increasing gyro sensitivity and gyro gain on the gyro itself?

Are you trying to improve its walking ability on an uneven surface?

[i-Bot]

The motion engine in the C3024 is driven from an interrupt about every 4 ms. Servo positions are updated using the position, speed, PTP etc in 3 phases (servo 0 to 11, 12 to 23, 24 to 31).

If you do a GYROSET command to enable a Gyro, then a fourth phase is added. It is during this phase the 4 possible Gyros are read. So the gryos are read every 16ms while they are enabled. You can see the raw Gyro outputs by peeking locations &H530 to &H533.

During the 3 servo update phases after the new position for the servos has been caclulated the Gyro raw output values are used to modify this servo position.

The code is quite complex, but the GYROSET value determines if a servo position is modified, and the GYRODIR the direction. The Gyro sense appears to change the time constant of an integrator which determines how fast a change in gyro output impacts the position. So it seems that the tuning of the two pots on the Gyro and the sensitivity value are important.

It seems most uses are restricted to where the same values are used for both legs, to try to influence the balance rather than the gait.

[Ray]

So is the RN not already improving its walking gait based on input from the gyro? Should you not be able to improve its walking gait by increasing gyro sensitivity and gyro gain on the gyro itself?

so, from the internal mechanism of the computation, the compensation is directly (heavily) depends on the Gyro itself.
All we have to do is just to adjust the direct gain, direction and slope (sensitivity). ( It may be a simple proportional gain .... )

In this case,
In order to actually compensate the Mechanical system, the job should finally back to the Gyro. However, the Gyro is simply designed for helicopter, it cannot be expected that it is tailored for RN.

So, that why there comes people thinking other algorithms to fit the Robot.

To solve this problem, I think the RN programming level cannot be done.
It should go to the micro-controller assembly level.
(fast!, you knowl, you should calculate the compensation as well as running the background routine then update the output at 16ms !)

So, the solution is fast enough to calculate a more complex algorithm. e.g. PID controller or fuzzy controller. The present controller may not be possible.

[Gort]

Can you not tailor the gyros to the RN by the GYRODIR and GYROSET commends. The GYODIR sets the direction of the gyro. The GYROSET assigns a servo to a servo.

Yes I think that the controller is too slow and RoboBasic is also too limited.

[davidalecmcinnes]

Thanks for the information chaps. I guess I will just use the gyro to stabilise the walking and the accelerometer to pick himself up when he falls over an ant, and just focus on the autonomus roaming and avoidance for Robonova 1. I think you're right about the C3024, it's not really powerful and is badly handicapped by the Robobasic; shame they didn't do a more powerful development environment for it. I will have to design a new microcontroller for the little guy if I am going to do some real number crunching, one of those new high speed 32 bit CISCs perhaps with isolated servo handling. Ooh that's got me thinking

[DirtyRoboto]

*not a flame, sorry*
Please dont go on about the RN1 limitations and just remember that because of ppl like Hitec, people like you and me can afford cutting edge kit like the RN1.

When you see other robots at Robo-One ect, you must remember that they builders may have spent many thousands of £/$/yen on that one bot.

If you want to spend about £3000 - £10,000 then you can basicly build it how you want. If you are spending under £1000 then you willl be gitting the very basic kit. The RN1 is in this basic kit area.

[davidalecmcinnes]

We are all pushing on the boundaries of the platform and seeking techniques in overcoming the limitations and problems of the basic model hence the discussions in these forums. But you have a point, it is a great platform which draws intense interest from anyone who sees it and without which I would still have lego bots running around the lab instead so pass the humble pie

[i-Bot]

Good news and bad news on my quest to input variables dynamically during moves.

I have found it is possible to enable the gyro code, but disable the actual gyros. This means that the variables can be poked in place of the Gyro inputs. The gyro direction and sensitivity (slope) still work. So I can now change the gait dynamically using PS2 wireless remote control.

The bad news and why this took so long is that the C3024 code for POKE is broken and I use this to put the variable in. The POKE command works fine for constants, but not for variables, since they forgot to save a register before a call. I do have a patched C3024 version to fix this, but that rather spoils my intention to do this without modifying the flash.

Still works for me, and I can share patched code for anyone else.

[tminionman]

how do you disable the physical gyros as you described? I've installed your flashed code (which speeds up my control loop nicely, thank you).

[i-Bot]

To allow the gyro value to be poked, the gyros are set up as usual:
GYROSET G6A,1,2,0,0,0,0

Here the first servo will be modified by the gyro 1 value, and the second servo by the gyro 2 value

Gyro 1 value will be from &H530, Gyro 2 value will be from &H531

GYRODIR and GYROSENSE work as usual

The GYROSET will have also stared the gyros to up update the gyro values. We need to disable this. So we :
POKE &H52F,&H21
This must be done after the GYROSET.
What this does is to have at least one gyro enabled, so the servos are updated, but the Gyro type is invalid, so no updates are performed.

You can now POKE into &H530 and &H531 to modify the servos. The maximum range is about +/- 11 degrees. I find about 5 degrees is the range to stabilise.

[i-Bot]

I forgot to add the values to be poked into the Gyro values are centered around 44 decimal (&H2C), So -11 is 33 decimal, and +11 is 55 decimal.