Programming Puzzle

[baronep]

So I am trying to solve a programming problem that we are having with our T-Shirt cannon.

We have an analog rotation sensor that, as the cannon rotates a full rotation, the analog signal changes between 0 and 5V (linearly).

My question is how I should deal with the transition between 0 to 5 volts in code. I want to be able to index the cannon so that it will snap to a position every 1/6th of the rotation. How should I do this?

[Chris Hibner]

1) Measure how much rotation (in degrees) you get from 0 - 5 V of your sensor. Specifically, at 0 V, set the protractor to 0 degrees. Turn your cannon to the 5V reading and read the angle on the protractor.

2) Calculate the conversion factor from voltage to degrees. Let's say in step 1 you determined that at 5 volts the angle was 270 degrees. Then your conversion factor is 270 degrees / 5 V = 54 degrees/V

3) Now in LabVIEW, multiply your sensor reading (0 - 5V) by the conversion factor calculated in step 2. This will tell your code the angle of your cannon in degrees.

4) Use a PID loop to command your motor to any angle (in degrees) you want your cannon to shoot.

[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

[billbo911]

Originally Posted by Ether

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.

I believe Ether is alluding to the portion of the rotation where the pot has no reading. Many pots only read in a 270 deg. range. This leaves 90 degrees of rotation unaccounted for. Even continuous rotations pots suffer from some amount of non-sensing.
You may want to look into a absolute position encoder if your pot just doesn't work out.

[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