Announcement

Collapse
No announcement yet.

Control Hub strangeness with encoders

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Control Hub strangeness with encoders

    I have two physically identical pushbot style robots, one using phone controller and one using a control hub. I am on 5.2 SDK and testing a body of code proven to work on the phone controller on the control hub to see if there are any differences/problems. The control hub is new and fully updated. Been going ok until I reached encoders. I am seeing two issues:

    1) The speed at which the motors run in RUN_TO_POSITION mode is quite a bit faster on the control hub robot. I can take the same code deploy to both the phone and the hub and the hub robot moves quite a bit faster for my 25% power setting. Seems more like 50-60%. When not in RUN_TO_POSITION the power setting works as expected on the hub robot. Perhaps this is due to the changes in 5.2 having to do with PIDF being used for run to position but this much difference from expected speed is not what one would expect.

    2) When I set a target position and RUN_TO_POSITION mode and run while motor isBusy() is true, the robot never stops. I monitored the encoder count while travelling and the sign of the encoder value is incorrect (opposite sign of target position value). I assume that is why the motor never stops. Again, same code to the phone controller works as I expect.

  • #2
    Originally posted by Crossle86 View Post
    I monitored the encoder count while travelling and the sign of the encoder value is incorrect (opposite sign of target position value). I assume that is why the motor never stops. Again, same code to the phone controller works as I expect.
    This is a hardware problem. Your A/B channels on the encoder wire are swapped. AndyMark has been known to sell cables with the channels swapped before. You can either manually reorder the pins in the connector, or you can simply cross the PowerPole connections going to the motor (red->black and black->red).

    Comment


    • #3
      Correct answer. It was a wiring issue. All good now.

      Comment

      Working...
      X