Bosch Seat Motor internal hal sensor track direction?

[cpapplefamily]

I have been trying to get a counter to track the direction. It seem that all the configurations of the counter object want an input for up/down mode not an internal Boolean. Thing is we don’t need a huge amount of acraccy here just sort of want to know with out adding a potentiometer or other more complicated feedback source. Here are some code snips:

Subsystem:
package org.usfirst.frc3244.FloorPick.subsystems;

import org.usfirst.frc3244.FloorPick.commands.*;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;
import edu.wpi.first.wpilibj.command.Subsystem;
import edu.wpi.first.wpilibj.Counter;
import edu.wpi.first.wpilibj.Spark;

public class CargoFloorPick extends Subsystem {

    private Spark speedController1;
    private Counter seatSensor;
   

    public CargoFloorPick() {
        speedController1 = new Spark(0);
        addChild("Speed Controller 1",speedController1);
        speedController1.setInverted(false);
        
        seatSensor = new Counter(0);
        seatSensor.setUpDownCounterMode();
    }

    @Override
    public void initDefaultCommand() {
        setDefaultCommand(new CargoFloorPickJog());
    }

    @Override
    public void periodic() {
        // Put code here to be run every loop
        SmartDashboard.putNumber("Seat Counts", my_GetSeatSensor());
    }

    public void my_Jog(double speed){
        speedController1.set(speed);
    }

    public int my_GetSeatSensor() {
        return seatSensor.get();
    }

    public void my_setReverseDirection(boolean r){
        seatSensor.setReverseDirection(r);
        SmartDashboard.putBoolean("Dir", r);
    }
}

Command:
package org.usfirst.frc3244.FloorPick.commands;

import edu.wpi.first.wpilibj.command.Command;
import org.usfirst.frc3244.FloorPick.Robot;

public class CargoFloorPickJog extends Command {

    public CargoFloorPickJog() {
        requires(Robot.cargoFloorPick);
    }

    @Override
    protected void initialize() {
    }

    @Override
    protected void execute() {
        double power = -Robot.oi.joystick1.getRawAxis(1);
        if (power>0){
            Robot.cargoFloorPick.my_setReverseDirection(false);
        }else{
            Robot.cargoFloorPick.my_setReverseDirection(true);
        }
        Robot.cargoFloorPick.my_Jog(power);
    }

    @Override
    protected boolean isFinished() {
        return false;
    }

    @Override
    protected void end() {
    }

    @Override
    protected void interrupted() {
    }
}

[ngreen]

The docs seem to say that the reversing the direction is for quadrature encoder (1x, 2x). So I don’t think that will work.

I don’t have a full answer for making it work. I did prefer using motor controller voltage for knowing the direction the motor is supposed to be moving (rather than the joystick signal). You’d have to use get voltage from a Talon or Victor (Spx).

I also, think setting an up down mode is not right. The up counter is started in the line above that, and you wouldn’t have a down source.

[cpapplefamily]

In this condition we are using a “dumb” PWM motor controller. If we are going to throw smarts at it then a more traditional feedback device would also be added. We are not at the bleeding edge of the CAW so a $90 SRX would not break the budget. I came here because it feels like I might be missing something. but as it stands it looks as if the base counter class and GearTooth counters can only count up.

[gixxy]

My idea is totally un-tested on how accurate it would be, or how badly it would drift, but what I wanted to try was to track the count/angle by getting the difference in count each loop and checking the direction from the motor controller object’s power. Then assume if the motor controller is at neutral, it must be gravity pulling down.

Here is the main snippet from my POC code

    int count = counter.get();
    int delta = count - lastCount;
    lastCount = count;

    double deltaAngle = delta/gearRatio*360;
    // Movement at zero mean falling
    if(motor.getSpeed() >= 0) {
      angle += deltaAngle;
    } else {
      angle -= deltaAngle;
    }
    return angle;

[JohnD]

The single Hall-effect sensor in the motor doesn’t report direction, only motion. As stated above, you need to reference your drive voltage polarity for direction.

This gets tricky if you stop on an edge of the sensor. It might bounce back and forth between active and inactive (others can chime in here, I don’t know how much hysteresis the Bosch sensor has). The trick is to ignore encoder changes when your drive voltage is below a threshold where you know the motor is not spinning.

We started on this path last year but ended up not needing the encoder so I don’t know what the next level of issues are. We might take this up as an off season project. .

[cpapplefamily]

The more the discussion continues about the hall effects sensor the more following this parth seems unreasonable.