Welcome to the Parallax Discussion Forums, sign-up to participate.

# Encoder position status

Posts: 18
Hi Guys!

I need a little help figuring this out:

I am working on a cablecam project, where I have an encoder riding on the rope/cable of a cable camera. As the rig drives down the cable, the encoder is counting and keeping track of the position along the length of the rope. I also have a provision for the user to manually Set A and Set B points on the cable that are safe zones to keep the unit within these zones.

The total cable run of 1000' provides 400,000 impulses from the encoder. (about 400 pulses per foot) When the rig is within 25 ft (10,000 impulses) of the Set A or B, I need the servo output set to 1500 uS so the unit will stop and then manual control (the opposite direction) can resume after the position variable remains the same for a few passes of the program. (showing that the rig has stopped)

In this code I just made the rig pass the Set point, slow down to idle and slowly return to the Set point. Then they can resume full control. This is working OK, but its not efficient when trying to get an important shot quickly...

pub process_encoder

if(setA > 0) ' push Set A button to read & store (near) position
stopA := position

if(setB > 0) ' push Set B button to read & store (far) position
stopB := position

if(reverse == 1) ' if reverse switch is activated
if(position < stopA) ' if position passes stopA stop
outcservo := 1600
elseif(position > stopB) ' if position passes stopB slow down
outcservo := 1400
else
outcservo := cservo

else ' if reverse switch is not activated
if(position < stopA) ' if position passes stopA slow down
outcservo := 1400
elseif(position > stopB) ' if position passes stopB slow down
outcservo := 1600
else
outcservo := cservo

John

• Posts: 1,761
"Not efficient" in the sense that you would like to able to trigger at an exact encoder count?
• Posts: 18
The current way the code operates is inefficient because if you enter the ‘zone’ at full speed then the unit slows down to a stop then reverses and slowly backs up to the Set point. At a full speed overrun, this would take some time before returning control back to the operator.
• Posts: 1,761
If I understand correctly, then ideally, you would prefer not to overshoot in the first place but actually stop dead on the set point(?) Please see the attached .pdf
• Posts: 6,998
edited 2019-07-27 - 18:52:30
Going from point A to point B without problems -- as taught to me by Peter Montgomery -- works like this:

-- Ramp up to desired max speed
-- Note delta between current position and half-way point of move
-- Continue to mid-point at max speed
-- Run delta (second half of move) at max speed
-- Ramp down
-- Adjust ramp as you get very close

I used this strategy in Camera Turret products and it worked very well.
• Posts: 4,035
PID is ideal for very accurate positioning. This is not trivial. An alternative I have used is to always check the position while moving. If the DestinationPosition - CurrentPosition is less than X, change speed to Lower speed or crawl speed. Then if there is overshoot it is done at a much lower speed. For deceleration you can switch over to a ramp down loop for the remanding distance once you are within range. Ie repeat while currentposition < destinationposition and during this loop ramp the speed down incrementally to a crawl. The lowest speed (min speed) being the minimal value of power the motor needs to actually produce movement (slowest speed).

• Posts: 22,754
edited 2019-07-29 - 17:23:57
I've always used something like this to set the current speed with ramping:
```speed := ramp_rate * (||(position - start_position) <# ||(position - end_position)) <# MAXSPEED #> MINSPEED
```

Speed is always a positive number. Velocity includes a direction component, given by the sign of position - end_position. Also, unless MINSPEED is zero, you will need a separate check to see if position is close enough to end_position to set speed to zero.

-Phil
• Posts: 1,761
T Chap wrote: »
PID is ideal for very accurate positioning. This is not trivial. An alternative I have used is to always check the position while moving. If the DestinationPosition - CurrentPosition is less than X, change speed to Lower speed or crawl speed. Then if there is overshoot it is done at a much lower speed. For deceleration you can switch over to a ramp down loop for the remanding distance once you are within range. Ie repeat while currentposition < destinationposition and during this loop ramp the speed down incrementally to a crawl. The lowest speed (min speed) being the minimal value of power the motor needs to actually produce movement (slowest speed).

PID... Agreed...but coupled with the discreetized profiling, per the document I posted will provide velocity control under varying load conditions.

• Posts: 4,035
One thing you can do is watch the encoder and see how consistent and predictable the travel is when you kill the motor. If it is pretty consistent you could kill the motor X pulses short of the full distance to travel and avoid overshoot, basically attempt to land on the destination vs go past it and reverse.
• Posts: 1,761
• Posts: 3,246
Mickster wrote: »

nice

Mike
• Posts: 1,761
Thanks, Mike.

Client was Jaguar Land Rover.

Siemens control died and no longer supported. Machine was in great shape. A replacement would have been \$200K.

I saved them a bunch