H-Drive Programming

[landinw]

Our drive team is developing a H-Drive system with omnis this year (4 corners and 2 across). Anyone have any tips on how to best program this so it can be driven with a single joystick. We're using Java.

[Ether]

Our drive team is developing a H-Drive system with omnis this year (4 corners and 2 across). Anyone have any tips on how to best program this so it can be driven with a single joystick.

That depends on what you want the drivetrain to do, and whether your joystick is 2 axis or 3 axis, and what motors and gear ratios you intend to use for the sideways motors.

Provide a little more detail.



Without knowing what you want the drive to do, one suggestion for a 2-axis joystick would be to program it in two separate modes, with the desired mode selectable using a botton or buttons.

ModeA could be simple tank or arcade driver interface (sideways motors not used). ModeB could be strafe mode (power only the 2 sideways motors and leave the corner ones unpowered).

[landinw]

Thanks for the reply.

We will have a 3-axis joystick available. Guidance we have is that going forward/backward (y-axis) the corner wheels would do the driving, going left/right (x-axis) the cross wheels would do the driving and turning in place (z-axis) the motors would work together to "twist" the bot. We'll be using CIMs, but don't have info on gearing.

We're just getting started dissecting this problem but thought I'd reach out to see what others with experience had to say.

Thanks again.

[TheMkrage]

Hi!
My team's off-season project was to build an H-Drive drive train. Our drive train is controlled by an XBox controller where the Y-Axis of the left joystick controls vertical movement, the X-Axis of the left joystick controls horizontal movement through the strafe wheel, and the X-Axis of the right joystick controls turning.
If you are attempting to use a single joystick, I suggest you use a three axis joystick. A two axis joystick with separate modes may work, but it prohibits some movements that are possible when using H-Drive. For example, with a two axis joystick, you could never strafe while moving forward or strafe while turning. You will never be able to move diagonally or turn while strafing with separate modes. A three axis joystick would allow you do this.
I also believe another aspect to take into account is how responsive the drivers can be with separate modes. Separate modes may require more practice to be used successfully because the driver has to remember which mode he or she is in. It is just another button to worry about when the driver already has enough on his or her mind. A three axis joystick would eliminate this problem.
Another thing to take into account when programming H-Drive is maintaining a constant angle when strafing. The point of strafing is to add horizontal movement without having to turn. Without code to fix for this, your robot will most likely arc when it is strafing. To eliminate this, I used a PID Loop (well a PD loop) that's main function was to keep the robot facing towards one angle. Of course this is only activated when you are strafing or moving forward and strafing (which would move you diagonally)

Hope this helped

[Andrew Schreiber]

Thanks for the reply.

We will have a 3-axis joystick available. Guidance we have is that going forward/backward (y-axis) the corner wheels would do the driving, going left/right (x-axis) the cross wheels would do the driving and turning in place (z-axis) the motors would work together to "twist" the bot. We'll be using CIMs, but don't have info on gearing.

We're just getting started dissecting this problem but thought I'd reach out to see what others with experience had to say.

Thanks again.

https://gist.github.com/schreiaj/c3356a23dc3a8e33c574 Code that I put together as a general solution to omni drives, it works for H drive as is. Code has been tested using a chassis weighted to 100lbs. It drifts (correct with Gyro) but does correct things.

Math's based on this paper (http://people.idsia.ch/~foerster/2006/1/omnidrive_kiart_preprint.pdf)

[kinganu123]

I figure I might as well throw in my two cents. The code (at least for my team's untested implementation) will look a lot like RobotDrive's mecanumDrive_Polar/Cartesian.

You want to take the joystick degrees and break it up into x and y vectors (kind of like what you do in physics).
Use the magnitude to compute the size of the x and y vectors.
Divide by the original x and y vectors so that you can bring your magnitudes back to a scale of -1 to 1. Without this last step, you robot won't be able to go diagonal at max speed.

[GeeTwo]

I figure I might as well throw in my two cents. The code (at least for my team's untested implementation) will look a lot like RobotDrive's mecanumDrive_Polar/Cartesian.

You want to take the joystick degrees and break it up into x and y vectors (kind of like what you do in physics).
Use the magnitude to compute the size of the x and y vectors.
Divide by the original x and y vectors so that you can bring your magnitudes back to a scale of -1 to 1. Without this last step, you robot won't be able to go diagonal at max speed.


If you extend or emulate mecanumDrive, you will also want to make some adjustments for the different amount of force you are capable of providing in each direction. If you turned all four tank wheels forward, and the two strafe wheels to the right, you wouldn't go off in a 45-degree angle right of forward, but a 26-degree angle right of forward (assuming equal weight loading on each wheel and equivalent wheels all around, ignoring differences in roller cross-friction). For a classic 5-wheel H-drive with the same assumptions, the answer would be only 14 degrees from forward.

[kinganu123]

Huh, I did not think about that at all! Looks like I'll have to bring the programmers back to the white board.

[GeeTwo]

Huh, I did not think about that at all! Looks like I'll have to bring the programmers back to the white board.

And that is why I'd rather post my design early than keep it secret.

[kinganu123]

And that is why I'd rather post my design early than keep it secret.

Wait, where is this said post? I think we got it be using a ratio relative to the x-axis, but I would like to know if there is a better way. Our way is hacky, but should do the trick.

[GeeTwo]

Wait, where is this said post? I think we got it be using a ratio relative to the x-axis, but I would like to know if there is a better way. Our way is hacky, but should do the trick.

No, I am not familiar with anyone else having emulated HolonomicDrive with an H-drive. I was just remarking that the value of sharing and getting more eyes on your idea usually has better payoff than keeping it secret does.

I can think of several solutions to this issue, none of them perfect. They pretty much come down to variations on:

Accept the fact that left to right strafing is at a lower speed and work through it in driver practice
Reduce the power on the tank drives (not recommended as an only solution; you'd be giving up the reasons for selecting H).
allow some way to switch between these two, or one of these and regular tank-drive or tank-drive-plus-strafe (or any three or four)

[kinganu123]

So we ended up doing is making our own Gaussian function to adjust the y speed based upon the angle of the x and y vectors from the joysticks. The major downside is that we won't be able to go diagonally at "full speed," but as you said, this may be something we'll just have to accept.
We should be able to actually test this approach on tomorrow and I'll try to update this post with the result.

[Ether]

So we ended up doing is making our own Gaussian function to adjust the y speed based upon the angle of the x and y vectors from the joysticks.

Gaussian function?

[GeeTwo]

Gaussian function?
Does sound strange. From context, I believe they're planning to "amplify" the strafe by a factor of four at low values so that response is essentially isotropic, and use a Gaussian taper on the strafe axis so that at large values of strafe they're back at a multiplier of one so that response on the main drive axis is four times as good as on the strafe axis.

[kinganu123]

Does sound strange. From context, I believe they're planning to "amplify" the strafe by a factor of four at low values so that response is essentially isotropic, and use a Gaussian taper on the strafe axis so that at large values of strafe they're back at a multiplier of one so that response on the main drive axis is four times as good as on the strafe axis.
Yes, exactly this.
So I wasn't there when we actually tested the drive train, but from my understanding, it seems like we are having dinner center of gravity issues that essentially messes with it values, so we're going to wait for the elevator to be put on before we do more extensive testing and tuning. But it went reasonably well for the most part.

[Ether]

Yes, exactly this

@kinganu123: Is the following a correct interpretation of what you meant?

Let X be the value of the joystick strafe axis,
in the range 0 to +1 for strafe right.

Let G(X) be your Gaussian taper function, such that G(0)=4 and G(1)=1.

Let Xt(X) be the tapered value of X: Xt(X)=X*G(X).
If so, would you be so kind as to post your G(X) function.

[kinganu123]

Our formula is e^(gaussianInput^2/-.18) where the gaussianInput is the polar degrees from 0 to pi where pi/2 is 0, 0 is 1, and pi is -1.
I'm putting the code below, in case what I've typed doesn't make sense, here's the code:
centerCurrent = xAxis;
double gaussianInput=angleToGaussianInput(Math.atan2(yAxi s, xAxis));
leftCurrent =gaussianConversion(gaussianInput)+rotate;
rightCurrent=leftCurrent-2*rotate;

private double gaussianConversion(double gaussianInput) {
return Math.exp(Math.pow(gaussianInput, 2)/(-.18));
}

private double angleToGaussianInput(double rad) {
if(rad>Math.PI)
rad-=Math.PI;
return (rad-Math.PI/2.0)/(Math.PI/2.0);
}

[Ether]

Our formula is...

OK, to see if I'm understanding your formula correctly, can we take a simple numerical example?

Suppose the driver pushes the joystick to Y=1, X=0.5, rotate=0. What will be the "tapered" value of X?

[kinganu123]

Oh, sorry, I meant to say that the y-axis is the one that is modified, not the x.
So, x will be .5 and y will be 0.9702, or e^(((atan(1/.5)-pi/2)/pi/2)^2/-.18).

[Ether]

Oh, sorry, I meant to say that the y-axis is the one that is modified, not the x.
So, x will be .5 and y will be 0.9702, or e^(((atan(1/.5)-pi/2)/pi/2)^2/-.18).

I believe you left out a pair of parentheses:

e^(((atan(1/.5)-pi/2)/(pi/2))^2/-.18)


This is quite different from the previous description (http://www.chiefdelphi.com/forums/showpost.php?p=1434921&postcount=15).

See attachments.

Have you guys driven with this yet? How is it working?

[kinganu123]

Yes, I didn't realize that he specified the strafe axis, which would result in the confusion.
And we haven't been able to test it yet since the mechanical guys are currently assembling the elevator on the robot, so we're losing a few days on testing and tuning this.
Also, I thought I'd note here that we tweaked the code above, in case anyone else wanted to try our stuff out, because I noticed a slight flaw in getting the y values

centerCurrent = xAxis;
double gaussianInput=angleToGaussianInput(Math.atan2(yAxi s, xAxis));
double scaledGaussianOutput=yAxis*gaussianConversion(gaus sianInput)
leftCurrent =scaledGaussianOutput+rotate;
rightCurrent=scaledGaussianOutput-rotate;

[Ether]

Yes, I didn't realize that he specified the strafe axis, which would result in the confusion.

It's not just the axis; the gains are quite different from what was described.

I'm a math enthusiast, so don't take this wrong, but why the complicated function with exponential and inverse trig? Wouldn't a simple linear interpolated 6x6 LUT do the job... and be far more easily tuned to compensate for actual behavior once you've done your testing?

[kinganu123]

So we do have a simpler version coded up with some sort of linear adjustment instead of this one (I had some of the other students write that as a backup), but the main reasoning behind this method was to allow y to increase significantly to make up the lost y speed as the driver went at a smaller angle (with respect to the front of the robot).

[Ether]

Instead of using arctangent and exponential functions, why not just multiply the X axis by a factor of 4, clip it at 1, and normalize the resulting X,Y pair?




void adjust(float Xj, float Yj, float *Xa, float *Ya){

float mag;

*Ya=Yj;

if (Xj<=-0.25) *Xa=-1;
else if (Xj<0.25) *Xa=4.0*Xj;
else *Xa=1.0;

// normalize adjusted values:
mag=sqrt(*Xa**Xa+*Ya**Ya);
if (mag>1) {*Xa/=mag; *Ya/=mag;}
}

See attached Excel spreadsheet. The 100 tab shows an overview of adjusted XY pairs (cyan cells) for the entire first quadrant. The 25 tab zooms in for a closer look for small joystick values.

The attached plot shows a family of Xa vs Xj curves for Yj=0 to 1.


Or you could make the X gain a function of Yj, like so:



void adjust(float Xj, float Yj, float *Xa, float *Ya){

float mag, gain;

gain=1+3*Yj;

*Ya=Yj;

*Xa=gain*Xj;
if (*Xa>1) *Xa=1;
else if (*Xa<-1) *Xa=-1;

// normalize adjusted values:
mag=sqrt(*Xa**Xa+*Ya**Ya);
if (mag>1) {*Xa/=mag; *Ya/=mag;}
}

See attached plots for Xa vs Xj for Yj=0 to 1
and Ya vs Yj for Xj=0 to 1