So I found a bug in the gyro. When used directly with bluetooth, the gyro develops a drift, especially when it is accessed frequently by the program. I assume that something in the way it continually reports the angle over the bluetooth to the EV3 program is causing the problem. When I downloaded the program and disconnecting bluetooth, I found that the robot could run within a one inch circle accuracy over 96" with the gyro. From my point of view, that is sufficient to run most of the missions.
This concept works best of any drive straight algorithm I've tried. 2 things I really like: (1) The motors will automatically compensate for the robot pulling left or right due to the weight of larger attachments. (2) The simple MoveSteering control automatically handles any weird math exceptions that pop up around 0 or 100 power when using MoveTank, especially within acceleration/deceleration modules.
Very clean solution for a bot with low centre of gravity to hill climb accurately , thnx look forward to getting my copy of the book uk side, Amazon uk now got it on pre order
You're a wizard. We use a gyro for our "GoStraight" MyBlock and still get minor drift (.5cm for every 1m). When we drive across the board, we can end up off quite a bit.
Great video! I have one question, though: Ho do i make the loop so that it will go for a certain amount of rotations? I know how paremeters work, so that is not the problem. currently, I have two measure rotation blocks connected to two compare blocks(they say greater than or equal to), then the outcome is put in a logic operations "and" block, which is then put to the end of the loop, which is set to logic until true.
If one had to choose between the EV3 Motor Encoder program shown in this video, and your previous video about "Gyro Following", I would use the Gyro for long-distance straight-line travelling. During last season, our FLL team had a heck of a time handling the irregular roughness of the FLL Game Mat just east of the "Base" area, and handling the underlying defects of our plywood table. When we implemented a variant of the Gyro Following (Gyro feedback) program shown in your previous video, it didn't matter if one of the robot wheels encountered different friction values on the mat or table -- it would correct itself and maintain it's straight "Heading". I know that the EV3 Gyro is only accurate to plus-or-minus 2 degrees (at best), but that inaccuracy could be less than the EV3 Large Motor's internal gear lash (what you call "Slop"). Do you agree?
Nice vid. Perhaps fixed in the latest firmware (but maybe you could experiment for me...) but the two motor RESETs tend to take a long time. Long meaning a few milliseconds each. So that if you use code like you show above, but place in a myBlock...then string many together with varying speeds/distances/etc....and just leave the motors running - the time it takes to do the two motor resets - can actually throw the bot off course for a tiny amount between each run of the myBlock. There are ways around that, but hopefully the motor resets have been improved and introduce no noticeable delay.
Yes, it does. But this doesn't always work perfect in practice, especially when the motors are under unequal load (see my NXT Grunt video to see what I mean; I use this block there, too).
Really nice and neat video man! I just have a quick question. How would I apply this program into a "myblock" ? Because I would want to use this in my programs. So I would want to make a myblock out of this so that I can change the robot degrees movement? How would I make that?
We have used the concept this program for over two years now, but this year it started giving us issues. The robot slows down, and speeds up repeatedly, as if the processing of the brick is overloaded. Anyone else have these issues? Any solution to it?
Could you give program example of moving backwards using encoders? I wrote program for moving backwards and it works but it doens't meet end condition and it goes backwards infinitely.
When I use motor rotations as the loop exit case, the robot moves a little bit to the left after it is done moving straight. Do you know how to fix it? (I used B for loop exit case, which is my left wheel, greater than or equal to for the compare type, and 1 rotation.)
Make sure you have some block (placed immediately after the loop) that stops both motors together (make sure that your motor blocks are not set to "coast at end")
Hi kyle, how about turning to a specific angle using only motor rotations and with pid control, without using gyro? Any idea? I saw your video about calculating the circumference etc but is it possible to use those data to make a pid controller for turning?
I think it's possible. In a recent video, I showcased an Excel spreadsheet that you can use to calculate turns (ruclips.net/video/0XBvdZjdCpk/видео.html). I think that if you take the equation from a spreadsheet and used it in a program to calculate a target turning path, then use the PID to keep it on that path, you will have what you are looking for.
Question (challenge perhaps). What would happen to this routine if one of the Read Rotation Sensor blocks got back a falsely higher/lower number than was actually in the motor. What if an aspiring programmer, actually "built in" such a mathematical "fib" to skew those results. How would the bot behave?
There shouldn't be any gap between encoder measurements and actual rotation; if you do, then you probably have a bigger problem. Anyway, If one were to manually add in an operation to skew the encoder values as they are put into the function, the robot will always turn away from whichever wheel it thinks has turned less. So, you will drive in a circle. The bigger the difference between the encoders, the tighter the circle will be.
Correct, I was not hinting towards a gap in the encoder process. I was talking about as a programmer, how could one manipulate the math to make the robot do something different (but useful) than drive a straight line. And the smaller the difference (or the induced fib) that "circle" would actually be an arc. A controlled arc. An arc can often times be more efficient and accurate than a straight and turn. Arcs can also support acceleration/deaccel, again with some math thrown into the loop you have going. Have fun, I hope you will take these ideas and run with them.
Yes, but if you wanted to use this in the middle of a program, you'd start having problems. It's always best to include the reset just in case you want to move it somewhere else.
@@Builderdude35 how can I set the program to drive straight for a specific number of rotations? I've been trying for days and I didn't find a solution that works properly.
No, if the motors move the robot in reverse with positive power, the only thing that is affected is direction. You won't have to flip the turning in this case.
Sorry i know im late but my robot is not driving straight but it keeps leaning on the right side and i tried many different value but the robot still lean on the right side. It cant go straight. Builderdude35 can you please please help me
Our team is so appreciative of your videos! Thanks for making them! Quick Question- how would you combine this program to make the robot drive straight with the program to ramp up and down?
That's going to be kind of complicated. But, you can add the programming for the drive straight into the loop after the acceleration bit. Think of it this way; acceleration sets the initial speed, then the drive straight program makes some adjustments.
Good info but this will not work if either of the wheels comes off the ground, it wont know to slow or stop the other wheel, since it does not measure load/torque.
So I ran the program, and it does make my robot go straighter, and saved it as a portable program, but I am not sure how I would add it to a regular FLL program. Can anyone help?
I tried this and I tried the gyro method. In the end, I got best results using the standard steering with a small offset (
Thanks for sharing!
So I found a bug in the gyro. When used directly with bluetooth, the gyro develops a drift, especially when it is accessed frequently by the program. I assume that something in the way it continually reports the angle over the bluetooth to the EV3 program is causing the problem. When I downloaded the program and disconnecting bluetooth, I found that the robot could run within a one inch circle accuracy over 96" with the gyro. From my point of view, that is sufficient to run most of the missions.
This concept works best of any drive straight algorithm I've tried. 2 things I really like:
(1) The motors will automatically compensate for the robot pulling left or right due to the weight of larger attachments.
(2) The simple MoveSteering control automatically handles any weird math exceptions that pop up around 0 or 100 power when using MoveTank, especially within acceleration/deceleration modules.
Thank you; I am glad that you are pleased with the performance!
Very clean solution for a bot with low centre of gravity to hill climb accurately
, thnx look forward to getting my copy of the book uk side, Amazon uk now got it on pre order
Awesome, thank you!
Thank you for helping us get to sectionals in FLL! The tutorials are amazing!
I;m glad to hear I've helped!
Thanks
You're a wizard. We use a gyro for our "GoStraight" MyBlock and still get minor drift (.5cm for every 1m). When we drive across the board, we can end up off quite a bit.
Have you seen this video: ruclips.net/video/7V16AEW3GG4/видео.html&lc=UgwiDmlgURZMoMv49zR4AaABAg I think it may help you.
Great video! I have one question, though: Ho do i make the loop so that it will go for a certain amount of rotations? I know how paremeters work, so that is not the problem. currently, I have two measure rotation blocks connected to two compare blocks(they say greater than or equal to), then the outcome is put in a logic operations "and" block, which is then put to the end of the loop, which is set to logic until true.
This is a great video for going straight. Seems similar to another website called PSI robotics. But great video and I got the answers I needed.
If one had to choose between the EV3 Motor Encoder program shown in this video, and your previous video about "Gyro Following", I would use the Gyro for long-distance straight-line travelling. During last season, our FLL team had a heck of a time handling the irregular roughness of the FLL Game Mat just east of the "Base" area, and handling the underlying defects of our plywood table. When we implemented a variant of the Gyro Following (Gyro feedback) program shown in your previous video, it didn't matter if one of the robot wheels encountered different friction values on the mat or table -- it would correct itself and maintain it's straight "Heading". I know that the EV3 Gyro is only accurate to plus-or-minus 2 degrees (at best), but that inaccuracy could be less than the EV3 Large Motor's internal gear lash (what you call "Slop"). Do you agree?
I agree with what you've said; you've brought up a great point!
a lot of the time my FLL team it tilts so this is really helpful!
I meant in my FLL team
Is Gyro more accurate than this program in going straight? What if one side of robot is heavier than other?
Would you need this program if you have a gyro on board?
cant we use pid for this setup?
I mean, for a robot without gyro.
thx! this really helps! cause our robot was driving crooked.
Awesome! I'm glad it helped!
Nice vid. Perhaps fixed in the latest firmware (but maybe you could experiment for me...) but the two motor RESETs tend to take a long time. Long meaning a few milliseconds each. So that if you use code like you show above, but place in a myBlock...then string many together with varying speeds/distances/etc....and just leave the motors running - the time it takes to do the two motor resets - can actually throw the bot off course for a tiny amount between each run of the myBlock. There are ways around that, but hopefully the motor resets have been improved and introduce no noticeable delay.
Thanks for sharing this, I was unaware that the resets took so long.
The normal move block does already have a PID controller for rotating the motors on the same speed, doesn't it?
Yes, it does. But this doesn't always work perfect in practice, especially when the motors are under unequal load (see my NXT Grunt video to see what I mean; I use this block there, too).
Really nice and neat video man! I just have a quick question. How would I apply this program into a "myblock" ? Because I would want to use this in my programs. So I would want to make a myblock out of this so that I can change the robot degrees movement? How would I make that?
I have two videos on MyBlocks; I suggest watching those, they will likely answer your questions.
We have used the concept this program for over two years now, but this year it started giving us issues. The robot slows down, and speeds up repeatedly, as if the processing of the brick is overloaded. Anyone else have these issues? Any solution to it?
Could you give program example of moving backwards using encoders? I wrote program for moving backwards and it works but it doens't meet end condition and it goes backwards infinitely.
What is your end condition? Maybe you forgot to set the end condition to a negative number of degrees (because you are driving in reverse).
I solved it in the meantime. It was about end condition. Thank you
Great! I'm glad to hear that you resolved the issue.
When I use motor rotations as the loop exit case, the robot moves a little bit to the left after it is done moving straight. Do you know how to fix it? (I used B for loop exit case, which is my left wheel, greater than or equal to for the compare type, and 1 rotation.)
Make sure you have some block (placed immediately after the loop) that stops both motors together (make sure that your motor blocks are not set to "coast at end")
Hi kyle, how about turning to a specific angle using only motor rotations and with pid control, without using gyro? Any idea? I saw your video about calculating the circumference etc but is it possible to use those data to make a pid controller for turning?
I think it's possible. In a recent video, I showcased an Excel spreadsheet that you can use to calculate turns (ruclips.net/video/0XBvdZjdCpk/видео.html). I think that if you take the equation from a spreadsheet and used it in a program to calculate a target turning path, then use the PID to keep it on that path, you will have what you are looking for.
Question (challenge perhaps). What would happen to this routine if one of the Read Rotation Sensor blocks got back a falsely higher/lower number than was actually in the motor. What if an aspiring programmer, actually "built in" such a mathematical "fib" to skew those results. How would the bot behave?
There shouldn't be any gap between encoder measurements and actual rotation; if you do, then you probably have a bigger problem. Anyway, If one were to manually add in an operation to skew the encoder values as they are put into the function, the robot will always turn away from whichever wheel it thinks has turned less. So, you will drive in a circle. The bigger the difference between the encoders, the tighter the circle will be.
Correct, I was not hinting towards a gap in the encoder process. I was talking about as a programmer, how could one manipulate the math to make the robot do something different (but useful) than drive a straight line. And the smaller the difference (or the induced fib) that "circle" would actually be an arc. A controlled arc. An arc can often times be more efficient and accurate than a straight and turn. Arcs can also support acceleration/deaccel, again with some math thrown into the loop you have going. Have fun, I hope you will take these ideas and run with them.
Very helpful
Thanks alot!!!
You're welcome!
When we run the robot, it turns very quickly to the desired angle. Is there any way to slow down the rate of turn? Thanks so much for your videos!!!
Changing your proportional constant to a smaller number should help (that's the number you multiply by to adjust corrections).
5:30 doesn't it already have the reset blocks at the beginning of the program?
Yes, but if you wanted to use this in the middle of a program, you'd start having problems. It's always best to include the reset just in case you want to move it somewhere else.
thanks!
If I take out the loop and change the "on" in the move steering block to on for rotations and put a value in that parameter, will the code still work?
The code will be very choppy. It will only check the difference after that number of rotations has passed. So no, it won't work very well.
thank you for your help
@@Builderdude35 how can I set the program to drive straight for a specific number of rotations? I've been trying for days and I didn't find a solution that works properly.
@@omarkhalaf7014 I aggree. It is very hard. I tried to use the motor encoders to sense once the rotations happened, but it did not work
Can i get help, my robot veers to one side when i use this code, especially after gyro turns.
hi, the robot seems to slow down. any idea why?
What if the motors are supposed to move backwards? Do we switch the input for the subtract math block?
No, if the motors move the robot in reverse with positive power, the only thing that is affected is direction. You won't have to flip the turning in this case.
thank you but how would i use it in wro junior high 2017
Sorry i know im late but my robot is not driving straight but it keeps leaning on the right side and i tried many different value but the robot still lean on the right side. It cant go straight. Builderdude35 can you please please help me
I would make sure that both drive motors are reset immediately before the drive-straight algorithm starts.
i did put a reset motors but still cant
Is the math block really needed for all these things because I'm using the iPad version and it doesn't have it?
Yes, the math block is necessary for the program to work correctly.
Our team is so appreciative of your videos! Thanks for making them! Quick Question- how would you combine this program to make the robot drive straight with the program to ramp up and down?
That's going to be kind of complicated. But, you can add the programming for the drive straight into the loop after the acceleration bit. Think of it this way; acceleration sets the initial speed, then the drive straight program makes some adjustments.
Thank you so much! We'll try that!
Can you please make one for medium motors, It's so hard for me. 😅
I've added it to the list. Thanks for the suggestion!
@@Builderdude35 thank you!
Good info but this will not work if either of the wheels comes off the ground, it wont know to slow or stop the other wheel, since it does not measure load/torque.
This is true, but if your robot is in a situation where its wheels will come off the ground, you need other means of keeping it straight anyway.
this did not work pls help idk what i'm doing wrong
can you use motor degrees to exit a loop?
Yes.
thanks!
Why is my robot going in circles? Please help, i’m quite new to this thing
It may be that you forgot to add two motor reset blocks (one for motor B, one for C) before the drive-straight program starts.
Could you do that with java
IT DOESN'T WORK FOR ME, IT DEVIATES ANYWAY AND I TRY WITH 0.2, 0.7, 0.5, WHICH MAY BE. THANK YOU.
it didnt even stop make a vid on that
See my recent video on Loop exits: ruclips.net/video/_YRwKHP4v8A/видео.html
My robot jerks both ways back and forth
it doesn't work
Hi
Bye
Knowledge test:
Read more
Its too far down
Meh nam Iz JEFF
Hey Jeff, I'm Kyle.
He Kyl wat is ur nam
So I ran the program, and it does make my robot go straighter, and saved it as a portable program, but I am not sure how I would add it to a regular FLL program. Can anyone help?