I was testing Grove ultrasonic and DI distance sensors on my GoPiGo2 using the library easygopigo and noticed that the measurement time for two sensors was very different. For the ultrasonic sensor it’s 0.42 seconds and for the distance sensor - 0.16 seconds. When I switched to the older library gopigo and tested the ultrasonic sensor again, I’ve got 0.09 seconds. Since the DI distance sensor is not supported in gopigo, I don’t have results for it.
The measurement time is crucial for me because I need to perform 5 distance measurements within 1 second (ideally within 0.5 second) for my adaptive cruise control project. It needs to be compatible with both sensors and should be programmed with easygopigo on my GoPiGo2 because the code will be later transferred to GoPiGo3 using easygopigo3.
So I checked the code of easygopigo and looked into the class UltraSonicSensor and DistanceSensor. They both include 3 attempts of measurements to account for faulty measurements that occur from time to time. Moreover, each attempt in UltraSonicSensor has an extra delay of 0.05 second (line 509) while each attempt in DistanceSensor only 0.001 second (line 899). For the ultrasonic sensor this time adds up (0.09 + 0.05) * 3 = 0.42 and gives exactly the same measurement time as I reported previously.
Based on these observations I have the following questions/suggestions for both easygopigo and easygopigo3:
Would it be possible to adjust the delay time for each attempt in UltraSonicSensor to 0.001 second (just like in DistanceSensor)?
Would it be possible to decrease the number of attempts to 2 for both UltraSonicSensor and DistanceSensor? So far I have never seen the faulty measurement more than one time in a row.
Would it be possible for me to adjust the local copies of easygopigo and easygopigo3 on my SD card to bypass the above mentioned restrictions?
It seems like we added that extra delay of 50ms because there were conflicts when consecutive calls were made.
You can first try adjusting the delay and take it from 50 ms to 40 ms, 30 ms and so on until it no longer works - and when it starts having issues, then take it back up a step.
In order to do all these changes, you can go in /home/pi/Dexter/GoPiGo/Software/Python and then edit easygopigo file accordingly. After you do your modifications, just run sudo python setup.py install --force command (use python3 for Python3) and you’ll have the package updated system-wide.
Please let us know if your tests lead you on a better path. If so, we’ll make changes be in line with yours.
Thanks a lot for your reply! I have also noticed that a small delay helps with conflicts but 1 ms for an ultrasonic sensor should be enough (just like in the code for a distance sensor). I will test how 1 ms performs and let you know.
By the way, when I try to access the folder cd /home/pi in the terminal of JupyterLab (DexterOS 2.0), I get Permission denied. I tried sudo cd /home/pi instead, but the I have to enter password for jupyter. I have tried robots1234, raspberry, root, admin but nothing worked. Which password should I use to enter the folder pi?
I was running on the impression that you were on Raspbian For Robots. You could download the zip file for GoPiGo and copy over the micro SD Card with a USB key.
Be aware that you need to drop the use of sudo when installing the package. And you might also want to use the --force option with setup.py - that will help when you run the installation multiple times because it overwrites the old build.
easygopigo(3) are written for the average use case in order to simplify learning. You can totally go down a level in our libraries and use the distance_sensor.py library.
The easy_distance_sensor library inherits from it, so all those advanced methods are available to you. You can call read_range_single() method directly, entirely bypassing the multiple reads and delays introduced by easy_distance_sensor.