I am writing some tutorials to intro conditionals for my students. I wanted to use location sensing, but getting weird behaviors. For instance, why would this code result in X being -899.9? Shouldn’t it still be -900? Makes exact positioning impossible. BTW: X gets off course as the robot is moving from y=-900 to 600.
Possibly a glitch to fix or is there a technical feature I am missing?
I really wanted to challenge my kids to write code to goto specific coordinates as a simple intro to conditionals.
You are heading 90.01 degrees so when you travel 900 mm so its not exactly a change in 900 mm in the x-direction because you aren’t going straight. To fix this, you can try hitting the back wall with the backside of the robot to align it perpendicular to the wall (90 degrees).
Hope this helps and feel free to ask questions to clarify if you don’t understand.
Thanks for the help. Not sure that is it as I checked that. When the program starts, heading is 0. It stays at zero will progressing north, but it too gets bumped to 90.01 when the X direction gets tweaked. Doesn’t make sense.
For kicks, I put SetDriveHeading to 0 into the program at the start and even in the loop to no avail. Curious, what happens if you try the code.
I tried the code in chrome it has the same error as you are saying, but apparently edge is not supported.
I think this vr vex is truly great at simulating real life situations as in real life robots can drift and the only way I have seen to fix that to achieve utmost precision is the gyro sensor but I can’t see that sensor option in the sensing.
hopefully this will help. it uses geometry to determine how much to turn and how far to go to get to the target point. maybe it can be modified to show how much to turn and how far to go so that your conditional can work 100% of the time. good luck!
quick edit: changed the file, this one was saved before it was finished o.O
It could be accumulated error or slight jitter coming from the fact that you’re driving in 50mm increments and stopping many times (from -900 to +600). Not everything in VR is 100% perfect as we are still using wheeled vehicles and physics - as opposed to just moving an avatar around the screen (like scratch).
I’d say the potential 0.1mm error in this situation is to be expected as there’s not much else we can do aside from suspending the physics engine when starting and stoping so many times.
I would recommend replacing your “drive for ” with a “drive” command so the robot does not stop so many times. Also, you can figure out your current position and your destination and use a single drive for command to move to the point once using math blocks (Y2-Y1):
(Drive forward for (600 - [current y position in mm]) mm)
Thank you for the assistance. Frosty, that is too complex for an intro to basic concepts for middle schoolers, but super cool
tfriez: when you said “physics” you gave me some critical insight into the VR engine. Curiously enough, your approach also results in a .1 jitter off course. The reason I was moving in increments of 50 was to feature the repeat until in action and that was a decent grid granularity traded off with speed.
I’d still like to know why one stop would tweak X and Heading while most of the others don’t. If nothing else is acting on the robot, I expect it to hold. Do I need encoders on my virtual wheels
That said, a simple fix was to just round the position sensor results before comparing. Good enough for my teaching target.
Technically, worked around a ‘feature’ of the platform, which is a key skill for all engineers I have learned dozens of languages/platforms over the years. Half the learning curve is learning about the eccentricities/bounds/limitations/secrets etc of said Platform. As a teacher, I prefer to know as many of these as possible before deploying a lesson, especially when I will not be able to stand over their shoulder this time around. Thanks again for the help!
