Great video and excellent demonstration/explanation. As I've learned this game to teach my kids I've often used your videos for tip/tricks and helping to explain thing to my kids. I'd like to offer a few comments: 1) I don't think it's too complicated to consider adding a speed variable to your created turn block. This way your longer missions can be easily customized for faster or slower turning depending on the action needed during the robot travel. 2) I don't teach my kids to reset yaw in the "custom block". Instead we reset yaw only 1 time when we are pushed backward against the back wall. When we turn to we specify a "global" angle based on the start orientation. With your demonstrated code you may have error from continually drifting beyond your target angle and reset yaw based on the robots position. I have a printed unit circle with degrees shown from 0 to 180 and 0 to -180, also showing intermediate angles (15, 30, 45, 60, etc...) we place that on the board when we want to turn and orient it how the robot was facing at the begging of the mission. Now the kids know the target angle...or at least best 1st guess and they can then hone in on the exact angle they need.
@jetescamilla tysm for the idea with the gyro sensor my team is competing at nationals on the weekend and this has helped our consistency a ton!!!!!! Good Luck with your lego league endeavors (:
I would be wary of backing up to square against the wall. At least for the competitions in Colorado last season, they did not tape the maps down to the tables and would not because that isn't done at world competition in Texas. We had coded based on our table where we taped the map down, and we ended up needing to change all of our code (granted it was minimal) so we didn't end up shifting the map underneath the robot. One thought I had was to create a "Reset" MyBlock that would set the yaw angle to 0º right after we had squared against a surface and before we moved again. For some of the code, we also reset the timer in that same block for where we had time-based calculations. I would love to find out your thoughts on this!
Great video, thanks for sharing. My FLL-C team uses Spike Prime, looking forward to working this with them. But for our elementary school program, we have a mix of Spike Prime and EV3 bots. I've tried adapting your process to an EV3, and find that it consistently overshoots the target angle. No surprise, I get better results with slower turns. I also have played around with adding a reverse slow turn to recover from the overshoot. It works, but both of these options slow down the bot's navigation, so I'm trying to figure out why it's happening. Is the Spike gyro that much more sensitive/faster that it helps prevent overshoot? Is the missing "Set Acceleration" command (not available in EV3 Classroom) part of the problem? Any other ideas?
When we added a gyroscope and wall start to the code, the robot became more consistent. Share tips on what else can be used to make the robot game more successful? Thank you
Still getting recomended FLL content tho we were knocked out pretty early. Won the tech part tho. We spent weeks after school yet we shot to high so we had too cut down 90 % of our code, that was painful 😅
Great one.. we competed this year, 2023 .. it was fantastic.. from Ghana .. I need more tips for this year . Coding is not my problem. My students and I are masters in coding.
Hello, we will participate in this competition from Turkey, this is our first experience, I do not know how to design our robot and what our codes will be, can you please guide us?
I believe it’s because a positive turn of (for example) 200 degrees is the same as a negative turn of -160, if my math is correct which it sometimes is.
The gyro has a reading range for yawning of [-180, 179], and since it's a circle, it sets back to -180 after 179. You could use the walls to "reset" the gyro to 180 and then turn to 0 to make a half turn.
I have had a problem with this method when the second turn is less that the first. Right 45 Left 90 Will work fine Right 45 Left 45, 44,43 etc.. Does not work Right 45 Left 46 Works Anyone else have this issue?
That is a GREAT question! Two reasons... 1. Myself and my immediate colleagues work primarly with grade 4-6 students. So anywhere between 9-11 years of age is our normal student on our teams. We DO NOT want to disrupt any linear thinking skills more than we have too. We value them creating, understanding and calling a function... but only to help their linear path of "the robot is turning left/right now".... 2. Why would that be extremenly benefical? As I sugguest to all teams that i inteact with, having a Skeleton or Starting Code program to duplicate is a game changer... but where in code are we recalling a starting squence multiple times? Teams typically have one launch per SPIKE program. IF you could call functions from outside of any given SPIKE program, then it would be super useful to have ANY function database to pull/call functions from. However that infastructure does not presently exist.
Great video and excellent demonstration/explanation. As I've learned this game to teach my kids I've often used your videos for tip/tricks and helping to explain thing to my kids. I'd like to offer a few comments:
1) I don't think it's too complicated to consider adding a speed variable to your created turn block. This way your longer missions can be easily customized for faster or slower turning depending on the action needed during the robot travel.
2) I don't teach my kids to reset yaw in the "custom block". Instead we reset yaw only 1 time when we are pushed backward against the back wall. When we turn to we specify a "global" angle based on the start orientation. With your demonstrated code you may have error from continually drifting beyond your target angle and reset yaw based on the robots position. I have a printed unit circle with degrees shown from 0 to 180 and 0 to -180, also showing intermediate angles (15, 30, 45, 60, etc...) we place that on the board when we want to turn and orient it how the robot was facing at the begging of the mission. Now the kids know the target angle...or at least best 1st guess and they can then hone in on the exact angle they need.
@jetescamilla tysm for the idea with the gyro sensor my team is competing at nationals on the weekend and this has helped our consistency a ton!!!!!!
Good Luck with your lego league endeavors (:
My team just placed third in the Worcester completion in cape town thanks to this video lots of help Thanks
I would be wary of backing up to square against the wall. At least for the competitions in Colorado last season, they did not tape the maps down to the tables and would not because that isn't done at world competition in Texas. We had coded based on our table where we taped the map down, and we ended up needing to change all of our code (granted it was minimal) so we didn't end up shifting the map underneath the robot.
One thought I had was to create a "Reset" MyBlock that would set the yaw angle to 0º right after we had squared against a surface and before we moved again. For some of the code, we also reset the timer in that same block for where we had time-based calculations. I would love to find out your thoughts on this!
Thankyou for your useful information on turning using Gyroscope. Very Useful.🎉
Great video, thanks for sharing. My FLL-C team uses Spike Prime, looking forward to working this with them.
But for our elementary school program, we have a mix of Spike Prime and EV3 bots. I've tried adapting your process to an EV3, and find that it consistently overshoots the target angle. No surprise, I get better results with slower turns. I also have played around with adding a reverse slow turn to recover from the overshoot. It works, but both of these options slow down the bot's navigation, so I'm trying to figure out why it's happening. Is the Spike gyro that much more sensitive/faster that it helps prevent overshoot? Is the missing "Set Acceleration" command (not available in EV3 Classroom) part of the problem? Any other ideas?
This really helped my team:)
When we added a gyroscope and wall start to the code, the robot became more consistent.
Share tips on what else can be used to make the robot game more successful? Thank you
Still getting recomended FLL content tho we were knocked out pretty early. Won the tech part tho. We spent weeks after school yet we shot to high so we had too cut down 90 % of our code, that was painful 😅
did u guys make it to states?
@ no i competed in my city gothenburg and i would Say the eqiulent of states is scandinavian Comp so sadly no
Great one.. we competed this year, 2023 .. it was fantastic.. from Ghana ..
I need more tips for this year . Coding is not my problem. My students and I are masters in coding.
omg can you teach me coding after 2days will be a competition and I’m coder but I don’t know coding sorry for my English
Hello, we will participate in this competition from Turkey, this is our first experience, I do not know how to design our robot and what our codes will be, can you please guide us?
Where can we find the code download?
where can i buy the kit to play for fun?
😊❤😊 A positive attitude and good ideas make perfect
We tried turning up to 179 degrees (almost a half circle) and it works. But it doesn't work with anything over 179. Why is that?
I believe it’s because a positive turn of (for example) 200 degrees is the same as a negative turn of -160, if my math is correct which it sometimes is.
The gyro has a reading range for yawning of [-180, 179], and since it's a circle, it sets back to -180 after 179.
You could use the walls to "reset" the gyro to 180 and then turn to 0 to make a half turn.
Can I contact with you?
Can you provide an email address?
@ZacharyTrautwein send me your email
@ZacharyTrautwein can you send me your email?
I have had a problem with this method when the second turn is less that the first.
Right 45
Left 90
Will work fine
Right 45
Left 45, 44,43 etc..
Does not work
Right 45
Left 46
Works
Anyone else have this issue?
I suggested the below way to the team I am coaching
Right turn:
yaw angle > X degrees
Left turn:
yaw angle < X degrees
Since you never change the start code, why not just make it a function also? code is cleaner than and reusable
That is a GREAT question! Two reasons...
1. Myself and my immediate colleagues work primarly with grade 4-6 students. So anywhere between 9-11 years of age is our normal student on our teams. We DO NOT want to disrupt any linear thinking skills more than we have too. We value them creating, understanding and calling a function... but only to help their linear path of "the robot is turning left/right now"....
2. Why would that be extremenly benefical? As I sugguest to all teams that i inteact with, having a Skeleton or Starting Code program to duplicate is a game changer... but where in code are we recalling a starting squence multiple times? Teams typically have one launch per SPIKE program. IF you could call functions from outside of any given SPIKE program, then it would be super useful to have ANY function database to pull/call functions from. However that infastructure does not presently exist.