Is there a bug in latest Vex IQ firmware? I don’t have robot or iPad in front of me. At least 3 teams (and I witnessed tonight with my team) simple autonomous program not working correctly after 5 or 10 commands.
Gen 2 brains for all.
Latest firmware.
After 5 or or 10 commands a simple command (drive or turn) will not work properly.
One team: drive forward 45”. They had to split up to 4 or 5 individual drive commands of same length - drive 10”, drive 10”, drive 10”, drive 10”, drive 5”.
For us pseudo-code (start by green row):
Spin combine forward
Drive forward 26” (fine)
Drive reverse 17” (not sure full length)
(Tried turn right 60 degrees, drive reverse 7”; spin shelf lift for 3 seconds).
Trying longer length than drive reverse 17” (step 3) no change in distance - even tried drive reverse 20” no change).
If we split to two drive reverse for half distance (same total) worked fine.
Similar comments from other teams.
All 2nd gen brains; battery 100%, latest firmware, and when adding device’s inertial gyro added properly at beginning.
Does the latest firmware have a bug? I can upload our code but simple so far (just started skills program with our programmer student(. Also - another team found odd red debug screen on firmware update (? Not sure walked up to me). If set velocity to either 800,000% or 1,000,000 % (kids - let’s see how big we can enter a number!) the brain dumped a red debug error. When he put to 100% no error.
Nothing that I know of.
1.0.8 has been out since October, so it’s not exactly recent.
That sounds like the python VM is throwing an exception, so not a debug screen but just a normal result of perhaps using a parameter that was incorrect for the function call.
VEXcode did switch code generation for blocks last year, the block code now defaults to generating python rather than C++ (this can be changed in the about dialog). perhaps you have run into a bug in the python code generation.
I suggest you use the feedback tool with the project open so the dev team can try and duplicate.
1 Like
Thanks @jpearman.
I don’t have the iPad in front of me but will send tomorrow when I am there. I’ll ask the other 3 coaches to do the same.
For our program tonight, our programmer literally only about 5 steps under when brain left pressed (pseudo code I wrote). Tried to change 17” to 18” (no change); tried 19” no change), and extreme changed to 20” (no change). He split original 17” to two drive reverse 9” and it worked. Other team - drive forward 45” had to split to 5 consecutive drive for same total and it worked. Will send code or screenshot.
anything special about the drivetrain ? unusual gear ratio or anything like that ?
1 Like
For other 3 teams no.
For our team 1:1 ratio for now on elevated base driving lower rubber wheels in back; unpowered (for now) Omni wheels on front for turns. (Think monster truck base to get over supply bar later).
For each of our teams - if the split drive into pieces works fine (for us also). The other team example drive 45” would only go a short distance until they split total drive distance into shorter chunks. That’s what clued our programmer to split 17” into two. Note - original drive 26” accurate. Drive reverse (after 60 degree turn) accurate.
did a quick test using both codeiq.vex.com and iPad.
everything works as expected.
you don’t perhaps have a short drivetrain/motor timeout set that would cause the drive command to abort early ?
1 Like
Sorry for delay. Brought iPad home and sent feedback with topic title. Vexcode IQ is version 3.0.1.3;Python selected. Do not have any set timeout in code
@jpearman
Is the topic “Gen 2 unable to run blocks after certain point related”?
did a brief test here again with your code. I can change drive distances without an issue.
One question, is the controller turned on ? If so then you should disable at the start of that code stack.
I doubt it. Nearly always these issues are related to either code logic or build problems (ie. a drive or turn not completing correctly)
1 Like
Controller is turned off. They copied the drive code so they didn’t have to add devices in again; use when brain left for start run; and use drive code for example (but controller is turned off).
I can try addingturn controller off and test. I know the physical controller was turned off.
Thoughts?
I’m pretty much out of ideas due to not being able to reproduce. Now I am simplifying at the moment, I don’t have the same robot and am just using drivetrain motors attached to the brain (with a wheel stand in that I can use to estimate distance travelled). I will try and find time this weekend to build up a clawbot with the additional sensors and motors you have and see if that changes anything.
1 Like
Thanks James!
I’ll have him add controller off and see what it does. Odd thing about 4 robots similar problems. Trying to help resolve for at least 4 teams.
I’ll keep you posted. For us, it was odd other forward reverse fine; just that one. Split in half (drive 8, drive 8) works.
Will have him work tomorrow afternoon on skills and let you know what we find. Late start to season and we don’t build a simple robot. Just starting to program and try to catch up before states March 2.
@jpearman
James - confirming our controller was off while running program, but we had issues.
We added the command you did - controller disable and it worked!
We still have some delta issues (drive forward 20”, drive reverse 21 (not momentum issue) but able to work thru that. One of teams with turn 180 was able to do two 90’s and they just worked with that. I’ll check with the other two teams to see if controller disable fixes their issues. That I know (but can check) their controllers were off.
Thanks!
To be honest, if the controller was off then the controller disable block should have made no difference. It would be interesting to know if disabling the drivetrain being attached to the joysticks in graphical setup also fixes the auton code. Let me know if you figure out what may have happened.
1 Like
I spoke with the other teams but no update yet. We still have the controller configured under devices. Controller was/is off. Adding the command controller disable seemed to have worked for us; drive commands working as expected.
If I hear anything will pass along - and thank you (as always) for the tips and guidance!
1 Like
