CTR turning problems

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.


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.

I already failed to keep up my promise…
(thank you though, I am yet to test the code now)

1 Like

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. :smiley:


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

Update: Turning works now! (kind of consistently) but does not pair with the drive straight code sadly
New image of Turn: