I am using these items to control a line following robot:
- Raspberry Pi 3 B V1.2
- Adafruit DC Stepper Motor Hat
- Two GrovePi IR Sensors whose outputs are wired directly to GPIO pins setup as inputs
(Volrage from IR Sensors divided down to 3.3V max).
- GrovePi v1.0
I have an if-then-else loop to monitor the input from the IR sensors via the GPIO’s and decide which motors should run to stay on the line. At this point the GrovePi is not attached.
The Robot works fine and follows curved lines and 90 degree turns at a decent speed. I have noted that its takes about 100 milliseconds to iterate through each loop.
However when I add a GrovePI board, even without sensors attached, the loop slows way down and now takes about 300 milliseconds to execute. This makes the robot reaction times very slow and requires slowing down the motor speed dramatically in order for the robot to follow a line.
I would like to get the robot working with the GrovePi in order to add additional sensors and functionality to the robot.
Any insight into why the GrovePi might be slowing down the Raspberry Pi and what do about it would be greatly appreciated.
@sully: can you share the code that you are using in your project. It might help us finding out what’s slowing down the program
Thanks for your quick reply and offer to help.
In my note above I said I saw additional delays by merely adding the GrovePi board. This issue appears to have gone away. This is good but I have not been able to reproduce it and determine were the hangup was. However I am able to consistently show that added sensor reads (in this case two Grove Ultrasonic Range Finders) using the GrovePi do add delays of about 400msec.
I am using a While loop with if statements to read the sensors and the IR line follower. One pass through the loop takes about 110msec if I don’t read the sensors. One pass though the loop takes about 520msec if I do read the sensors.
This additional delay makes my robot unable to follow a line.
Thanks for looking at this. I look forward to your feedback.
The code is at the link below:
2m2s2ur_dig_01_forpost.py (3.8 KB)
Most of the commands in the grovepi lib add 50ms+ delays, often 100ms. This is usually orders of magnitude too slow for anything realtime, so you’ll have to replace the firmware. The way reads and writes are implemented is that an i2c command is sent telling the atmega328p to read/write data from a specific pin; some modules have commands that do some calculation on the atmega end to get a useful result. The upshot is that due to the delays that the lib uses for i2c commands, you aren’t going to get realtime control.
It’s actually a lot slower than hooking up the RPi’s gpio pins directly, but i guess you get 5V support?
If there’s a faster way to read/write GPIOs that are brokered by the atmega (why is this even there, why not just connect the gpios directly?), I haven’t figured it out.
nimish, Thanks for your input. In fact I bypassed the GrovePI and wired our IR line follower sensor outputs to RPi GPIO’s (after dividing down to 3.3V) and was then able to follow a line at a decent speed. With the GrovePi, as we had it set up, we were’nt able to do that.
I’d really like to use the GrovePi for all our other planned sensors such as the Ultrasonic Range Finder etc…This would avoid custom building a board. I am exploring possible firmware mods.
@karan were you able to view my code posted in a link above? I’d be very interested to know if you see anything in this code that could be changed to reduce the large delay between reading sensor data through the GovePi on the RaspberyPi. Thanks.
@sully: Sorry for taking this long to reply back. Looks like the file upload on the site is not working properly right now. Can you try uploading a zip file or upload it somewhere else and send a link to it.
Sorry for troubles.
@sully: the file upload is working now. I just had a look at your code. The ultrasonic read has a 200ms delay built in here: https://github.com/DexterInd/GrovePi/blob/master/Software/Python/grovepi.py#L250. Can you slowly reduce that from 200ms by 50ms each time in the grovepi.py and try out this example to find out what’s the lowest delay that works for you .
I went ahead and ran the code snippet I sent you since my acid test was to get line following working. Sorry, I’ll try your code suggestion tomorrow since that will explicitly tell me if I am getting errors.
However, I was able to reduce the delay in the ultrasonicRead function to 30ms and still get consistent readings from two Ultrasonic sensors wired to the GrovePI attached to my RaspberrryPI. This reduced delay gave my robot enough time to also respond to feedback from two IR line follower sensors, monitored via GPIO pins on the RaspberyPi. The robot can now follow a line with motor speed set to about 60 rpm. In addition the bot will stop if an object comes within 10cm of its to front facing ultrasonic sensors.
This is great progress. Thanks.
So then I tried running the IR line follower sensors through the analog ports on the GrovePi. That worked almost as well as the above setup but I had to reduce the two 100msec delays in the analogRead function in grovepi.py to 10msec each.
So, again, this is good progress.
I would like to make this more robust since there is a possibility of needing the robot to go faster and/or respond to input from multiple sensors while following a line.
Do you think that there is any value in looking at the GrovePi firmware to improve this? Do you have any other suggestions?
Thanks for your help and great feed back.
@sully: Great to hear that it’s working for you. We are working on a firmware/software combination that would allow faster and more robust reads and would be releasing it in a bit. No ETA on this, but you should keep an eye on the forums. We’ll push it out to beta-testers first before pushing it out to general public.
It is possible to make changes in the firmware but it would be a bit more harder. I can point you to some resource which you would find helpful if you want to jump into updating the firmware.
Karan, Yes thanks for the help. The firmware/software combination you mention would be great. I’d like our bot to be able to move a bit more quickly. I’ll keep an eye out for the update.
As far as firmware, I’m still following up on the leads you provided earlier.