prosv5 gyro value is 0-360
In my architecture, I recalculated the angle of change for each LOOP.
If the robot makes a circle, the integral value will change to a maximum of 360.
How to solve this problem?
In practice, I input 180 degrees. The robot will keep turning around.
What if you don’t want to use gyro. reset ()?
What is your code? Are you targeting ==180 instead of <=180, for instance?
I haven’t use this. As for the maximum of 360 degrees, does it doesn’t automatically drop to 0 and start counting up again when you pass it? If so, no problem, it’s just not putting you in different Riemann sheets. Then you just turn to the facing you want to hit. If it hits 360 and gets stuck there, that’s a whole other issue.
Only two things are jumping out right away to me.
One is that, depending on the timing, you could entirely miss fabs(idegTarget - angleChange) <= atTargetAngle. I would expect this wouldn’t be a problem since you’ve got a whole degree (from ±0.5 degrees to the other of ±0.5 degrees) of leeway and you’re using PID so it should be turning more slowly at that point.
The second is related. You’re waiting 0.250 seconds after reaching your target before exiting the loop. Why are you waiting so long? Depending on what’s going on with your PID loop (specifically thinking about the integral part blowing up), you may well set a hard mark and then clear it before exiting the loop, even if you properly set the hard mark in the first place. This leads me to wonder why you’re bothering with that “else” to clear the hard mark anyway. It seems like you’re coding it so that if you overshoot a little, you’ll make sure you completely overshoot. Does it work fairly well if you comment out the “else” bit? That could be a quick way of telling if you’re accidentally removing the marker you wanted to identify.
Use
std::atan2(cos(angle), sin(angle))
to move angle to -180, 180].
That’s the problem here. fabs（idegTarget - angleChange）<= atTargetAngle
So I don’t want GYRO to reset to 0 automatically.
I wrote an odometer, which requires high angular accuracy. So wait a little longer before jumping out. I don’t like to use autonomous step by step. I hope to use algorithms to let him automatically judge what to do.Especially now we have vision sensors.
I used this function in the odometer. But the calculation should be 180 degrees…
void rotatePid () is the final execution function.
I get that. I wasn’t saying you should reset it to 0. You’re saying you’re overshooting. I’m asking about the PID potentially not going letting the robot rotate slowly enough as you reach the target so that the 0.250 s delay between reaching the target and actually exiting the loop results in erasing the exit. If you weren’t using fabs(), but instead had two checks, one <= and one >=, depending on which direction the robot is rotating, this wouldn’t show up as a possibility. But with fabs()<= it does show up as a possibility.
Essentially, you’re guaranteeing that if you’ve got some sizable value stuck from the integral part of the PID that there is no way the robot will stop rotating. And you’re saying it doesn’t cease rotating. So this seems to me to be a good place to look.
Have you tried commenting out the “else atTargetTimer.clearHardMark();” part? I would try that and see where the robot stops. This way, even if it overshoots, it should still stop so long as it has spotted a moment when it was within 0.5 degrees of your goal.
.
Oh, also, that fabs() bit doesn’t behave the same around ±180 degrees as everywhere else. You could throw in an if statement so that if you’re targeting around ±180 degrees, it’s more like fabs(fabs(idegTarget) - fabs(angleChange)). That’s because you want it to read -179.9 degrees as 0.1 degrees away from +180 degrees, while right now you’re reading it as 359.9 degrees away.
@callen Thank you.
I’ll wait for the government to come up with a function without upper and lower limits. I think your method is effective. But I can’t say that to the students. I always emphasize that robotic learning is the application of mathematics and science. It’s not in line with the spirit of science…
Glad I could help. Sometimes it’s just a fresh pair of eyes looking at something.
Yes, you’re right, there is a big difference between science and engineering even though we so commonly lump them together and they share a lot. Similarly, there is a big difference between being an engineer and being a mechanic despite a similarly large overlap in understanding and subject matter.
Haha. If you mean the rollover at 360 deg, I’ll have a look in the new year and see if we can remove that limit. I set it up that way as that’s what ROBOTC did, nobody anticipated so much use of the old gyro so we didn’t give it too much attention, I will make another pass and see if we can improve for vexos 1.0.6
If there were a V5 gyro like the IQ gyro, we would probably have moved on from the old one a lot faster.
thank you.It’s really good news.
OMG Yes please. Dealing with the rollover and switching from positive to negative values is annoying!
Might I suggest a couple of different modes?
Thanks for being proactive with this while we all wait with bated breath for the new fangled V5 sensors.
This is a good idea. It’s probably nearly what’s done anyway, just giving access in the middle as well as after restricting the range, instead of only after restricting the range.