Simplified FTC Odometry. Part 1: Overview

[@cantthinkofaname1029]

This is one of the tutorials of all time

[@zwesterful]

How do you have 4 motor encoders and 2 odometer pods plugged into motor encoder slots simultaneously?

[@GEARSinc]

You can't have 4 motor encoders and two odometry pods plugged into ONE Control hub. You either need to add an expansion hub (to get 4 more encoder inputs), or some other device, like an OctoQuad to get 8 more encoder inputs. If you ONLY have ONE control hub, then you need to run your motors in RUN_WITHOUT_ENCODER mode, (which does not need the encoders plugged in, which is the default) rather than "RUN_USING_ENCODER" (which I normally prefer). This way you have acess to all 4 encoder ports.

[@dakuucgt]

Mr Phil we are having a problem. We tried to use your sample code as a basis for our code and it didn't work 100%. We are using it for a basic linearopmode autonomous similar to the sample one, with added motors and movements. Sometimes the robot doesnt drive when told, and sometimes other motors that have nothing to do with your odometry class wont respond either. After researching online, we found that multi-threading is not compatible with the control hub because it only takes input from one thread at a time. Do you think this is the reason for our issues, and do you know how we could get around this?

[@GEARSinc]

Hi. Not sure why you mention Multi-Threading. Certainly my tutorial code does not do that. My first question would be: Does my tutoral code work for you BEFORE you add any extra functionality? Certainly I would try to get it running with as little modification as possible, and then archive that code before you start adding more functionality. As for multi-threading.... I've been programming with FTC since 2008, and I've NEVER needed to do multi-threading. Some folks use multi-threading to perform simultanious actions on multiple subsystems, but I have found that it's more reliable to build a simple State Machine for Telop actions. You need to make sure you don't add any sleep() commands or "while loops" that can disrupt regular driving loops. If you wanted to share a link to your code, and describe a specific issue (when things stop running) I'd take a look at it.

[@dakuucgt]

@GEARSinc how would we go about setting other motors to set positions without using while loops?

[@GEARSinc]

@@dakuucgt One way would be to put the motor in RUN_TO_POSITION mode. Then when you call setTargetPosition() the motor will just go there and stay there. If you don't like that, then you need to add some code that gets executed every time the main while loop. This code will read the current position and set the power to move the motor to the desired "setpoint" position (a basic proportional controller). For teleop, this control code would get called once every control cycle. For auto, you would need to call this code from inside the drive, strafe or turnTo methods. Make one function that controls all your other motors, and just call that function in whatever code is already looping.

[@kobsboy4227]

thanks unc

We are trying to build a method to drive the robot in a 45 degree strafe while holding heading. Is it possible using only 2 deadwheels? Here is what we are thinking:
/*FORTY FIVE TRY*/

public void fortyFive(double distanceInches, double power, double distanceInches, double power, double holdTime) {
resetOdometry();
driveController.reset(distanceInches, power); // achieve desired drive distance
strafeController.reset(distanceInches, power); // achieve desired strafe distance
yawController.reset(); // Maintain last turn heading
holdTimer.reset();
while (myOpMode.opModeIsActive() && readSensors()){
// implement desired axis powers
moveRobot(driveController.getOutput(driveDistance), strafeController.getOutput(strafeDistance), yawController.getOutput(heading));
// Time to exit?
if (driveController.inPosition() && yawController.inPosition()&& (driveController.inPosition()) {
if (holdTimer.time() > holdTime) {
break; // Exit loop if we are in position, and have been there long enough.
}
} else {
holdTimer.reset();
}
myOpMode.sleep(10);
}
stopRobot();
}

[@GEARSinc]

Yeah, that looks good. It just assumes that both axes will try to get to their destinations at the same rate. The 45 angle may not be perfect, but it's worth a try to see what the path looks like. Since we are using the Gyro to maintain the heading, two Deadwheel modules are all you need.