The problem with this program is that the correction factor is dependent on the absolute value of the commanded turn. If you turn less than 5 degrees, for example, this program will introduce quite a bit of error. Below 10 degrees, the correction factor should be scaled down.
Absolutely. My team never needed a small angle turn, so didn't focus on that. Once at a full [unchanged] speed into the turn (which happened in the first ~15 degrees), the offset remained constant. The offset is really just a measure of the time between sending the stop signal and the robot coming to a full stop - it will vary based on how fast the robot is going. To account for smaller angles, a ratio could be introduced into the offset calculation. Instead of just "abs(a) - b", you could use something like "abs(a) - min(b, abs(2*a/b))", so angles under 18 degrees would get the offset scaled down.
b is a correction factor because if I just used "90" it would tend to turn about 96 degrees. Because I subtract b (6) from a, I need to use an absolute value. Otherwise, you would end up with something like -90 - 6, which is -96, causing the robot to turn further than you want.
WE used this block successfully; however, your My Block your gyro sensor is set to Angle and NOT reset like your first test. How does this work in the My Block. No matter what the gyro states its angle value the robot always turns 90 degrees left or right, why is that since the gyro block is set to Angle and NOT reset and the Turn Until is looking for a change to 90? The final Gyro reading is the angle it turned, can you explain how that works? Example if the gyro is at angle of 236 before the turn block how does the gyro state 90 degrees after the turn block and turns the proper degrees?
You can do it with wheel rotations. It'll be different for each wheel size and axle length. Do some experiments with the tank turn green block - turn just one wheel 20, 40, 60, etc. degrees while recording with a protractor what angle your robot turns. From there, you should be able to figure out how many degrees of wheel rotation will cause your robot to turn 45 degrees.
EXCELENTE VIDEO FELICIDADES!! COMO SE PONDRIA DENTRO DEL BLOQUE QUE CREASTE UE SE PUDIERA CONTROLAR LA VELOCIDAD YLA DISTANCIA A RECORRER, SI ME LO PUDIERAS ENVIAR POR FAVOR
Instead of introducing a 6 degree 'fudge factor', how hard would it be to just have it turn at full speed for 90% of the turn, then slow the motor down for the last 10%? That's why it's overshooting -- the inertia of the robot in motion is sailing it past the desired angle.
Give it a shot and let me know! I'm not certain how much of a time savings it will give you, though. i think the next big time savings to be had is converting two straights path with one turn into a single curved turn. My kids on the FLL team weren't able to figure out the math for it, so we skipped it.
@@hyliston oh, curves are fun! The trick is knowing that the power given to the wheels is proportional to the distance they travel. So, if the left wheel has 50% power and the right wheel has 25% power, the right wheel will go exactly half as far as the left. Once they understand that, the rest is basic math. For example, say they want a long curve that involves the left wheel traveling 1286 degrees and the right wheel traveling 1908 degrees (determined by moving the robot by hand while in port view). 1286 / 1908 = 0.674. They'll then program the left wheel to receive 0.674 * the power of the right wheel: 40 * 0.674 = ~27. Program a move tank block with left power: 27, right power: 40, distance: 1908 degrees (the EV3 software applies the distance number to the wheel with more power). It will move in that same perfect curve every time. (I just picked 40 randomly. It will work as long as whatever power you give the right wheel, the left wheel is 0.674 of that.) When the kids can run two or three curves together and gracefully 'S' their way across the table, it really is a thing of beauty!
We are having problems making the program to make a right hand turn after it makes a left hand turn and drives. Our program drives forward, then turns left ( -90), then drives forward and supposed to turn right (+90), but it keeps turning left instead, regardless of the value (-90 or +90). Both left turn and right turn look the same otherwise. If we turn right first (90), then it allows us to turn left (-90). Help!
I made a giant myblock for this using the gyro, but mine has an input for just about anything you might need to change, but yours still has similar results, mine only varies by 1 degree and it looks like yours does the same :P
Wow u are a gene ius. I have run this program on several” adaptations of bots. The bots progressively getting better but the program adapts as long as u fine tune it. Regards Paul
That is how many degrees the robot would over-turn. It's caused by a delay between when the gyro reads the number and how long it then takes the wheels to stop turning.
Watch your program when it is running and see where it hangs up. You can also watch the bottom right window for each sensor reading. I'm guessing you have your gyro sensor in a different port that what you selected in your program. Does the gyro value change in the sensor window?
Well explained with clear and simple terms. Keep up your good job. Thank you.
This is helpful. I typically create a MyBlock for 90 turns each of left and right. But this is great.
No, this is awesome. This is very awesome.
Very Impressive and very good tutorial!
The problem with this program is that the correction factor is dependent on the absolute value of the commanded turn. If you turn less than 5 degrees, for example, this program will introduce quite a bit of error. Below 10 degrees, the correction factor should be scaled down.
Absolutely. My team never needed a small angle turn, so didn't focus on that. Once at a full [unchanged] speed into the turn (which happened in the first ~15 degrees), the offset remained constant. The offset is really just a measure of the time between sending the stop signal and the robot coming to a full stop - it will vary based on how fast the robot is going. To account for smaller angles, a ratio could be introduced into the offset calculation. Instead of just "abs(a) - b", you could use something like "abs(a) - min(b, abs(2*a/b))", so angles under 18 degrees would get the offset scaled down.
what is the absolute value for? and why we need to minus a and b. thanks
b is a correction factor because if I just used "90" it would tend to turn about 96 degrees. Because I subtract b (6) from a, I need to use an absolute value. Otherwise, you would end up with something like -90 - 6, which is -96, causing the robot to turn further than you want.
WE used this block successfully; however, your My Block your gyro sensor is set to Angle and NOT reset like your first test. How does this work in the My Block. No matter what the gyro states its angle value the robot always turns 90 degrees left or right, why is that since the gyro block is set to Angle and NOT reset and the Turn Until is looking for a change to 90? The final Gyro reading is the angle it turned, can you explain how that works? Example if the gyro is at angle of 236 before the turn block how does the gyro state 90 degrees after the turn block and turns the proper degrees?
How do i make a 45 degree angle with out a Gyro block?
You can do it with wheel rotations. It'll be different for each wheel size and axle length. Do some experiments with the tank turn green block - turn just one wheel 20, 40, 60, etc. degrees while recording with a protractor what angle your robot turns. From there, you should be able to figure out how many degrees of wheel rotation will cause your robot to turn 45 degrees.
EXCELENTE VIDEO FELICIDADES!! COMO SE PONDRIA DENTRO DEL BLOQUE QUE CREASTE UE SE PUDIERA CONTROLAR LA VELOCIDAD YLA DISTANCIA A RECORRER, SI ME LO PUDIERAS ENVIAR POR FAVOR
Very good video, please make some more!!!
Instead of introducing a 6 degree 'fudge factor', how hard would it be to just have it turn at full speed for 90% of the turn, then slow the motor down for the last 10%? That's why it's overshooting -- the inertia of the robot in motion is sailing it past the desired angle.
Give it a shot and let me know! I'm not certain how much of a time savings it will give you, though. i think the next big time savings to be had is converting two straights path with one turn into a single curved turn. My kids on the FLL team weren't able to figure out the math for it, so we skipped it.
@@hyliston oh, curves are fun! The trick is knowing that the power given to the wheels is proportional to the distance they travel. So, if the left wheel has 50% power and the right wheel has 25% power, the right wheel will go exactly half as far as the left. Once they understand that, the rest is basic math.
For example, say they want a long curve that involves the left wheel traveling 1286 degrees and the right wheel traveling 1908 degrees (determined by moving the robot by hand while in port view). 1286 / 1908 = 0.674. They'll then program the left wheel to receive 0.674 * the power of the right wheel: 40 * 0.674 = ~27. Program a move tank block with left power: 27, right power: 40, distance: 1908 degrees (the EV3 software applies the distance number to the wheel with more power). It will move in that same perfect curve every time. (I just picked 40 randomly. It will work as long as whatever power you give the right wheel, the left wheel is 0.674 of that.)
When the kids can run two or three curves together and gracefully 'S' their way across the table, it really is a thing of beauty!
We are having problems making the program to make a right hand turn after it makes a left hand turn and drives. Our program drives forward, then turns left ( -90), then drives forward and supposed to turn right (+90), but it keeps turning left instead, regardless of the value (-90 or +90). Both left turn and right turn look the same otherwise. If we turn right first (90), then it allows us to turn left (-90). Help!
It sounds like you might need a reset block. Adding some debugging output to the LCD screen about the current angle might also help.
When you say reset block, do you mean resetting the motors or the Gyro, because we resetted the Gyro and that did not help?
thank you so much for this video help a lot !
I made a giant myblock for this using the gyro, but mine has an input for just about anything you might need to change, but yours still has similar results, mine only varies by 1 degree and it looks like yours does the same :P
Mine doesn't take decimal under 1
So , it's possible to put another parameter for the over-turn on the myblock?
Yes. Especially if you turn at a speed other than 40, you will likely need to adjust the over-turn correction parameter.
Wow u are a gene ius.
I have run this program on several” adaptations of bots.
The bots progressively getting better but the program adapts as long as u fine tune it.
Regards
Paul
why was the number 6
That is how many degrees the robot would over-turn. It's caused by a delay between when the gyro reads the number and how long it then takes the wheels to stop turning.
THIS IS SUCK AN AMAZING PROGRAM, THX SOOO MUCH
I think mine is broken... the gyro programming block doesn't show up under the sensors tab. Anyone know how to fix this?
+skyluke3 Gaming Yes.
*****
Thanks, I have it now!
or just go to lego and find file blocks and replace EducationOnly with space
Es muy importante y educativo gracia al eso podemos ser grande en el mundo
Omg fantastic
Nice video
Make one that turns left
+Sheil Patel It does turn left - you enter a negative number for left turns and a positive number for right turns
thank u
Mine goes in circles repeatedly
Watch your program when it is running and see where it hangs up. You can also watch the bottom right window for each sensor reading. I'm guessing you have your gyro sensor in a different port that what you selected in your program. Does the gyro value change in the sensor window?