Re: How to go about making tankDrive and ArcadeDrive methods
 

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

Re: How to go about making tankDrive and ArcadeDrive methods
 

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

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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

Re: How to go about making tankDrive and ArcadeDrive methods
 

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:


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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.)

Re: How to go about making tankDrive and ArcadeDrive methods
 

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.

Re: How to go about making tankDrive and ArcadeDrive methods
 

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 )

Re: How to go about making tankDrive and ArcadeDrive methods
 

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.


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.


I also believe both approaches are correct.


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.