üApp: picar-s: smoothen the line-following steering

This task will attempt to smoothen the line-following steering of the picar-s. Changes will be made to the line-following python/C code in order to gain a smoother handling of corners.

Linked PRs:

Merges:

Related tasks:

Working on 2 ideas. Some combination of the both will yield good results.
Idea 1: Slowing down while turning
Idea 2: Smooth steering via incremental angle change

Both ideas exploit the tradeoff between overshoot and settling time

Marvellous! Thanks @Atharv

Hopefully the changes will be in file line_follower_clib.py only.
We have to see how we can quantify the improvements with logs that we can compare with logs that we already have from the code we have so far.
Is the existing score_line.py sufficient or we need something else?

score_line.py does the job.
Another approach is to convert 5 bit number to signed integer with range -16 to 15. The sign gives us the notion of direction of error ie right or left. (I can write a function to compute this if required)
Another concern is maybe if we had timestamp for each of the row in the log, there would be a huge potential for analysis of performance.
@raffromagno can share some thoughts on this

Time stamp printing can be added to the print statement in line_follower_clib.py as part of the improvements.

I have forked the repo and created a new branch. Modified code with reduced speed and smooth turning is implemented.
The print is modified to include the timestamp and formatted to match the current log format.
Let me know if you encounter any error

I think if we can add the time and just print the sensor measurements it can give us a lot of information. I would expect that, when the system is under attack the system will spend more time on a specific position, that would explain why Anton can’t see many difference between the number of corrections with and without attack. Then we may consider a time interval N and plot, at each time instant, the average value of the previous N sensor measurements. Converting 5 bit number to a signed integer may be a good idea to have a better visualization.

1 Like

The smooth turn function does not work.

There were syntax errors on line 70 and 71.
Here is the corrected version:
if (final_angle < current_angle):
sign = -1 * step
Even after fixing this, the code does not follow the line any more.
Commenting out smooth_turn() function shows that the problem is in there.
Need to figure out what is wrong in this function,

I found more issues in this function and this is what I have for the code, but it still does not help follow the line.
This function needs to be unit tested separately before we put it back in the script.
The situation with debugging embedded code is that the more you do before you put things together, the better.

def smooth_turn(final_angle, step=10, time_interval=0.001):
global current_angle
sign = 1 * step
if (final_angle < current_angle):
sign = -1 * step

    while (final_angle != current_angle):
            fw.wheel.write(current_angle)
            current_angle = current_angle + sign
            time.sleep(time_interval)

Noted. I will test the function thoroughly on my end.
Did the slowing down of the car help? Is there a visible change in the speed while turning?

I think the issue is when step is not equal to 1. The loop may never exit. Let me modify the function to accommodate it.

Yes, the loop never ends. I found that myself.
The slow down is seen, but I am not sure if it helps with the quality of line following that much, because we have the sharp turns.

There are more things to keep in mind:

  • A step of one makes no sense, because we will have 90 increments and 90 writes for just one call to this function. This increases the CPU usage and is completely not necessary.
  • The sleep between the steps has to be small, in the order of micro seconds, so that the overall smoothing is done with a millisecond or not more than 5 milliseconds, let’s say
  • The angle of 90 degrees is not necessary. I don’t think we need to do more than 45 degrees, since we don’t have 90 degrees turns. Even if we call the smoothing function we don’t need to reach 90 degrees, because this will overshoot.
  • Yes I agree increment of 1 step will increase cpu usage. We will need to tune step size and delay depending on performance.
  • I believe 90deg is for going in straight line. For turning, angle is 90 ± turning angle. I think even with the smoothing function, we will never go beyond 45 deg for Turing

ok, I tried to check in an initial wotking version to the forked repository, but it was rejected for permissions issues.
! [remote rejected] smoothtest -> smoothtest (permission denied)
error: failed to push some refs to ‘https://github.com/athens2000/uapp-SunFounder_PiCar-S

can you share your GitHub username

My github username is : antonhristozov

The file is checked in.

1 Like