Is it possible to code a coordinate plane and use the coordinates as destinations in autonomous?

Programming Support
#1

I’ve been asking myself the question that is it possible to code a coordinate plane and use the coordinates as destinations in autonomous? I was thinking that instead of making a PID or Odom code I could make the bot basically have itself on a coordinate plane and in the auton function say

drivetrain spin to (1,1)

Now that is boiled down pseudo code, but if it is possible to make this work how could I?

1 Like
#2

You just described the point of PID and Odom.
You may be able to make this work with a GPS sensor, but it won’t be as accurate and precise as the alternatives. PID is needed to make it not overshoot/undershoot the coordinate point you want it to drive to.

5 Likes
#3

It is quite possible. We use a simple PID function to turn and drive to points, and odom to give the robot’s current position. Turning to a certain point is quite easy with odom: you set your desired turn angle to atan2(y-roboty, x-robotx) and run an easy PID loop.

3 Likes
#4

I mean a more direct way of coding it

#5

Can you explain what you mean by direct?

#6

Like

void Cplane (){
code to set the quadrants and points
}

void Botplacement () {
sets the bots starting coordinate
and the movement to any other coord
}

void autonomous (void) {
runs the placement function (2,3)
}

The Cplane function would be in pre-auton

#7

You’re on the right track. After you make a coordinate grid, how will you know where your robot is? How is it going to reach its target on the coordinate grid from the starting point?

The job of the Botplacement() function in your psuedocode is to answer these questions and move the bot accordingly.

To answer the first question, some known methods are odometry, GPS, etc.
You can answer the second question with PID, which is used to move the robot based on how far the bot is away from the target.

2 Likes
#8

In that case, could I transform the inputs from Odom and PID into coordinate pairs?

#9

Yes. Say that you start at (0, 0), and want to drive to (5, 0). Your odom wheels will keep track of where you are, and give you coordinates. When your bot starts moving on the x axis, you can take the value of how much the odom wheels have turned, and turn that into a distance in units that your bot has travelled. This gives you data to work with, and answers the first question: Where is the bot?

But just knowing where your bot is isn’t enough. There’s no point in knowing where you are if you can’t move. This is where PID comes in. It takes in the value from the data you created using odom, and calculates an error in the distance from the current position of the bot and where it needs to be. It then runs the motors at the appropriate speed for it to reach its target, and slows down accordingly as it nears its target.

If you haven’t checked it out already, the Purdue Sigbots wiki has great resources for PID and Odometry.
This document by George Gillard is also really helpful for understanding PID.

7 Likes
#10

Here is some old code from a skills run a few years ago. EDIT: 7 years ago…

FondleStacks being a joke name for the function that went to a stack of balls and picked them up. Configured the location of each stack of balls. so that you just pass which location to fondleStacks, I think the arguments are if its near a wall you need a bit of special behavior.

switch (autoMode)
		{
		case skills:
			clearTimer(T4);
			amRed();
			startAutoFlywheel(midShot);
			SensorValue[FlyControl]=0;

			drivePID(535,false);
			turnPID(45);
			drivePID(285,false);
			motor[intake]=-127;
			motor[indexer]=motor[indexer2]=-127;
			gohome();
			faceGoal(ourGoal);
			delay(250);
			shoot();
			faceGoal(ourGoal);
			fondleStacks(ballSix, false,false);
			drivePID(-400,false);
			startAutoFlywheel(pipeShot);
			faceGoal(ourGoal);
			shoot();
			//fondleStacks(ballSeven, true, false);
			//motor[intake]=-127;
			//drivePID(-400,false);
			//faceNorth();
			//shoot();
			fondleStacks(ballSeven, true ,true);
			drivePID(-400,false);
			faceGoal(ourGoal);
			shoot();
			stopFlywheel();
			gohome();
9 Likes
#11

Love the name FondleStacks.

8 Likes
#12

Thank you for explaining that :sweat_smile: I just have two final questions how do you incorporate Odom and PID. Also how do you add tracking wheels into the combined code

#13

We have a task/loop that runs really fast (20 msec) that takes the rotations from the forward facing tracks wheel, multiplies it by the sin of the angle of the gyro, then adds this to a y-value. Take the cos(angle) times distance to add to the x-value. If you have a sideways facing wheel you can do the same thing but plus 90 degrees. We use these x and y values in function for the starting position so the only input required is your destination. Your PID function can calculate the angle/distance between those two points to turn and go there

1 Like
#14

Could you use the v5 motor’s integrated one, and have a sideways tracking wheel?

#15

Technically you could use it but it is inaccurate and ill advised. The best solution is to have external tracking wheels connected to rotation sensors.

#16

Ill advised yes, but op if done right (2647X using motor encoders for worlds skills runs)

3 Likes
#17

It’s very possible and what we used at the beginning of last year. The only problems is if your wheel spins out or doesn’t slide. But if your drivetrain is built straight enough, your wheels have plenty of traction, and you don’t accelerate too quickly(the cause of spinning out which can be avoided with ramping code), then you should be fine. The reason why we have them is because we are using the 4in wheels for our drive train and I like the 3.25 omnis better for tracking. Also the main reason is so that we can use the odometery in driver control as it is more likely to have a wheel come off the ground due to driver inconsistencies. You could implement ramping in a drive but at some point it would just feel unresponsive

#18

The George Gillard document has psuedocode on how to code a PID and explains what each part of a PID loop does.

As for odometry, the Purdue links go in depth into the math of how tracking wheels find distance and heading, which is great to know during interviews. As for coding it, you can make it based off of the math, or you can use something like OkapiLib’s built in odometry with PROS.

3 Likes
#19

Not rotation sensors, the external encoders are much better cuz less friction (or so I hear)

#20

Rotation sensors are external encoders…

If you mean they have less friction than the old quad encoders, I found that they’re about the same.

1 Like