Programming Puzzle

[baronep]

But the problem is that I want the motor to rotate seamlessly through the 5v to 0v. For instance, if it overshoots a setpoint at 4.9 to .1, i don't want it to rotate the rest of the way around, but back up past 5v to 4.9

[Ether]

Originally Posted by baronep

But the problem is that I want the motor to rotate seamlessly through the 5v to 0v. For instance, if it overshoots a setpoint at 4.9 to .1, i don't want it to rotate the rest of the way around, but back up past 5v to 4.9

The canon can turn only so fast. Put rate checks in your code. That will tell you whether .1 actually means .1 or 5.1

BTW, how much of a deadband is there ? You may need to swap out your sensor.

[baronep]

I think you misunderstand. If I was just using a simple comparator like > or < between setpoint and the analog input, and the cannon overshot past the wraparound, how do i force the cannon to go backwards instead of continuing another complete rotation to get back to the setpoint?

[Ether]

Originally Posted by baronep

I think you misunderstand. If I was just using a simple comparator like > or < between setpoint and the analog input, and the cannon overshot past the wraparound, how do i force the cannon to go backwards instead of continuing another complete rotation to get back to the setpoint?

I understood you perfectly clearly. You need to add code to detect zero crossings. You do that with rate checks. If your sensor reads 0.1 in the current iteration, and it read 4.9 in the previous iteration, then the actual reading is 5.1, not 0.1

Can you work from there, or do you need a more detailed explanation?

Again, how large is the sensor's dead zone? You may need a new sensor.

[baronep]

This zero crossing makes sense in theory but I am still unsure about how to implement it.

The dead zone is very small

[EricVanWyk]

It may be easier to think in terms of "difference between where I am and where I want to be", and write as much of your code in that reference as possible. Then you will only have to handle the wrap-around in the one spot where you calculate that value. You will need some if statements and a little bit of math - if it is calculated as past half way around in one direction, map it in the other direction.

[baronep]

I think I found a fix, I found a zero crossing VI that I am going to try and use. Lets see how it works

[Ether]

I don't have LabVIEW here, so I can't say for sure, but I seem to recall that the LabVIEW PID VI has an input where you can tell it that your sensor wraps around, and the VI will handle it for you. Can someone confirm?

[baronep]

I was not able to find that, but maybe i'm missing it.

I have drafted up some code that can (using the pt by pt zero crossing vi) count the number and direction of zero crossings and then calculate an integer for the number of full rotations. After that point, it simply multiplies that number by 5 and adds that to the number that it is receiving from the sensor.

From that, I added PID functionality to control the spinning of the motor.

We will see how it works tomorrow

[plnyyanks]

Originally Posted by Ether

I don't have LabVIEW here, so I can't say for sure, but I seem to recall that the LabVIEW PID VI has an input where you can tell it that your sensor wraps around, and the VI will handle it for you. Can someone confirm?

It doesn't look like this functionality is in any of the PID VIs.

However, there is a separate VI that should be helpful (link) and will return a boolean when zero is crossed. (edit: this VI won't function as I first thought - it'll actually check for when a number goes from positive to negative)

[Ether]

Originally Posted by plnyyanks

It doesn't look like this functionality is in any of the PID VIs.

This is from WPILib. Doesn't LabVIEW have something similar?

/**
 *  Set the PID controller to consider the input to be continuous,
 *  Rather then using the max and min in as constraints, it considers them to
 *  be the same point and automatically calculates the shortest route to
 *  the setpoint.
 * @param continuous Set to true turns on continuous, false turns off continuous
 */

[Ether]

Originally Posted by Ether

This is from WPILib. Doesn't LabVIEW have something similar?

If not, I think this or this would work, where angle error is your desired canon angle (in degrees) minus your sensor reading (converted to degrees).

Then for your PID inputs, use:

setpoint = desired canon angle in degrees

processVariable = setpoint - corrected_angle_error

[plnyyanks]

Originally Posted by Ether

This is from WPILib. Doesn't LabVIEW have something similar?

Not to my knowledge. Here is the manpage for the basic PID VI we're given. Also, none other more advanced PID VIs seem to indicate that this functionality exists, either.

Bummer, because it'd be nice...

Originally Posted by Ether

If not, I think this or this would work, where angle error is your desired canon angle (in degrees) minus your sensor reading (converted to degrees).

Yeah, we've done stuff like this in the past when using sensors that will cross zero. Or, I think the VI I linked in my last post could be good, as well. (edit: no, it won't. see my last post)

edit: here's a VI I quickly wrote up that demonstrates both of the methods Ether wrote up: zero_cross_test.vi

[Todd]

You could also try using a PID to minimize error, rather than reach a setpoint.

IE: Rather than

My setpoint is currently 4.5 my process variable is at .1

Say

My setpoint is always 0, currently my process variable is -.6 (where -.6 is the circular difference between your 'goal' and your 'actual') then when your goal changes, the frame of reference you use to calculate your process variable changes, and your (probably only proportional gain?) controller will move your motor.

[Ether]

Originally Posted by plnyyanks

edit: here's a VI I quickly wrote up that demonstrates both of the methods Ether wrote up: Attachment 12945

Thanks Phil. For any C programmers who may be lurking, here's how to do it in C:

error -= 360*floor(0.5+error/360);

That converts any angle to the equivalent minimum absolute value, with the correct sign.