Calling forward(30) should make the Zumo32U4 go forward 30 cm. It does go forward 30cm, but after that it gets stuck in this function and doesn’t move onto next function.
What’s wrong with my function to make my Zumo32U4 go 30 CM forward? Why does the robot get stuck in this function when it’s called after going 30 cm forward? It makes a humming sound after going 30 CM.
I am sorry to hear you are having problems with your Zumo 32U4. Could you post a copy of your complete code (ideally, the simplest complete code that still demonstrates the problem)?
Thanks for your response. I have fixed my problem but I have another question.
As of now, my Pololu Zumo32U4 turns 90 degrees based on its gyroscope. I want my turns to be accurate, as this is a competition robot. Aside from the gyroscope, what is another data point I could use to ensure my robot has actually turned 90 degrees.
How could I use data from the encoders, or the magnometer to ensure my robot has actually turned 90 degrees? Are there any Pololu libraries that simplify this for me?
As far as 90-degree turns, you could try using the encoders, which will allow you to monitor how far each motor has turned; however, with tracked robots like this, turning generally involves the treads slipping, which results in less accuracy and repeatability (especially as the tracks get dirty).
We use the gyro in our MazeSolver example program. Are your turns using the gyro not accurate enough? There are techniques to use the magnetometer in combination with the gyro to account for drift and make it more accurate over time; however, those are typically not necessary for doing a simple 90-degree turn (and using the magnetometer has its own challenges like calibration and accounting for magnetic interference).
Your point about the tracks being dirty is likely why my robot’s 90 degree turns are not always on point when the gyro is used. The other thing messing up the turns is the fact that the robot doesn’t go straight when both motors are given the same speed. This is likely because one motor has more wear on it than the other one.
Is there a code segment which uses data from the encoders to make both motors spin at the same speed and keep the robot straight?
Slipping tracks should generally have much less of an impact on your turning when using the gyro compared to using the encoders, but cleaning them is worth a try (some isopropyl alcohol on a rag usually works well). Similarly, since the gyro is measuring the rate of rotation, the impact from unit-to-unit variation of your motors should be minimal. Depending on how mis-matched they are, you could start to notice that your robot doesn’t pivot perfectly around its center.
We do not currently have any code examples for doing closed-loop speed control of the motors, but to do something like that you would generally use something like a PID controller for each motor. This PID speed control tutorial on YouTube is a good starting point for learning how to do that. An alternative that is less elegant but much simpler might be to calibrate for the difference by empirically finding an offset between the two speeds for your particular combination of motors.
By the way, depending on your application, there might be other ways you could improve your turns; for example, if you’re following a line, you could have the robot turn until it detects the line in the center of the sensor again.
I decided to calibrate for the difference by finding the offset between both of my motors. The calibration went very well.
But the issue of inaccurate turns persists. I notice that with each subsequent turn, the degrees turned by the robot increases above 90 degrees. Additionally, I found that when only one track spins to turn the robot, and the other track is stationary, and the center of rotation, that’s when the robot achieves its best turn accuracy. Could these observations be attributed to dirty tracks?
My function to move the robot forward uses the gyroscope to ensure it goes in a straight line. Could this be interfering with the gyroscope readings for the turns? Could the fast velocity and hard stopping of the robot before turns contribute to the gyroscope being slightly off before turns? I can add a delay between when the robot stops moving and when it starts turning.
Using the gyro should generally work very well for doing 90 degree turns. From your description of the turns getting worse with each subsequent turn, it sounds likely that it is an issue with your program. Could you post a copy of your complete code that demonstrates the problem? A video showing the issue could also be helpful. The forum does not allow very large videos, so you might need to post it to a video hosting website (like YouTube or Vimeo) and link it her.
Thanks for offering help. The problem with my robot was that the right motor started up a little bit before the left motor, causing deviations from a straight path. That’s why 90 degree turns did not appear to be 90 degrees.
I do have another question for you. I need the proximity sensors to update within a few milliseconds and be as accurate as possible. What values of
should I use in my code to make the sensors update to their most accurate values as soon as possible? How can I get the most IR pulses from sensors within a few milliseconds without compromising accuracy of readings?
We already tried to optimize the default values of those parameters, so it might be hard to find anything that results in more range (but if you do, we would be interested in hearing about it). You can read the documentation on some of them here for more information.
As for the brightness, I expect your particular environment to be a key factor involved, so I suggest trying to do some empirical testing in the actual surroundings you plan on using the robot in.
One of the IR LED’s on my robot got damaged. Does Pololu sell spare IR LED’s for the Zumo32U4? If so, please send a link on where to purchase them? Can I use aftermarket IR LED’s for my robot?
There are a couple different IR emitters used on the Zumo 32U4 Robots. Just to be clear, are you referring to one of the forward-facing through-hole ones? Please email us with your order information, a reference to this thread, and a picture of the problem.
Could you please provide the specifications of the IR LED’s that came with the robot (the white ones, not the blue ones). For example, what is the wavelength (in nanometers) of the provided white IR LED’s?
