Increased loop time

[laurensvalk]

Increased loop time

[laurensvalk]

Hey @mbraeunlein, thanks for trying out the code!

The algorithm implemented in Python is actually much simpler than the old EV3-G program, which still contains some superfluous code. I still mean to update the EV3-G program to make it consistent with the simpler Python code, but since it's working well in its current state, this hasn't had a high priority.

What kind of computations are you doing to find speed and steering? Computations in the loop should generally be fine, but I have found that some hardware (like a bluetooth remote control) can seriously affect performance. Although the average loop time may seem alright, this led to some loops taking much longer than others because it was busy handling bluetooth.

Either way, the new Python program is meant to work at least as smooth as the EV3-G version (Here's one video running the Python code) and going towards 20 ms should be no problem. Making it more smoothly generally amounts to adapting these values:

gainGyroAngle                  =   # For every radian (57 degrees) we lean forward,            apply this amount of duty cycle.
gainGyroRate                   =   # For every radian/s we fall forward,                       apply this amount of duty cycle.
gainMotorAngle                 =   # For every radian we are ahead of the reference,           apply this amount of duty cycle
gainMotorAngularSpeed          =   # For every radian/s drive faster than the reference value, apply this amount of duty cycle
gainMotorAngleErrorAccumulated =   # For every radian x s of accumulated motor angle,          apply this amount of duty cycle

This can be a bit tricky (but fun as you start to get the hang of it). Basically, increasing one number increases the sensitivity to that sensor value. So increasing gainGyroAngle makes it respond to a nonzero body angle with greater motor voltage. But increase it too much and it will try to over-compensate and become unstable. To get started, set the gains related to the motor angle to 0 and see how the robot responds to angular rate or angle, for example.

I'm not sure what the best way would be to make certain values work for everybody. Somehow, the EV3-G version seems to work for most people without adapting any values, so I'm not sure what is causing the inconsistencies with ev3dev/Python.

[mbraeunlein]

Hi @laurensvalk,

thank you for your fast response.

The robot in the video looks really stable, that is about what i imagined to achieve. I use slightly taller wheels (62mm diameter) and mounted two color sensors at the bottom to be able to detect in which direction i cross a border. There is no bluetooth or fancy stuff involved, just the two sensor reads for which i also used the FastRead function and some if's.

As you mentioned here, your loop takes about 6ms. I measured the time right before the program sleeps for the rest of the loop using
...
print time.clock() - tLoopStart
while(time.clock() - tLoopStart < loopTimeSec):
...
and get values of 8-10ms with your code copy pasted and the robot is kind of shivering.

I was trying to get a feel for the parameters for the last weekend straight but did not get the robot to balance as stable as in your video.

With the EV3-G program i did not have any issues even if i did not adjust the wheel parameter. I also can not imagine what those differences come from so my guess was the PID controler. Why is it superfluous in your opinion?

Best,
Michael

[laurensvalk]

I also can not imagine what those differences come from so my guess was the PID controler. Why is it superfluous in your opinion?

The old code was based on literature I found elsewhere, as referenced on the tutorial page. Since then, I studied control theory, and I found that the PID term was not necessary at all to achieve stabilization.

In the newer code, proportional control (P) is achieved with feedback on body angle and wheel angle. Damping (D) is now achieved by feedback to angular rate of body and the motors, while integral action (I) is achieved using the accumulated motor term angle.

Overal, there are now just 5 control terms, rather than 12 (four signals, each with three PID terms). Some of these 12 were partially overlapping or achieving an opposite effect. For example, derivative control on the body angle is the same as proportional control on the body angular rate.

That doesn't do too much harm and computation time is not so much longer, but it makes tuning even less insightful than having just 5 parameters.

[mbraeunlein]

Yes makes sense. Since you are not able to confirm that the robot is falling over when the loop time is set to 20 on your hardware i will close this issue.