for faceuphill function, the coding is suitable for zumo32u4 with 75:1 hp, but I’m using 50:1. slight changes have to be done on the turnspeed. Can someone explained to me how to change it based on the encoder?
Hello. How well does the unmodified code work for your Zumo 32U4 with 50:1 motors? I suspect that the easiest way to account for the difference in gear ratio is to modify the turnSpeed equation and/or update maxSpeed. Can you get the program to work with your Zumo32U4 if you try adjusting those two parameters?
Modifying the FaceUphill example to use a different control scheme will be hard. If you want to try it though, I would suggest that you measure the angle you want to turn using the accelerometer while the robot is at rest, and then use the gyro to turn by that amount. Our MazeSolver example shows how to do turns using gyro feedback, though it also uses the line sensors at the end of the turn. We have not tried this so we do not know how well it would work, but we would be interested to hear what you come up with.
–David
I’ve tried changing the equation of turnspeed but the motor movement is not as efficient as using 75:1 HP. as for the maxspeed, is it possible for any value, or it depends on the motor used?
thank you for the reply, i’ll try the methods that you’ve suggested
What equation for turnSpeed did you try, and what do you mean by “not as efficient as using 75:1 HP”?
In the “What you will need” section of the Zumo 32U4 user’s guide, there is a table listing the top speeds of Zumos with different gear ratios (under specific conditions). The table indicates that a Zumo with 50:1 HP motors moves about 1.6 times faster than a Zumo with 75:1 HP motors, which is what we would expect since the gear ratio is smaller by a factor of 1.5.
So if you want your Zumo to run at the same speeds as the 75:1 HP Zumo that the FaceUphill example was developed for, then it seems to me like a good first step would be to reduce all of the motor speeds in that example by a factor of 1.5. So I would change maxSpeed from 150 to 100, and change the turnSpeed value from y / 16 to y / 24.
Please let me know what you come up with. If you can get it working, it would be nice to see the final code and a video of the robot in action. If you can’t get it working, the code and video would be useful for troubleshooting.
–David
1 Like
Can I know how do you get the feedback algorithm,
y / 16.
From where the value 16 come?
and also… are you using pyhthagoras theorem to calculate this?
16384 * sin (5 deg) = 1427
Is it 16384 is the hypotenuse ?
From what I understand, 16384 is equal approximately to 1g …
How come it become the hypotenuse ?
Thanks in advance…
The value 16 in turnSpeed = y / 16 came from trial and error. I tried different values until I found one that worked.
Yes, you can think of 16384, which is the downward acceleration of gravity, as the hypotenuse of a right triangle: the two other sides of this triangle the acceleration the Zumo measures in its z-direction (a_z) and the acceleration it measures in its plane of motion (a_{\rm tilt} = \sqrt{a_x^2+a_y^2}).
If the Zumo is on a flat surface, a_z = 1 \,\rm g and a_{\rm tilt} = 0. (Those equations are approximations that ignore contributions to the accelerometer reading that come from movement of the Zumo, and also ignore any inaccuracy in the accelerometer.) As the surface tilts, a_z will decrease and a_{\rm tilt} will increase. I needed to put an arbitrary threshold on the tilt angle before considering it tilted enough to attempt to turn. I picked 5° as the threshold, so the corresponding limit on a_{\rm tilt} is 16384 * \sin(5°), which is about 1427.
Note that it would not work well to put a limit on a_z, since that would involve a cosine function, which does not change very much for small angles. Also, while you could do trigonometry to directly calculate the tilt angle, you don’t actually need to do it for this application, and it would probably take up a lot of program space and time because floating point computations are expensive on 8-bit AVRs.
–David
1 Like
Hello,
can you explain me how the feedback algorithm works. I dont understand why we use the y-readings to define our turnSpeed??
Thanks in Advance
Hello.
In the FaceUphill example for the Zumo 32U4 Robot, the y variable holds the Y component of the accelerometer reading. If the robot were in a free fall, the accelerometer reading would be zero, but since it is sitting on a surface and resisting the pull of gravity, its accelerometer measures an upwards acceleration (away from the Earth).
The axes used by the accelerometer are shown in labels on main control board of the Zumo 32U4. If you look there, you can see that the Y axis points towards the left side of the robot.
If y is positive, it means the Zumo is experiencing some acceleration in the positive Y direction, which means that its positive Y axis is pointing (partially) upwards, which means that its left side is higher than its right side. Therefore, in order to point uphill, it needs to turn towards the left.
Similarly, when y is negative, it means the left side is lower than the right side, so it needs to turn towards the right.
The equation turnSpeed = y / 16 implements both of those behaviors, and it also causes the Zumo to slow down its motors when it gets closer to facing uphill. This is an example of proportional control.
–David