Okapi: Not Expected Outcome

Programming Support PROS Support
#1

Hello! I am trying to use Okapi this year and I am stuck on what I need to do to fix my program. It is suppose to move forward 1 foot and it does this:
Demo video
This is my code:

void autonomous() {
	std::shared_ptr<OdomChassisController> chassis =
	ChassisControllerBuilder()
	    .withMotors(20, -15, -1, 8) // left motor is 1, right motor is 2 (reversed)
	    .withGains(
	        {0.001, 0, 0.0001}, // distance controller gains
	        {0.001, 0, 0.0001}, // turn controller gains
	        {0.001, 0, 0.0001}  // angle controller gains (helps drive straight)
	    )
	    .withSensors(
	        ADIEncoder{'A', 'B'}, // left encoder in ADI ports A & B
	        ADIEncoder{'C', 'D',true}  // right encoder in ADI ports C & D (reversed)
	    )
	    // green gearset, tracking wheel diameter (2.75 in), track (7 in), and TPR (360)
	    // 1 inch middle encoder distance, and 2.75 inch middle wheel diameter
	    .withDimensions(AbstractMotor::gearset::green, {{2.75_in, 14_in}, quadEncoderTPR})
	    .withOdometry() // use the same scales as the chassis (above)
	    .buildOdometry(); // build an odometry chassis

			chassis->setState({0_in, 0_in, 0_deg});
			chassis->moveDistance(1_ft);
}

It is a x-drive, any ideas?

#2

I got it to drive straight, I had the wrong encoder reversed…

Now it is not stopping when it goes forward

#3

First step to solve the configuration problem (which it is) is to just print the encoder values to see that they are reversed properly.

Now it is not stopping when it goes forward

This sounds like it is caused because now the encoders are reversed improperly, so the further the robot tries to drive forward the more it thinks it is driving in the wrong direction.

After you have established that your encoders are correct, the next step is to use chassis->forward and chassis->turn to confirm that your motor configuration is correct. Test them out separately one at a time. You can also use chassis->arcade with a joystick for this step.

There might also be a problem with your PID gains (the angle gain is way too high and the distance too low) which might be causing this.

8 Likes
#4

Okay, so I found out that the Gains is what is giving me the problem. I know that because when I take them out the problem went away. When I do arcade it works very well. How should I re-add the gains in, or do I even need them? Thanks!

#5

So, what actually happens is that when you take out the gains, you switch from a CCPID controller (Chassis Controller PID) to a CCI controller (Chassis Controller Integrated), which actually executes the movements completely differently. Without gains and a CCI, your external encoders are not used for moveDistance or any other movement function, the only thing your encoders are used for is knowing where you are for odometry. You also need to adjust your dimensions as per the tutorial.

If you do want to use your external encoders for movements, you will need a CCPID instance, and therefore need gains.

Therefore, I am not sure if your problem comes from bad gains or something wrong with the sensors/configuration.

8 Likes
#6

I think it is coming from bad gains, because when I put it in op control and make it arcade drive, it drives fine. I know what encoder is reversed due to printing out the value of them to the brain.

#7

It stopped driving forever now, but it goes three times the distance that I put In, I think I know what it is, I will check back if it works or not. Thanks for the help!

#8

I am having almost the same problem. @Robotnerd did you figure out what the problem was?

#9

@theol0403 Does the .withgains version of the ChassisController use the internal encoders in the motors?

#10

Yes; if no withSensors(...) is specified in the builder, then the integrated motor encoders are used to create a CCPID

1 Like
#11

So changing out the motors wouldn’t fix this problem. My specific problems are that some of the motors keep moving after others stop. And my Odom isn’t going to the right place. For instance If I tell it to drive 2_ft up than goto 4_ft 4_ft it drives diagonally into the negative coordinates instead of going to 4, 4.

#12

Ha, yes I got it @lerker100 . I had my left and right encoders swapped. Just make sure that your
.withsensors(I think this is what it is) has all of the encoders in the right order: left, right, and middle.

1 Like
#13

Thanks @Robotnerd I already have then in the right order. I had to change my wheel size in code to get the drive train to drive the correct distances and now when I use drivetopoint from one point than back to the same point my robot drives way past the point. Not sure why. I’m using a standard 4 motor omni drive. Nothing fancy.

#14

Yeah, I have been having the same problem were it doesn’t do stuff correctly when trying to use the drive to point.

1 Like
#15

Ok, well I’m going to put an issue on github than. I’ll link it here when I do.

#16

Are you using odometry wheels that are a different size than your drivetrain wheels?

#17

No. My external encoders are on the back two drive wheels.

#18

Is your chassis externally geared? Is it using the normal “green” motor inserts?

#19

It’s a basic 4 motor direct drive with green cartridges in all motors. Nothing fancy.