If X == Range

T Chap

I tried .. to check for a range of vlues but it seems this does work in this instance if x == -10 .. 10.

Is there a faster way in spin to check for a value to fall within a range other than resorting to case X, AND, OR, etc?

CannibalRobotics

If your looking for a deviation from zero maybe there is a clever way to ignore the sign with a bitwise AND. This would be particularly easy if your deviation was a power of two. Then all you would have to do is a bitwise AND of that bit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

Paul Baker

Is there a problem using:

if x => -10 and·x =< 10

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Ariba

How about this?:

  case x
    -10..10: <do something>

Andy

hippy

if ( || x ) =< 10

would be my bet for fastest.

The only way to find out though is to benchmark the various solutions. Just looking at the Spin code or bytecode doesn't give any real indication of how long it's going to take.

T Chap

Thanks guys, I appreciate the ideas. Speed is the concern, so all these will be tested to see what is best.

In a PID loop that is constantly checking an error, I found that the motor required a certain amount of PWM duty (~35) just to move.When attempting to hit a target position there was always overshoot, and often a toggle back and forth over the target, often attributed to integral windup. So instead of trying to reset the windup at the target number, I reset it withing a range of 5 or so, and am eliminating a lot of oscillation and overshoot. There is already a lot of code in the loop that is adding to the problem, so I am looking for faster ways of doing the same thing, if that is possible.

Post Edited (Originator) : 10/25/2008 5:09:15 PM GMT

agodwin

You need a liveband and a deadband.

The liveband is a range of error values OUTSIDE of which the integrator is frozen. This ensures that you don't get it winding up like mad when the error is large : the P term is supposed to predominate in those conditions.

The deadband is a (much smaller) range around error = 0 : the idea is that once inside this range, the integrator is again frozen. This seems odd as the integrator is there to remove small errors, but if you have some stiction the integrator will see the small error, slowly wind up to the point where the motor will move, cause a jump to the other side of the error and repeat in the opposite direction. However, a dead band like this will also forever stop you quite reaching the setpoint so it's best arranged so that you don't stop integrating until you pass error = 0, then stop the integrator until you get outside the deadband in either direction.

Unfortunately, the simple and elegant P+I+D calculation you thought you had is lost in all these cunning tricks. As with most systems, the 'normal' code is only 1/10 of the whole .. the other 9/10 deals with errors and exceptions.

T Chap

I appreciate the info agodwin. I have found that there is much extra code needed for a true motion control system, especially when the encoder res is 1600 a revolution. It has been quite a challenge to park the motor consistently on an encoder line, but I am getting closer. This gives me a new level of respect for the servo amp/motor I am trying to replace with my own system, those guys had it down.

As far as the liveband and deadband, that is sort of what I am creating, a range in which the accumulator is reset, say within 10 lines, I hit the brakes and kill the PWM with a short pause to insure the motor is stopped, then allow the accumulator to start pushing the motor a little closer to the mark. There are so many factors though, the load, friction, PWM period, all play a role in torque at the low speeds, even with a 10:1 gearbox assisting.

"if you have some stiction the integrator will see the small error, slowly wind up to the point where the motor will move, cause a jump to the other side of the error and repeat in the opposite direction."

This is precisely the issue, it takes a certain amount of duty to get the motor to move, below which you just have some noise. The problem is at a low speed, the motor is either on or off, and wants to jump back and forth over the line unless some measure fades the PWM and lets the motor fall near 0. Another problem at this close point, is that the D starts outputting larger values during oscillation, so realistically, there needs to be a deadband for D as well, else it contributes to the jumping.

Paul Baker

While there may be inefficiencies in your algorithm which are contributing to the oscillation, I would experiment more with the D parameter. The purpose of the derivative portion on PID is to "brake" the system as it approaches its target so that it minimizes overshoot. PID is what's known as a damped system (http://en.wikipedia.org/wiki/Damping), what you are experiencing is whats called an underdamped system (ζ· < 1).·Instead of tearing your hair out trying to optimize your code, tinker with the D parameter. While some people say making the system critically damped is the goal (ζ =1), a slightly underdamped system is actually ideal because it reaches target equilibrium faster. The goal is to get·it to overshoot only slightly then return to target and stay there. If you find that changing the D parameter doesn't solve the problem then·perhaps·the D code isn't working properly.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 10/25/2008 10:09:37 PM GMT