You can simplify this program by using a move steering block(like your original drive straight) instead of a move tank. Of course the order of which motor's value you subtract from which will need to change if you drive in reverse, so what we did was copied the entire code into a second condition in a switch with these values swapped. Then we just run the different side of the switch for the direction we want, you can program this to select automatically based on whether power is positive(> 0) or negative. Last year the fll team that I coach made a myblock that accelerates or deccelerates in either direction incorporating drivestraight and with the option of running for rotations. Needless to say it was quite complicated. We had trouble getting the distance it drives consistent at first since accelerating works on time which is not very consistent, so we then made it go for rotations after accelerating(of course without resetting the rotations after accelerating so it measures the total rotations traveled throughout) and then it worked really really well.
My son's FLL team did something similar this year, although I think he/they took it further. They already were using a Gyro-assisted "stay straight" block, where variations detected by the gyro sensor would cause proportional adjustments to the speeds of the two motors. This year they added the concept of "speed limits". There's the general overall max speed, but also a speed limit based on time when the block stops, and a speed limit based on distance from the destination. The robot speed is capped by these three limits. Using this approach, the robot ramps up the speed at the start, and ramps down the speed as it stops. Because of these limits, they are able to simple say "go straight" pretty much everywhere, rarely needing to adjust the speed, because short distances (where precise movements are needed) never reach the full speed. This was my son's last year, and was kind of the "capstone" of what he learned over 7 years of FLL. They were fortunate to win the programming award at the state championship event this year.
Hi. Very nice. Thank you for sharing this. The bottom of your green tools has 3 icons on the right that I have not seen before. What are they? I checked for a software update and saw nothing; but, I do not have the three icons that are to the right of the brick light green tool.
Hey Kyle, I've got 2 new video ideas for you to consider: A light calibration and gyro calibration programs!. Our robot in FLL was wonky because our gyro messed up, so please consider it :D
It's convenient that you should ask, because I already have tutorials on these topics! Calibrate color sensor: ruclips.net/video/UZX13bIYcYY/видео.html Calibrate gyro: ruclips.net/video/7V16AEW3GG4/видео.html
Hi, good job! I saw you have many EV3 block, I mean, not my block, they are blocks which created by developer edition. Do you have any tutorial video for that? Thanks.
Hey Kyle, first of all, thanks a lot for your videos. They are very, very helpful! In this video, I am asking myself why you are not using the built-in data wire of the loop block. If you have a loop running for x times, there is a data wire available (at the starting point of the loop) which exactly contains the current index number of the loop. So pretty the same as what you 'Power' variable does. Is there a reason why you built it this way, so why you use a variable instead of the index value of the loop? (If my English is strange, sorry for that, I am not a native speaker.)
That's a great point! You absolutely may use the count built into the loop, and it should work the same. I'm primarily a C programmer, so I always think of programming in terms of C code, that's the only reason why I wrote the EV3 code the way I did. :)
I really like this program, but I can't figure out how to make it stop at a specific distance. Is there a way to run a parallel code to exit the loop once certain number motor degrees have been reached? More specifically, we are trying to solve 3 problems, acceleration, motor drift, and stopping at a specific point. Your videos have been most helpful and free of errors.
First, give the loop that you want to end (the one that contains the driving code) some kind of name (the default name is "01"). Then you will need a second Start block to start a parallel branch of code. The second branch should have an infinite loop that monitors the rotations, then triggers the true case of a switch if the condition is met. Inside that true case, place a Loop Interrupt block and select your named driving loop. Voila, your exit case is set up!
Hi, How can we combine acceleration and gyro-drive straight. Because yes this acceleration program works fine but if not attachments on robot. In FLL when we add the attachments for the missions, acceleration doesn't work because or center of mass changed.
Hi Kyle, why would we want to use acceleration in FLL? Was just wondering cause I do not really use acceleration in FLL competitions. Thanks for the help in advance.
Can you make one that has both moves in centimeters and deceleration, except the deceleration doesn't happen the whole way, only part of the way using a percentage? I tried making one it worked but was hard to use. Can you make a tutorial video about that?
Hi Kyle, if u wanted. It to continue smoothly at max speed would it be best to include this loop in a Boolean loop with a logic test of if not at 100, Regards, paul
Absolutely! You will just need to know the diameter of the wheel to convert degrees to linear distance (and assume no wheel slippage). See my video on calculating linear distance from wheel diameter (How Far is One Rotation?).
The Seshan brothers have an *excellent* text-based resource here: ev3lessons.com/translations/en-us/advanced/GyroRevisited.pdf. It addresses most cases of gyro drift, and addresses some of the confusion about why "calibration" doesn't always work.
Hi Kyle; while your tutorial does an excellent job of explaining the proven approach of switching measurement modes on the Gyro, that widely-accepted technique never quite worked for me (and many others.) Someone in the Seshan brothers' reader base (Sam Last) managed to discover that EV3 gyro sensors produced from 2014 onwards use different electronics that behave differently - they do NOT reset when changing measurement modes. For those, the only way to reset them is to disconnect/reconnect or - get this - force the brick to reset them by reading them as "infrared" sensors! Very interesting technique indeed, documented very well in the link I posted. Have been using it for the past few months with great success.
Some robots (like Sirius) move backwards with positive power. Try making the drive motor power negative. Also take car to change the "+" sign to a "-" in the part of the program that increases the robot's speed.
![SahBabii - Viking [Official Music Video]](http://i.ytimg.com/vi/D37cL92JX0I/mqdefault.jpg)
You are not the hero we need but the hero we deserve
You can simplify this program by using a move steering block(like your original drive straight) instead of a move tank. Of course the order of which motor's value you subtract from which will need to change if you drive in reverse, so what we did was copied the entire code into a second condition in a switch with these values swapped. Then we just run the different side of the switch for the direction we want, you can program this to select automatically based on whether power is positive(> 0) or negative. Last year the fll team that I coach made a myblock that accelerates or deccelerates in either direction incorporating drivestraight and with the option of running for rotations. Needless to say it was quite complicated. We had trouble getting the distance it drives consistent at first since accelerating works on time which is not very consistent, so we then made it go for rotations after accelerating(of course without resetting the rotations after accelerating so it measures the total rotations traveled throughout) and then it worked really really well.
That is awesome, thank you for sharing!
My son's FLL team did something similar this year, although I think he/they took it further. They already were using a Gyro-assisted "stay straight" block, where variations detected by the gyro sensor would cause proportional adjustments to the speeds of the two motors. This year they added the concept of "speed limits". There's the general overall max speed, but also a speed limit based on time when the block stops, and a speed limit based on distance from the destination. The robot speed is capped by these three limits. Using this approach, the robot ramps up the speed at the start, and ramps down the speed as it stops. Because of these limits, they are able to simple say "go straight" pretty much everywhere, rarely needing to adjust the speed, because short distances (where precise movements are needed) never reach the full speed. This was my son's last year, and was kind of the "capstone" of what he learned over 7 years of FLL. They were fortunate to win the programming award at the state championship event this year.
That's incredible! Thank you for sharing this with me! That is a fantastic idea and I'm glad to hear about it. Tell him I said congratulations!
This is really helpful! Thanks for the idea.
You're welcome!
Hi. Very nice. Thank you for sharing this. The bottom of your green tools has 3 icons on the right that I have not seen before. What are they? I checked for a software update and saw nothing; but, I do not have the three icons that are to the right of the brick light green tool.
I explain why in this video: ruclips.net/video/MKXFIZPVgw0/видео.html
Hey Kyle, I've got 2 new video ideas for you to consider: A light calibration and gyro calibration programs!. Our robot in FLL was wonky because our gyro messed up, so please consider it :D
It's convenient that you should ask, because I already have tutorials on these topics!
Calibrate color sensor: ruclips.net/video/UZX13bIYcYY/видео.html
Calibrate gyro: ruclips.net/video/7V16AEW3GG4/видео.html
Hi, good job!
I saw you have many EV3 block, I mean, not my block, they are blocks which created by developer edition.
Do you have any tutorial video for that? Thanks.
Hey Kyle, first of all, thanks a lot for your videos. They are very, very helpful! In this video, I am asking myself why you are not using the built-in data wire of the loop block. If you have a loop running for x times, there is a data wire available (at the starting point of the loop) which exactly contains the current index number of the loop. So pretty the same as what you 'Power' variable does. Is there a reason why you built it this way, so why you use a variable instead of the index value of the loop? (If my English is strange, sorry for that, I am not a native speaker.)
That's a great point! You absolutely may use the count built into the loop, and it should work the same. I'm primarily a C programmer, so I always think of programming in terms of C code, that's the only reason why I wrote the EV3 code the way I did. :)
I really like this program, but I can't figure out how to make it stop at a specific distance. Is there a way to run a parallel code to exit the loop once certain number motor degrees have been reached? More specifically, we are trying to solve 3 problems, acceleration, motor drift, and stopping at a specific point. Your videos have been most helpful and free of errors.
First, give the loop that you want to end (the one that contains the driving code) some kind of name (the default name is "01"). Then you will need a second Start block to start a parallel branch of code. The second branch should have an infinite loop that monitors the rotations, then triggers the true case of a switch if the condition is met. Inside that true case, place a Loop Interrupt block and select your named driving loop. Voila, your exit case is set up!
@@Builderdude35 Hi I tried it but It does not work is there anyway you could make a tutorial
Hi, How can we combine acceleration and gyro-drive straight. Because yes this acceleration program works fine but if not attachments on robot. In FLL when we add the attachments for the missions, acceleration doesn't work because or center of mass changed.
Yes how to you make the robot go for longer
Hi Kyle, why would we want to use acceleration in FLL? Was just wondering cause I do not really use acceleration in FLL competitions.
Thanks for the help in advance.
It's not necessary, but some teams choose to use it to minimize the possibility of wheelspin, which would make their odometry inaccurate.
Can you make one that has both moves in centimeters and deceleration, except the deceleration doesn't happen the whole way, only part of the way using a percentage? I tried making one it worked but was hard to use. Can you make a tutorial video about that?
Maybe this is what you're looking for: ruclips.net/video/vlntXTjUv08/видео.html
Hi Kyle, if u wanted. It to continue smoothly at max speed would it be best to include this loop in a Boolean loop with a logic test of if not at 100,
Regards, paul
Thank you for the input!
very helpful! is it possible to program an accelerating motion while following a line?
And How can we program that the robot is driving with a given speed ?
how can we program that the is doing 1 turn on the motor?
Is it possible to merge that myblock with one to convert degrees to centimeters?
Absolutely! You will just need to know the diameter of the wheel to convert degrees to linear distance (and assume no wheel slippage). See my video on calculating linear distance from wheel diameter (How Far is One Rotation?).
My video idea is how to correct gyro drift and use an alternative when a gyro drift is present
The Seshan brothers have an *excellent* text-based resource here: ev3lessons.com/translations/en-us/advanced/GyroRevisited.pdf. It addresses most cases of gyro drift, and addresses some of the confusion about why "calibration" doesn't always work.
thanks
Try this tutorial of mine: ruclips.net/video/7V16AEW3GG4/видео.html
Hi Kyle; while your tutorial does an excellent job of explaining the proven approach of switching measurement modes on the Gyro, that widely-accepted technique never quite worked for me (and many others.) Someone in the Seshan brothers' reader base (Sam Last) managed to discover that EV3 gyro sensors produced from 2014 onwards use different electronics that behave differently - they do NOT reset when changing measurement modes. For those, the only way to reset them is to disconnect/reconnect or - get this - force the brick to reset them by reading them as "infrared" sensors! Very interesting technique indeed, documented very well in the link I posted. Have been using it for the past few months with great success.
Why didn’t you use the gyro sensor?
I find the motor encoder to be more reliable. However, next week I am releasing a video on PID gyro drive straight; be sure to check it out!
why does my robot move backward?
Some robots (like Sirius) move backwards with positive power. Try making the drive motor power negative. Also take car to change the "+" sign to a "-" in the part of the program that increases the robot's speed.
mine still is not working!can somebody help me??
maybe your robot drives backwards if you put motor block on forward, just change the numbers you need such as -1 or divide in the loop.
My robot doesn't run. I followed all the steps
Hi
Is it possible to add a gyrosensor to a 31313 package?
yes i did it because all the sets are the same only the parts for building the robot might be more or less so my answer to your question is YES
!!
Or, you could use a move steering block, which I believe automatically corrects for veering based on the rotation sensors.
is it ????
Lol, I meant to post that in the main thread. In my gyro ramp move inches my block, I use both a steering block, and a gyro.
my anwer is that everithing is possible with lego and ev3!!!!!