Encoder position status

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

position := encoder.read(0) ' sample encoder position reading

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

Comments

  • "Not efficient" in the sense that you would like to able to trigger at an exact encoder count?
    Failure is not an option...it's bundled with the software.
  • 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.
  • 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
    Failure is not an option...it's bundled with the software.
  • JonnyMacJonnyMac Posts: 6,221
    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.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • 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).

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,391
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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.

    Was just asking about you in another thread :smiley:
    Failure is not an option...it's bundled with the software.
  • 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.
  • Failure is not an option...it's bundled with the software.
  • I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • 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 :wink:
    Failure is not an option...it's bundled with the software.
Sign In or Register to comment.