üApp: picar-s: Control Algorithms for Line Follower

This thread keeps track on current progress on the control theory and its Uber-objects friendly implementations

PR(s):

Merge(s):

Preliminary implementation of PID controller with a shared library.

3 posts were split to a new topic: Adding new sensors

Thanks for this effort @atharv!

When this is ready, could you submit a PR on: https://github.com/uberspark/uapp-SunFounder_PiCar-S.git on branch uobjcoll so we can review and merge?

Submitted a pull request.

Hey @Atharv,

A couple of questions:

  1. Does the PR add the control algorithm as a separate functionality? i.e., we can still execute the existing line-folllowing algorithm but can switch to this new one?

  2. Is there some documentation to be able to use this new control algorithm and the steps one would need to take to start using this for the picar-s line-following functionality? e.g., a README of some form.

Thanks for your contribution!

  1. Yes. it is a standalone functionality. It is upto the user whether to include it or not. The vanilla line follower can still be executed without any issues if the shared library is not used.
  2. I will create a README and commit it right away
1 Like

A post was merged into an existing topic: Adding new sensors

Linked PR to OP.

@antonhristozov: can you give this new PID controller a test on your testbed using the PR? Please try following the README and feel free to post any questions/clarifications you may have for @Atharv on this thread. I can merge once you confirm a successful test.

Thanks!

I assume that this is part of the following branch:
https://github.com/uberspark/uapp-SunFounder_PiCar-S.git on branch uobjcoll
Need to get to it and test it.

No, you will need to grab it from the PR linked in the OP on this thread. I am listing it below again for your reference:

See: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally on how to check-out PRs locally so you can test them.

Thanks!

So this is not merged yet. I see.

I got the code and the first thing I noticed is that it does not compile on the Raspberry Pi.
We have to keep in mind that compilers on Linux and Raspbian may differ:

gcc pid.c -o pid.so -fPIC -shared
pid.c: In function ‘pid_compute_error’:
pid.c:42:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int idx=0; idx < size; idx++) {
^
pid.c:42:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
Makefile:14: recipe for target ‘all’ failed
make: *** [all] Error 1

Changing the code to the following fixes the compilation problem on the Pi.

int idx;
for (idx=0; idx < size; idx++) {

pi@raspberrypi:~/test/uapp-SunFounder_PiCar-S/example/pid_shared $ make
gcc pid.c -o pid.so -fPIC -shared
pi@raspberrypi:~/test/uapp-SunFounder_PiCar-S/example/pid_shared $ ls -l *.so
-rwxr-xr-x 1 pi pi 6932 Apr 22 15:22 pid.so

This post for getting pull requests locally was more helpful for me:

1 Like

Thanks @antonhristozov!

@Atharv: Can you give @antonhristozov permissions to your branch so he can push his changesets as he is walking through the process of testing this controller?

I had to move the .so file and pid_line_follower.py to the folder above so that I can start it.
By the way the README should contain this information, but it focuses on the functions in the library only.
Maybe another section of how to use it is going to be good.
Ran the script, but the car did not follow the line.
Is there something that I am missing ?

Hi Anton,

  • I have given you the access to push to my repo.
  • I use off the shelf latest rasbian on my raspberry pi. But I understand the differences and confusion posed by C99 and C11. I will update my Makefile to explicitly define the version.
  • The ‘Installation’ section in README says to copy the .so file to working directly. Nevertheless I will mention to put it in the examples folder to make to more clear.
  • Let me know if you come across any more issues. I would be happy to resolve them as early as possible.

Better to change the declaration to be outside of the loop, so that it does not depend on the compiler.