e-puck2 / e-puck2_main-processor

e-puck2 STM32F407 firmware
6 stars 4 forks source link

motor.c : Manage the absolute min value of speed and explain the limit of speed change period in order to obtain an correct effect #2

Open nathmo opened 4 months ago

nathmo commented 4 months ago

Hi, I spent some time scratching my head on why the robot was not moving, even tho I kept calling left/right_motor_set_speed(vitesse) in my main loop. I'm not sure if the comment on line 314 meant that the problem was supposedly fixed or if it's known, but it seems that the problem is still present. My workaround was to call X_motor_set_speed(vitesse) only if there is a change from the previous state.

I would suggest doing the same inside left_motor_set_speed(vitesse) and right_motor_set_speed(vitesse) unless the root cause can be addressed, as I couldn't find anything about this issue in the documentation

void motor_set_speed(struct stepper_motor_s *m, int speed)
{
[...]
    uint16_t interval;
    if (speed == 0) {
        m->direction = HALT;
        //Resolves a problem when the motors take about 650ms to restart
[...]
nathmo commented 3 months ago

@dburnier ?

dburnier commented 3 months ago

Hi,

It is not necessary to do this in higher level routines (left_motor_set_speed and right_motor_set_speed) because they call precisely motor_set_speed(motor_selected, speed) doing the job.

I will test your code which was problematic, I think of the commit cbb0e6db29ed2a21229a2e129bf1d1e260727711 and I come back to tell you.

nathmo commented 3 months ago

I did it there to make the code clearer as I believe that adding logic to select the correct right / left speed inside the function motor_set_speed would make it more complex and be less readable. Feel free to modify this as you see fit

nathmo commented 3 months ago

If I recall correctly, you should be able to trigger the issue by just having a while(true) loop in the main where you constantly set the speed of the robot to go forward.

dburnier commented 3 months ago

So I confirm that your problem was that you were initializing the motors in the wrong places: In fact the motors_init function should only be called once in the main because it resets all timer management for you and prepare the control. You then only need to use the other functions of motor.h

Just comment the 3 motors_init in your movement.c and the robot will move.

For the rest of the code, I was not able to validate correctly the fire detection but that's not the problem here.

And for sure the frequency call of speed command need to respect some limit, essentially linked with the speed value:

In order that the timer interrupt is able to trig the speed change must not be applied faster than this period an perhaps with a factor. That actual motor driver limit only the max absolute speed value but not the min one. With a speed of 100 [steps/s], the timer period is equal to 5 [ms]. With a speed of 10 [steps/s], this period will be 50 [ms]. In any case, change of speed faster than half step period, linked with the last speed value, the risk is to have no pulse at all. Then you see well that speed values could produce some side effect and that's why I will comment the motor driver soon and add a limit on the absolute min value too.

And just to understand the famous comment in motor.c

//Resolves a problem when the motors take about 650ms to restart
interval = 1000;    //so the motors get updated at 100Hz when not used

the timer is set at 10 [ms] or 100 [Hz] when the motor is stopped in order to react faster (max 10 [ms]) for a new not null speed.

I hope that answers your questions and I close the ticket.

dburnier commented 3 months ago

Must correct motor driver in order to limit max and min absolute speed value and comment the usage in order to limit the change of speed consign in accordance with the min limit, but mostly the last speed value.