I have a simple course. I have calibrated and run the course multiple times with varied success. Most times it appears the script stops early. I am watching the values as the GoPiGo3 progresses through the course. But when it gets to he follow line until all wwwww, even though the output shows wbbbw, it still fails. Sometimes it runs it complete, but rarely.
My course background is whit paper, and the course is black electrical tape. When I calibrate, it shows wwwww for white, and bbbbb for black.
Please help, this is rather frustrating to hvae it intermittently fail so often. I have varied light intensities in the room too, but since the output is showing correctly, I am perplexed as to wy it will not run all the steps. is there a way to ‘step’ through in Bloxster?
I burned the 2.0.0 image, but how do I look at Dexter to see what version o/s is actually running?
I’ve used the LineFollower/LineReader before and there are a few quirks to it. The reflection from the tape can sometimes cause a sensor to read w when it should read b. On the opposite end, the shadow cast by the robot can occasionally cause w to read b. having a usb light the points down over the light sensor can help remove some of these problems. Additionally, the light sensor has some dependency on the voltage, so if things are getting weird, recharge your batteries and try again.
for the problems that just don’t go away there are solutions:
The two solutions I’ve used is to have it read 5 times and then “majority rules” for the final reading.
if you get a reading that is completely unexpected you can have the robot stop, and read again as this usually does not have the same the result ad have it act as normal once it gets a ‘normal’ reading.
I don’t think it is a read issue, because when I am looking at the changing output of what the sensor is picking up, it is reading correctly. It’s more like it just stops and fails to proceed to the next line of code.
Here is my script:
Sometimes it fails after it does it’s 90 degree to the left, sometimes it makes it all the way through to the 180. Nearly always fails after the 180, even though the output from the sensor is showing bbbbb (I have extended the width of the tape so it is wide enough to cover the entire sensor after the 180 and after it does it’s 180, Bloxter is showing it reading bbbbb.) It just fails to execute that last line follow step, if it ever gets there. I have gotten it to execute the entire script 1 time out of probably 100 tries. I did recharge battery, no help.
I also found that when in Bloxter, the sensor is being picked up by both IC2 port 1 and IC2 port 2. Why would it read output on both when I only have it plugged into one IC2 port? I am guessing it is IC2 port 1 I have it plugged into, but the board is not labeled. It is on the same side as the Servo 1 and Analog 1 so I am assuming it is IC2 port 1 as well.
I was just able to run the whole thing twice, then it failed five more times.
Does the line controller work better in Scratch? I was hoping to keep them in Bloxter, but I will not know how to explain why we can’t get it to run through the script in Bloxter to a reasonable number of successful attempts.
Just as a heads up, I’m not part of dex industries, just an enthusiast so take the next bits with a grain of salt and maybe a dex engineer can validate how right/wrong i am. I’m sorry I thought you were running this in python. I’m not sure my solutions are possible with blockster as I’m unfamiliar. As per your hardware detection: do you have something plugged into both IC2 ports? That would explain why it is reading from both. As it might be reading from both sensors even though your code asks for only one.
Thanks for the clarification, but honestly I will take any help I can get
Only one thing plugged into the IC2 port, the other one is blank.
Unfortunately, I am not a Python programmer but I have dabbled some in modifying pre-built code. I think I will try to run a few test scripts or two and try all this from Raspian for Robots. But for the class I am teaching, I think that is taking it too far and I am trying to keep it as simple as I can for them. A STEM camp for 8th grade girls. And I only have about 10 hours total with them, so I was trying to stay as simple as possible since they have no idea bout programming nor Linux.
@bakers
We’re hard at work trying to figure out why the behaviour in 2.0 is not what it should be.
As for the I2C ports both working with the line follower, it’s the nature of I2C that does that. It does not actually care with port the sensor is plugged in.
Just thought since you were nice enough to try and help me, I would give you an update. I received word from Dexter today that apparently they are having issues with the line follower in Dexter, and they are trying to figure it out. So apparently it is not an isolated incident just for me. Doesn’t help my situation, but at least I can move on and not keep thinking it is something I am doing wrong.
I would be interested in your development with Python and this robot. My plan is to move into using it to learn Python myself. Best advice where to start? I am totally new to Python, but I have dabbled a little in the past with javascript and vbscript. So I am hoping I will be able to get going fairly quickly.
Thanks again for your assistance with my line follower!
@bakers,
now I feel silly because after all this time, the issue I had - which I thought reproduced what you described - is actually my own black line being too thin. So yes, my robot would detect “all white” in the middle of the line to follow, but that’s because the line was actually falling between two sensors. Doh me.
What I can recommend for now is to try to run your own line but do NOT select the line follower in the control panel. Sometimes the two (the program and the control panel) can interfere with each other.
Would you be able to test this out and let me know if it fares any better?
@bakers
Can you share photos of your GPG? Especially the front with the line follower?
How much space would you estimate there is between the line follower and the actual line?
And photos of the course you’re trying to have the GPG run, please.
As for @jspagnol suggestion of reading the sensor a few times, it is already done for you by the block. We take three readings and average them out.
Also, I noticed this question just now: I burned the 2.0.0 image, but how do I look at Dexter to see what version o/s is actually running?
It is written at the top right of your browser window.
Yes, I have tried without selecting, and selecting both, and selecting one vs the other. Still same issue.
Incidentally, the last line I is the steps wide, and the out put shows wbbbw, and the line follower says to follow until all white, yet it still stops and doesn’t run it, even though the out put shows it is not all white
It is standard ¾” tape. But I have put down three strips (after the turn 90 left) to make the track wider and it still fails. I have included the script below. Every time it fails, the sensor is reading correctly.
Sometimes it fails after it does it’s 90 degree to the left, sometimes it makes it all the way through to the 180. Nearly always fails after the 180, even though the output from the sensor is showing bbbbb (I have extended the width of the tape so it is wide enough to cover the entire sensor after the 180 and after it does it’s 180, Bloxter is showing it reading bbbbb.) It just fails to execute that last line follow step, if it ever gets there. I have gotten it to execute the entire script 1 time out of probably 100 tries. I did recharge battery, no help.
Are you with Dexter? I am really concerned now that I am not going to be able to complete this project with my students because this is so erratic. I have been trying to get this fully functional for nearly two weeks. My project with them starts next week. I just noticed a new version of Bloxter, 2.1.0 and after installing it, it seems to be a little more stable. It is still not completing it 100% of the time, but it does seem to be working better. I was finally able to get it to complete the course to 100% for the first time. But again, subsequent runs of the same program resulted in failures somewhere along the code. But it is a marked difference from 2.0.0 – Did the code update to 2.1.0 address the line follower? If so tell the developers they are ALMOST there. Something however is still amiss.
One thing to note, the instructions on Dexter tell you to use the two acrylic spacers on the follower. (like the attached pic) Two goe on top of the board (they look like washers) and the other one goes on the bottom of the board (looks like a leading shield in front of the sensors.) When I assemble the pieces as instructed, it places the line follower too close to the floor and the screw heads wind up dragging. So I have to remove one or the other, (the washer or the shield) to make this work else it drags and does not work at all. I have double-checked the instructions and it is assembled correctly, but again it winds up dragging. But again, I don’t think that has anything to do with it because Bloxter is showing it picking up the correct values. The print output however is usually wrong, and inconsistent with what is showing in Bloxter under the IC2 sensor reading.
I am at my wits end, and can’t move on to the distance sensor because I can’t get it to work with the line follower.
@bakers,
my apologies, I had a small medical issue that needed attending.
What does the print statement return? Does it return “wwww” or not?
Also, how high is the distance sensor from the piece of paper? By your description of the assembly, it seems you used the information for the GoPiGo2. On the GoPiGo3, the round washers are going on top of the body acrylic as in the image below:
Turns out my flash to 2.1.0 fixed the issues. But it is good to know where the washers go, as I left them off completely because it put the follower too close to the floor.
For now I think I Good. Thank you and I hope you get back to 100% soon
