How to go about making tankDrive and ArcadeDrive methods

[kinganu123]

Originally Posted by lineskier

Rotation is handled as plus or minus

Left is y. - x
Right is y+ x

They may be flipped

Once again remember scaling

That doesnt work for moving the joystick to the corners or towards them. thats the hardest part of arcade and ive been trying a bunch of algorithims but none of them can be used for more than one specific coordinate

[mwtidd]

Originally Posted by kinganu123

That doesnt work for moving the joystick to the corners or towards them. thats the hardest part of arcade and ive been trying a bunch of algorithims but none of them can be used for more than one specific coordinate

well you could do an if > 1 output 1
or a divide by 2
those should work somewhat.

the best case would be to use trig even for an arcade drive to ensure max values

[Ether]

Originally Posted by kinganu123

That doesnt work for moving the joystick to the corners or towards them. thats the hardest part of arcade and ive been trying a bunch of algorithims but none of them can be used for more than one specific coordinate

Look at this diagram, and see if you can figure out what the left and right motor speeds should be for the red, green, and blue dots. If you can do that, you should be able to design an algorithm to compute the wheel speeds for any joystick position.

Some drivers find this behavior more intuitive.

[Ether]

Originally Posted by kinganu123

That doesnt work for moving the joystick to the corners or towards them. thats the hardest part of arcade and ive been trying a bunch of algorithims but none of them can be used for more than one specific coordinate

What do you mean by "doesn't work" and "one specific coordinate" ? Please post a couple of example calculations to illustrate the problem you are encountering.

[mwtidd]

Originally Posted by Ether

What do you mean by "doesn't work" and "one specific coordinate" ? Please post a couple of example calculations to illustrate the problem you are encountering.

I assume it has something to do with the math being done. If you pass a value >1 or <-1 i'm pretty sure the robot does nothing.

Also knowing whether or not iterative or simple robot are being used is helpful too. I prefer simple robot as I like to have control over initialization and my loops.

My interest has been peaked by approaching the arcade drive similar to a mecanum by using arc functions. however arc estimators will have to be coded up as only standard sin cos and tan are supported

[kinganu123]

Originally Posted by lineskier

I assume it has something to do with the math being done. If you pass a value >1 or <-1 i'm pretty sure the robot does nothing.

Also knowing whether or not iterative or simple robot are being used is helpful too. I prefer simple robot as I like to have control over initialization and my loops.

My interest has been peaked by approaching the arcade drive similar to a mecanum by using arc functions. however arc estimators will have to be coded up as only standard sin cos and tan are supported

I was thinking it would be easier in simpleRobot as well however since we use iterative for our robot code he wants me to make one that will work with iterative.

[kinganu123]

Originally Posted by Ether

What do you mean by "doesn't work" and "one specific coordinate" ? Please post a couple of example calculations to illustrate the problem you are encountering.

For example, i was trying to figure out how i would get the left motors to stay off and the right motors to stay full on when the joystick is at teh top left corner(X,Y) = (-1,1), and see if that code works for all quadrants. I used y+X for the left wheels and Math.max(X,Y) for the right wheels. However that algorithim doesnt work for all four quadrants so Ive made a big branching if-else so I have a different algorithim for each quadrant of the cartesian plane and another if else for if the joystick is on the x or y axis.
It looks pretty inefficient but without trig i dont think theres another way to do it.

[Ether]

Originally Posted by lineskier

arc estimators will have to be coded up as only standard sin cos and tan are supported

Not sure what you mean by the above. Java, C++, and LabVIEW all support the atan2 function.

Originally Posted by lineskier

My interest has been peaked by approaching the arcade drive similar to a mecanum by using arc functions.

There's nothing wrong with exploring that, it's a great way to learn. But what is the basis for the following statements:

the best case would be to use trig even for an arcade drive to ensure max values

programming a mec via trig is a lot easier than doing it without it

[Ether]

Originally Posted by kinganu123

For example, i was trying to figure out how i would get the left motors to stay off and the right motors to stay full on when the joystick is at teh top left corner(X,Y) = (-1,1), and see if that code works for all quadrants. I used y+X for the left wheels and Math.max(X,Y) for the right wheels. However that algorithim doesnt work for all four quadrants so Ive made a big branching if-else so I have a different algorithim for each quadrant of the cartesian plane and another if else for if the joystick is on the x or y axis

Try this: Use L=Y+X and R=Y-X.

Then limit L and R to the range -1..+1. Spoiler hint at bottom.

If you do this, you should get these values:

 X	 Y	 L       R

 0	 1	 1	 1
 1	 1	 1	 0
 1	 0	 1	-1
 1	-1	 0	-1
 0	-1	-1	-1
-1	-1	-1	 0
-1	 0	-1	 1
-1	 1	 0	 1

The above table matches this diagram.

If the above table is not the result you are seeking, post a table showing the result you want.

Warning: spoiler follows:



Hint:

for limiting (clipping), do this:

if(L>1) L=1; else if(L<-1) L=-1;
if(R>1) R=1; else if(R<-1) R=-1;

instead of clipping, you could normalize instead. you'll still get the same table as above, but intermediate joystick results will be slightly different:

max=fabs(L); if(fabs(R)>max) max=fabs(R);
if(max>1){ L/=max; R/=max;}

if you want to get the exact same results as the WPI library functions for all intermediate joystick settings, a slightly different algorithm will be necessary... but still no trig required.

[Ether]

See attached chart.

The first column is for the simple L=Y+X, R=Y-X with normalization. The second column is the same as the first except it uses clipping instead of normalization. The third column is a slightly (very slightly) more complicated algorithm which I believe gives the same results as what you get from the WPI library (and may indeed even be mathematically identical... I haven't checked).

The first 8 rows of the chart are the values around the perimeter of the large square in this diagram, starting at the top center and going around the square clockwise. Notice that all three algorithms give the same values for these points.

The remaining rows show the outputs for intermediate joystick values. The three algorithms differ somewhat for these inputs.

None of these algorithms uses any trigonometry.

[mwtidd]

Originally Posted by Ether

Not sure what you mean by the above. Java, C++, and LabVIEW all support the atan2 function.




There's nothing wrong with exploring that, it's a great way to learn. But what is the basis for the following statements:

the best case would be to use trig even for an arcade drive to ensure max values

programming a mec via trig is a lot easier than doing it without it

How do you access atan2? Its not included in the stripped down Math util.

A perfect arcade drive would map every point within a circle to a set of motor outputs. Using trig you can program for every case using one formula.

Same is true for the mecanum drive. By knowing the resulting vector and magnitude you want, you can program a whole mec drive with a couple calculations.

The code would be a lot cleaner and more efficient, as every point on the circle formed by the joystick would map to a distinct ideal set of motor outputs. (as opposed to using a scaling algorithm.)

[Joe Ross]

Originally Posted by lineskier

How do you access atan2? Its not included in the stripped down Math util.

http://www.chiefdelphi.com/forums/sh...ght=atan2+java

[Ether]

Originally Posted by lineskier

How do you access atan2? Its not included in the stripped down Math util.

See Joe's post.

A perfect arcade drive would map every point within a circle to a set of motor outputs.

The joystick makes a square, not a circle. The algorithms mentioned here map every point in the square to a set of left/right motor outputs.

Using trig you can program for every case using one formula.

You don't need trig to do this.

Same is true for the mecanum drive. By knowing the resulting vector and magnitude you want, you can program a whole mec drive with a couple calculations.

FR = -Y -X -Z

FL = -Y +X +Z

RR = -Y +X -Z

RL = -Y -X +Z

How does trig make the above any easier ?

The code would be a lot cleaner and more efficient, as every point on the circle formed by the joystick would map to a distinct ideal set of motor outputs. (as opposed to using a scaling algorithm.)

How does using trigonometry make the above mec code any "cleaner", or "more efficient"? The above code is kinematically correct, even after normalization.

[mwtidd]

Originally Posted by Ether

See Joe's post.



The joystick makes a square, not a circle. The algorithms mentioned here map every point in the square to a set of left/right motor outputs.




You don't need trig to do this.




FR = -Y -X -Z

FL = -Y +X +Z

RR = -Y +X -Z

RL = -Y -X +Z

How does trig make the above any easier ?




How does using trigonometry make the above mec code any "cleaner", or "more efficient"? The above code is kinematically correct, even after normalization.

thanks for the feedback.

I guess if you approach the js as a square, you are def right. I personally always approach the joystick as a circle as the points you can get on a joystick can be easily mapped to either a circle or a square.

The way you solve the grid seems to be a case statement. Personally I would rather have one equation that gets the value based on heading and magnitude.

Again your algorithm certainly solves the problem well and I do not believe it would have any dead spots. But i guess we approach the joystick from 2 different views: a square vs a circle. I believe both approaches to be correct.

approaching it as a square requires normalization where as approaching it as a circle does not (unless we start looking at mecanum where factoring in rotation requires normalization )

[Ether]

Originally Posted by lineskier

The way you solve the grid seems to be a case statement

No, its not a case statement. It's simply this:

L = Y+X
R = Y-X

I can't imagine anything simpler. It works for all 4 quadrants. No case statement is necessary.

Personally I would rather have one equation that gets the value based on heading and magnitude.

If that's your personal choice I cannot argue. But what "one equation" are you referring to? To get heading and magnitude, you need two equations right there. Then you have to calculate the wheel speeds from those.

But i guess we approach the joystick from 2 different views: a square vs a circle. I believe both approaches to be correct.

I also believe both approaches are correct.

approaching it as a square requires normalization where as approaching it as a circle does not

If your X,Y values are (1,1) then your magnitude calculation will give 1.4 and you will need to clip or normalize... unless you aren't using the magnitude but converting it back to X and Y values... in which case I'm puzzled why you converted them to polar in the first place.

Would you be willing to post your code ? I'd like to understand better what you are saying.