PID Without Direction - How?

[LieAfterLie]

I would like to know what the best ways to implement a pid control are when your feedback doesn't include direction. All you have is a setpoint and an interrupt count - you don't know which direction the wheel was spinning when each interrupt was generated, just how many times/how fast it's going.

Obviously you have to assume that the count is in one direction or the other, either in the ISR counter or in the control itself, but this assumption can be taken from a lot of places, such as the direction of the setpoint.

If you do this, without any precautions, then whenever the wheel happens to be spinning backwards faster than the current setpoint is telling it to go forward, the assumption that the wheel is going forward will cause an attempt at correction and end up sending a continuous full reverse signal. (until the setpoint changes to reverse and the direction assumption becomes right)

What are your ideas on the best way to retain full control at slow speeds and still detect/prevent false direction assumption?

I was thinking about a combination of different sources to detect a wrong direction assumption, such as setpoint direction and a sudden change in error and a high D term output and (hopefully not necessary) unchanging extreme total output.

Any ideas or links would be very appreciated, I think this is a very interesting problem and I'm curious about different ways and the best way for us to fix it.

I'm sure other teams have had to get around this somehow, with the gear tooth sensors this year not telling direction.

[114Klutz]

Using GTS, you actually can sense direction - going one direction, the sensor gives a different length pulse then the other, but without using timing, you can simply determine the direction based on the current direction you set the motor to spin at. While not as reliable, it should work well enough.

[Jetweb]

Using GTS, you actually can sense direction - going one direction, the sensor gives a different length pulse then the other, but without using timing, you can simply determine the direction based on the current direction you set the motor to spin at. While not as reliable, it should work well enough.

we have been using this method for years on our team but this years geartooth counters are only single direction and the pulse width is the same in both directions :mad:.

we just decided that +/- 6 inched was good enough on distance and used gyro for going streight . When you have a 40 In. target we dident have a problem hitting it with this method but its still not as accurate as in the past

[Qbranch]

Well, if you're worried about the robot going backwards, limit the reverse power output of the PID to a number too low to actually cause reverse robot motion.

-q

[LieAfterLie]

Well the same thing applies in the forward direction. I was just contemplating the results of misjudging the direction of the feedback. If it's less than the setpoint and assuming the wrong direction, then the output will tell it to go faster, actually making it go slower and towards the real setpoint (even if in a more uncontrolled manner, going faster and faster until the assumption is correct). If it's more than the setpoint, it'll go the other way and won't stop, which is more of a problem, although being able to detect a wrong direction in either of these circumstances is better.

[The Lucas]

Are you looking for an alternate way to determine direction or do you want to leave direction completely out of it?

As far as alt forms of direction sensing goes, you can use
current output value to motor - motors running forward generally drive/coast forward till reverse is applied
accelerometer - if external force (crash) is applied you can sense its direction
(speed) rate of GTS/encoder pulses - definitely a stretch, but if you have speed you can make some assumptions that are generally correct under normal circumstances
gyro

a combination of these sensors and some (reasonably complex) code should be able to determine direction.

[JBotAlan]

Our team is just flat-out shutting the motors off once we are at/past our goal--if the feedback loop is tweaked well, you will settle in pretty closely and a bit of overshoot should not hurt anything.

As far as assuming direction, I don't think so. I can't honestly imagine software being useful here. If you absolutely need direction, you might consider using an encoder instead.

JBot

[intellec7]

Some careful positioning might allow you to align two GTS for quadrature output. You'll probably need to use an oscilloscope to visualize the position.