I found this thread and wanted to check on the drivetrain turning issue. We have a similar problem when programming the robot, the drivetrain seems to turn, even when it is programmed to drive straight. When we program it to turn 90 degrees, we have to subtract a few or add a few degrees to get it accurate.
The kits we are using are new, just opened today. We have updated the firmware. We have changed out motors, wheels, devices used to program, and tried it on different surfaces.
Any suggestions or ideas on what we can do to fix the problem?
I took a picture of what the motors are showing in the classroom app. The program was to drive forward 57 inches.
Hi @Jennifer_Spencer! I’m sorry to hear about this. If possible, could you share a video of the robot moving? This could help us further identify the issue.
I have a few things that you can try
- Can you send some pictures of the robot build? Sometimes when we see this issue, the robot could have extra friction on one side of the drivetrain compared to the other, causing it to drive not 100% straight. I saw that you noted that you already swapped out the wheels and tried running it on different surfaces. Sometimes we see a shaft collar pushed against the wheel too tightly.
- Do you have an older Kit? If so, can you try the new Brain on an old robot build? (including old motors). So here, the only new element would be the Brain.
- Can you try an old Brain on the robot built from the new Kit? This can help us determine if the issue is with the electronics.
Let me know if this helps!
Hi @Lauren_Harter! Thank you for the suggestions. I am going to send you info.
For the attached pictures, the images ending with 8233,8234, and 8235 were one robot. 8237 and 8238 are another, and 8239 and 8240 are a third.
The videos are five different robots, showing how they are veering off ‘course’. One moves forward fairly true, three veer right at different extremes, and one veered left.
We have tried loosening the wheels and shaft collars to account for inconsistent friction.
We took the robot that was moving most inconsistently and switch its new brain with our old brain. The drivetrain veered right significantly with both the new brain and the old brain.
Hi @Jennifer_Spencer! Thank you for these videos and pictures.
For the robot that was most inconsistent, was this the third robot from the left in the videos? You mentioned trying both a new and old Brain, what were the rest of the electronics and build? Were the motors on that particular robot old, new, and swapped at all?
@Lauren_Harter, yes, the one that was most inconsistent was the third from the left. We left all other electronics the same. Only the brain was changed. The motors on that robot are new.
@Jennifer_Spencer thank you for that information
Does the robot perform the same if the motors are also swapped to the old motors? I’m trying to think if the new motors (or maybe just one on the side where the robot is leaning) could be the problem.
@Lauren_Harter, we did swap out motors for a new motor and had the same issue. I will try to swap it out with an old motor and let you know.
@Lauren_Harter, here it is. This video is of the same robot swapping out the motor on the side where it veers with an old motor. It still veers. Don’t pay attention to the camera, a tv station is here doing a story!
Hi @Jennifer_Spencer! Thank you for this video, we’re looking to see if there are any other troubleshooting steps we can take to investigate the issue further
In the video, the robot keeps veering to its left trying to compensate, I wonder if it is trying to compensate for a bad motor. However, you said that it behaves this way even when the motors are swapped, correct?
Wheel slip can also cause this. Does the robot still drive this way if it’s on a different surface?
Thanks so much for your patience throughout this process of trying to identify the problem
Yes, in our initial testing, we updated the firmware, changed out motors, wheels, and devices used to program, and tried it on different surfaces.
I didn’t know if this was related to the drivetrain turning issue that @Jacob_Palnick mentioned above?
Several of the robots had the same issue, just some veered more than others.
These are 2 distinct issues. The one reported by Michael is an issue with turning, where the amount you turn is of by a proportional (multiplier) amount. The issue you are having is with driving straight. So I’m moving this conversation to a new thread in the forum to keep them from getting mixed up.
As of right now we don’t know what is causing your robots to drift while driving, but we are continuing to investigate.
There was an issue with the motors where they would have issues due to the programming devices sending messages while the brain was controlling the motors. It is possible that something similar it happening. While that seems unlikely, we can check this fairly easilly.
I suspect all the programming is done with the same devices. Are the robots and devices for programming always used as a pair? So robot 1 is always used by group 1 and is programmed with tablet/computer/coder 1.
If that is the case, try using the programming devices from another robot with one of the ones that is drifting a lot. If you don’t have everything paired up, but you are using the same tablet/computer models for programming, then it is less likely that this is the problem, but we can still test it by using a different device. For example, using a personal laptop/tablet to test with the worst of the robots to see if it changes how it drives.
These were brand new kits, just opened that day, so they had not been previously paired to a specific device. We programmed with an iPad, a Mac, and a Windows-based laptop and had the same issues.
Just want to update you. We are still investigating this issue.
One other thought is that one of the drive wheels could have less contact or intermittent contact with the floor. This could cause that wheel to slip slightly and result in the robot drifting towards that side. Can you check to make sure the wheels are always in good contact with the surface? also make sure that the drive wheels are rotating such that they do not cause intermittent as it is rotating. (could be caused by slightly bent shaft or a bad wheel)
Hello Jennifer and Jacob,
I also can observe a similar issue on my units. For me there seem to be two issues that cause problems:
- Wheels:
This has been mentioned already and its the wheels. Having them clean and in good contact is key. For me though it is not the driving wheels that are causing the issues but the blue follow wheels. For straight driving they can cause issues because sometimes they slide rather than rotate (especially on smoother surfaces such as the competition fields) which can cause the robot to veer. Also the builds have the driving and blue wheels really close together. On some occasions the blue wheel actually touches the driving wheel which causes all kinds of strange behaviour.
This configuration can also be problematic in the turns. Because of the geometry of the wheels when the robot turns, the blue wheels always need to drag across the floor without spinning. This is somewhat compensated for because the turn is controlle by the gyro sensor and the turn will complete in any case. What happens wuite often though is that the robot changes position because of this drag i.e. the center of rotations shifts away from the point between the driving wheels. In the IQ robots this problem is solved by the omni wheels but the Go kits don’t have them.
So be sure that the blue wheels are turning freely and don’t touch the driving wheel. Ideally you would replace them with a single roller ball, this makes all the problems go away but isn’t a part you can buy. I make them myself with my 3D printer and some 20mm steel balls. If you have a printer I can send you the STL file if you are interested to make your own. You can see this in action on the video.
- Motor Behaviour
The second thin I have noticed is that the motors have a rythmic pulsing behaviour which at 50% speed is roughly happening every second. I think this pulsing does actually make the robot veer in one direction. If you look at my video you can see the robot does a small right/left judder every second. It seems that for a short period of time the motor increases the speed just a fraction. On every lurch the robot moves a bit off track. The one in the video is actually doing pretty well, some of my other units are worse.
Jacob, do you know what is causing this pulsing of the motors?
All the best,
Michael
The VEX GO Brain will try to keep the heading fixed when told to drive forward/reverse. So my first thought is that the slight side to side motion you are seeing is the brain trying to adjust for a heading error while driving. It does look like overall the robot is not really drifting in the same way that was reported previously.
It is possible that one of the motors has an encoder that is not reporting correctly. We can test for this. To test for this, you need to configure the motors individually in the robot config. After that, create a project that has the motors both run at a fixed velocity. Then you should be able to see if each motor is running at a fixed speed. If you see it speeding up and slowing down as it runs, that could be a sign of a badd motor or something like a bent shaft causing periodic changes in friction and thus speed.
As for the original issue in the thread of driving in a large arc for select robots, you can also try the above to check the motors, but Since you already saw the same results even after swapping the motors and the brain, I doubt it is an issue with a motor encoder or the inertial sensor in the GO Brain causing it to drift. We are still trying to figure out what could cause the issue to happen when every part of the robot and programming setup has been switched out.
Thanks Jacob. The issue I’ve shown in the video is a momentary speed up of the motor at each rotation at a fixed position. If you look at the attached video you see that at the same point on each rotation the motor speeds up a bit before settling down again. This happens on all the motor and brain combinations in our 6 sets so I assume this is something thats inherent on the design or the brain firmware.
I realise that this is different from the issue reported originally but the connection is that the ‘jerk’ introduced by this behavior can push the robot off track over a certain distance.
Regards,
Michael