H-Drive Programming

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.

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

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.

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

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)

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.

  1. You want to take the joystick degrees and break it up into x and y vectors (kind of like what you do in physics).
  2. Use the magnitude to compute the size of the x and y vectors.
  3. 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.

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.

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:

  1. Accept the fact that left to right strafing is at a lower speed and work through it in driver practice
  2. Reduce the power on the tank drives (not recommended as an only solution; you’d be giving up the reasons for selecting H).
  3. 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)

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.

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.

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.

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

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(yAxis, xAxis));
    	 leftCurrent =gaussianConversion(gaussianInput)+rotate;

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

	private double angleToGaussianInput(double rad) {
		return (rad-Math.PI/2.0)/(Math.PI/2.0);

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?

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:


This is quite different from the previous description.

See attachments.

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