Rotation Sensor Reset Issue (Okapilib)

Programming Support PROS Support
, ,
1

Issue: attempting to reset an Okapilib rotation sensor works for a few milliseconds, but after that returns to its original value.
Relevant parts of code:

RotationSensor odomL(11);
RotationSensor odomR(12, true);

shared_ptr<OdomChassisController> chassis = ChassisControllerBuilder()
.withMotors(1, 2, 3, 4) //I don't use these anyways for now
.withDimensions(AbstractMotor::gearset::green, {{4_in, 10_in /*doesn't matter*/}, imev5GreenTPR})
.withSensors(odomL, odomR)
.withOdometry({{2.75_in, 2.25_in}, 360 /*?*/})
.buildOdometry();;

void initialize() {
    odomL.reset();
    odomR.reset();
}

void opcontrol() {
    chassis->setState({0_in, 0_in, 0_deg});

    while (1) {
        auto state = chassis->getState();

        cout << state.x.convert(inch) << " " << state.y.convert(inch) << " " << state.theta.convert(degree) << " | " << odomL.get() << " " << odomR.get() << "\n";

        pros::delay(5);
    } 
}

The output:

0 0 0 | 0 -0
0 0 0 | 0 -0
0 0 0 | 0 -0
0 0 0 | 0 -0
0 0 0 | 0 -0
0 0 0 | 0 -0
0 0 0 | 0 -0
0 0 0 | 222.45 -212.34
0 0 0 | 222.45 -212.34
-0.0258316 0.0280807 265.222 | 222.45 -212.34

and from there on, all of the lines are -0.0258316 0.0280807 265.222 | 222.45 -212.34 (I’m not moving the sensors). This behavior isn’t consistent though, and sometimes it prints out 2.69346 2.64069 265.222 | 222.53 -212.34 (the slightly different left odom value probably comes from the fact that I bumped the robot, but doesn’t change anything). I believe these are the only two “options”. I used to think it alternated but that doesn’t actually seem to be the case.
Notes:
Moving odomL.reset(); odomR.reset(); to the start of opcontrol() (right before setting the state) doesn’t change anything.
Changing the initial state more or less works as you’d expect: for example, if we start with 5_in for the x-value instead, the states printed out will either have x-value 7.64... or 4.97.... Degrees work the same way.
Both the rotation sensor values and the odometer state seem to update accurately when I do move the robot.

Anyone know why this is occurring? (Also, while we’re here: is using 360 in the .withOdometry() correct? Edit: looks like 360 is correct?)

2

An update: I tried doing the same thing with pros Rotation sensors, and the same issues are occurring. reset_position(), reset(), and set_position(0) all behave in the same way: the values of get_position() and get_angle() are correctly zeroed at first, but then revert back to the values you’d see in the brain’s “Devices” menu (that is, the behavior of the pros and okapilib rotation sensors are the same)

3

Second update:
For whatever reason, putting a 100ms delay at the end ofinitialize()correctly sets the chassis state to (0, 0, 0). This works if chassis->setState(whatever) is kept where it is or placed after the delay, but not before. However, the actual values of odomL.get() and such are still printing out the “Brain values” (which occurs both when I put the resets before the delay, after the delay in initialize, and at the start of opcontrol). It seems to work so this isn’t going to be a huge issue (and if I want to write a custom odometry system I can always just subtract the starting position), but I would still appreciate an explanation/fix for the actual values.

4

A few questions:

  1. What happens if you bump the wait to 20msec?
  2. Are you running a calibration routine to ensure any sensor drift is accounted for?

I know that when I was helping my kid troubleshoot an issue last year (granted, using Blocks), the only thing that consistently solved the problem was having a 20msec+ delay. I’m assuming this is giving enough time for the underlying OS to go around and service a new read. This somewhat lines up with your 100msec delay at the end of initialization.

5

I tested both 20ms and 30ms (I saw 30ms being mentioned as a calibration time somewhere) and both had original behavior (nothing works), but at 100ms the odometry state works fine, just not the actual sensor values.
I don’t have any calibration routine. Right now the sensor values being printed don’t drift if I’m not moving the robot, instead staying at their (incorrect) values.

6

Would recommend you to ask this on the vex discord. The okapilib devs are in the server and it’s probably easier to ask them directly.