We have a basic gyro heading script running on our Spike Prime robot. It works fine, but only sometimes. We are wondering if the pressure on the wheel is the source of this problem or whether it is a mechanical issue.
It doesn’t look like the wheels are parallel to each other on your robot. Is there a reason why you have the magenta blocks between the motor and wheel hubs? I might try mounting the wheels directly to the motor with 4 pins and an axle to keep them square to the body of the robot. You might even try to support the axles through the frame/bumper of your robot to keep everything in line.
Even if you don’t have clearance to remove the magenta blocks, the thru-axles, supported on both ends will help.
1 Like
Are you able to repeat that test on a surface with more traction than the hardwood floor. Something like indoor/outdoor carpet or a large piece of bare plywood. A second test would be to reduce the power level used. A third test would be to add some weight on top of the robot, say a thick textbook.
Re-watching the video several times, I am seeing the robot slew to one side or the other when it starts moving and when it comes to a stop. This is especially evident when playing the video at half or quarter-speed. This is generally indicative of the two tires losing traction at random. The gyro can only help make corrections after the robot starts moving. It cannot do anything to correct the slewing that occurs when stopping. Depending on how the program is written, after slewing when stopping, the gyro may cause the robot to continue on the wrong heading instead of returning to the correct heading. In any event, there is often some movement to one side as a result of this so even if the robot continues on the correct heading, the path is now offset to one side of the original path. A way of confirming that the tires are slipping is to add a coloured pin on the wheels so that one watch very carefully to see when they do and do not turn.
My sons learned that 100% power should be used with care due to the high probability of the wheels slipping. Sometimes, they start at a lower power level, say 25%, travel for a short distance, then gradually step up to 100% power in several steps to avoid wheel spin.
Last season, both of my FLL teams were experiencing more inconsistency in navigation than when they were using the EV3 the previous season. They both did testing independently and both were able to verify that the wheels with the blue tires have less traction than the wheels with the black rubber tires. Both of them are using different wheels/tires this season and are getting much more consistent navigation. There have been at least one report each week of a problem like this on the FLL facebook page over the last few years.
It is not clear from the screenshot that @veg posted if the axles are supported by the outer structure. My sons discovered years ago that they got more consistent results when the axles are supported at both ends.
In the future, use one centrally located trackball, not two. My sons discovered that the surface the robot runs on is never truly flat. It typically has some undulations in it. The trackballs cause some drag that will cause the robot chassis to turn to the side with more drag. As the robot travels, one or the other trackball will drag more than the other causing a “wandering path”, assuming no gyroscope is being used. While a gyro can help straighten out the path, it is better to start out with as few error sources as possible.
Getting the navigation accurate and consistent is a fundamental skill that is crucial in order to rise beyond the mid-level of competitiveness. Is your team squaring up against walls and mission models as a navigational aide? The flat front and rear of your robot are well suited for that technique.
1 Like
My FLL days were long ago so I’m badly outdated but I’d add to the great comments about wheel mounting, traction, and making sure the wheels are identical with make sure the motors are identical.
I remember two problems
- one motor may noticeably start before the other (coding sequence, for example)
- one motor may be slightly more powerful (or efficient) than the other.
You can get some insight by swapping the two motors in code if possible (A+F → F+A maybe if those are the motor ports?) or swapping the wires to the motors.
after trying the other solutions listed above, it may just be a gyro issue. One way to determine if the gyro itself is drifting is to line the robot up against a solid, flat surface and unplug the gyro. After keeping it unplugged for a few seconds, plug the gyro sensor back in and do not touch the robot for 5-10 seconds. This can reinitialize the gyro sensor and help fix any temporary sensor drift.
Get rid of the blue and white casters. Find, beg, borrow, steal the grey steel ball casters from the EV3.
Whoever green lit the Blue/White casters should craft a hand written apology to every team that used them for the headaches and tears they caused. They are that bad.
We’ll see if that’s your problem but you’ll be better after you replace them trust me.
The gyro is internal to the Spike controller, but gyro initialization errors are a common problem. For the Spike, it is important to set the 'bot on a stable, flat surface when turning it on, and leaving it alone for several seconds or more.
If the gyro doesn’t initialize properly, you will get constant zero readings for roll, pitch, and yaw. We had a simple program to display a smiley face when one of these values was non-zero to test that the gyro had initialized properly.
That could explain why your robot thinks it is driving in a straight line when it is not.
@NellyBoi there are a lot more very experienced Spike Prime users on the "FLL Challenge: Share and Learn " Facebook group.
We had the same issue with some of our teams. You might want to try redeclaring your motors with the set movement motors block after you use the blue motor block.
1 Like
ah, I forgot spike doesn’t use external gyro like previous mindstorms do
thanks! this is the answer to our problem
1 Like