Hi, I am using the CTR drive straight code, (thank you to @EngineerMike and @SCFarrell for patiently explaining and troubleshooting the code) Since my last post, I have been trying to understand the concept of PID and have a pretty decent understanding of the code itself. But there is one problem that I could not solve, when we try to get the blue dispenser, no matter how little or how much we tell the robot to turn it always overshoots the dispenser, here is a picture for reference:
So, my initial suspicions are that you have something fundamentally wrong somewhere. That first parameter should be something closer to being in whole degrees, and yet youâve got it as a very small fractional value of 0.01, but say that itâs overshooting every time.
Can you post your code with the detail of GyroTurn? When you tell it to go 90 degrees, is it going left or right, and how close to 90 degrees is it (estimated)? These are all critical parts of data that need to be understood in order to help you start to find whatâs going wrong.
1 Like
Thank you for the response, when I tell the gyro to turn 90* (shown in screenshot1 ), it turns to the left, and it turns about 100* instead of 90* (give or take a few degrees), and I have tried values like 5, 10 15, 1 ,2 etc, and all turn almost the same amount,
Gyro turn 90*:
Gyro code itself:
So, the Momentum parameter is supposed to be the thing you use when you characterize how the robot drives. So in this case, if you have it turning 90 degrees, but it turns 100 degrees instead, make Momentum 10, which should make it stop closer to 90.
In this case, this is an example of a PD('ish) loop, where Momentum is acting as the D portion to stop things closer to where you want it to go.
Now, I do want to check in on this:
By this, do you mean no matter what you put in, itâs turning to 90-100 degrees every time?
1 Like
It is noteworthy that the GyroTurn myblock you have replicated (I havenât checked it for accuracy of that replication) is not PID. This code is turning at a constant specified velocity until it gets to the cutoff (desired angle minus momentum) and then it shuts off.
.
The faster you turn, the more it will swing after you turn.
If you have all omni wheels vs rubber tires, it will affect your accuracy.
The value of your leftmotor and rightmotor âstoppingâ will affect this.
This will get you a reasonably accurate turn. Experiment with the above variables and with various velocity & momentum values to see what works best for you.
You could even put back to back gyroturn blocks with the same end goal heading in mind to âreinforceâ your robot moving to the correct heading.
Very sorry for the delayed response, I read this and it was helpful, but when I increased the momentum to 10, the same effect kept happening, so I increased the momentum to 10, 15, 20 etc all to the same effect. And by this:
I mean to say that even when using regular numbers and not decimals, it overshoots. Here is a video of the overshooting turn code:
blob:chrome-untrusted://media-app/b27ddbfd-02f4-4317-8908-dd066c30982a (I do not know if the video will work for you, but hopefully it will, and I recommend watching it on no volume, because I like to whistle and It plays in the video )
Try decreasing your velocity, if that doesnât work, you can try individually moving the motors like this
Also I forgot to mention, you have to make the motor not wait for it to fully spin, so you have to click the arrow at the end of the block
I have tried both solutions before to no avail
Sorry to be so bothersome about this topic, but I figured that the turning was not an issue, and the drive straight was, so I decided to make my own drive straight code, and it said âerror while compiling codeâ. Please help me debug if you can.
Thank you in advance
looks like you lost a variable, see the grey âspeedâ in the middle of that image ?
When you get an error, perhaps read through all the code carefully before jumping on the forum.
5 Likes
Thank you so much @jpearman! I donât know how I missed that, and from now on I will try to read through the code more thoroughly. I was having another problem with the same code, where it would turn a little when the code is started and then move forward in little steps.
thank you
I have found the solution to the post above, but somehow another problem arose (Im not the best coder) , where when I use the CTR turn code, it does not work with my own drivestraight code. The problem is, that the drivestraight code works, but the turn code does not even activate. Please help if you can
Is your drive straight code resetting the motor encoders to zero at the start of the function? If not, youâre probably turning and generating something like 500 degrees of motor counts, and if you tell it to drive 400 degrees, the motor thinks itâs already where it needs to be.
Yes, it is, and here is the code for reference:
p.s. it says stop right motor, but below it there is a stop left motor code too, it got cut off in the screenshot
Compare those first two motor blocks before the âifâ block on yours very carefully to the CTR code. Thereâs a subtle error you have there, and itâs the key to whatâs causing your problems.
To be fair, this is also part of software development. A key piece of debugging is being able to check over your own code, or that of someone else to make sure that weâre not making any silly errors.
I like to relate to new coworkers of mine that are fresh out of college the story of where I thought I was going to get fired because I made an incredibly ridiculous error that took me a month to find. My boss was gracious and told me that itâs effectively a rite of passage of a software engineer to have those types of errors. Iâm sure other professional software folks have similar stories.
Long version of the story: I was adapting a bootloader that the company I worked for, from Atmel ATmega processors to a Texas Instruments DSP, and I had to completely rewrite the FLASH writing mechanism. This bootloader would take in a converted standard hex file input, write it to RAM until it hit a FLASH boundary (or the end of the load file), and work through the flashing process. Somewhere in there, inside of a for() loop, I had an stray i=0; that was triggering on a certain condition. That stray 4 characters caused the software to get partially through execution after bootloading, and then would reset (because the wrong data was being written to FLASH, or had invalid data that it was jumping to, and so the chip triggered a reset). It took me a month to find, and Iâd had three calls with TI support in India with them trying to troubleshoot the problem with me (thought there was a silicon problem).
I was finally at witâs end, and sat down to walk through the code with my boss; when I got to that line to try to describe what it was doing (she was acting as my debugging rubber duck), I still remember (almost 18 years later) that moment of dread realization of exactly what Iâd done. I regale this story on those kids fresh out of school just to let them know that theyâre going to screw up; the important thing is to screw it up when itâs in the lab, and not where it can hurt anyone. 
5 Likes
For some reason I cannot fathom, the gyro code will not ever stop turning and does not work with the go straight code. So basically it usually just spins forever, but it also does not even initiate when strung together with the drive straight code going before it
Turn code:
Go straight code:
thank you
