Drivetrain Idea - "Box Drive"

[pimathbrainiac]

So over the summer, I thought up of an idea for a drivetrain I dub "box drive," inspired by H drive. It requires 8 omni wheels, and it strafes while being able to retain more of the traction of a four traction wheel drivetrain than mechanum or omni, while being more obtainable/less costly to the common FRC team than swerve drive (read: my team can't do swerve drive for various reasons, including money and lack of a machine shop sponser).

As far as cons go, If you need to feed from the floor, like in rebound rumble or ultimate ascent, this is unusable. It shouldn't be a problem in rack-n-roll or logomotion style games, though.

Since I don't know CAD, here's my ASCII art interpretation of what it would look like top-down, each line representing a wheel on the perimeter of the robot (With the orientations matching the orientation of the lines) (All of these being Omni wheels):

front
__-__-__
|-------|

|--__ --|

As far as programming goes, if robot oriented, strafing is done by moving the horizontal wheels, without moving the vertical ones. Moving forward is done by moving the vertical wheels and not the horizontal ones.
EDIT - rotating would be done with moving the vertical and horizontal wheels accordingly.

The most effective way to use this drive would be field oriented, which I don't know what to do. I would need help coming up with the calculations for the rotations of the wheels (the forward and strafe vectors themselves are easy enough).

So this is two part:
1) Do you like this drivetrain idea?
2) What would the general calculations be for the wheel speeds, with distance between wheels in a variable?

[nathannfm]

Do you think you could do a quick sketch in paint of the concept, I am having a bit of trouble picturing what you are saying.

[cjl2625]

Hm, that's interesting.
Why 3 sideways omnis in the front but only 1 in the back?
I would assume that programming something like this would be somewhat similar to a swerve drive. You can check out my presentation on swerve if you want some ideas on calculations. Maybe you could program it like a mecanum, but I don't know; I have no idea how mecanum works.

I have an idea for the code if you rearranged the layout to something like this:

You could do regular 4 wheel swerve calculations, and then end up with an (x, y) vector for back left, back right, front left, and front right. For each of those corners, take the x value and send it to the horizontal wheel, and take the y value and send it to the vertical wheel.
Might be better ways of doing it, but that's my idea.

Edit: I'm starting to realize that all 8 wheels might not be independent. In that case, my idea probably won't work.

[Alan Anderson]

If I'm understanding the idea correctly, the programming for something like this would be exactly like a mecanum or traditional omniwheel drivebase, but with "forward" being along the diagonal. As such, it will have the same drawbacks with the limited number of motors that can provide full power simultaneously.

[cbale2000]

I actually thought of making a drive system like this, but doing it with traction wheels and have one set actuate up and down to change directions, a bit like some of the octocanum and similar drives do, but with the entire drive module (the benefit being you'd have a sort of omnidirectional drive system with traction wheels).

Eventually I concluded that the system would weigh too much, use to many motors, and be too complex to be practical. That said, it would be cool to see someone make it work.

[nathannfm]

Originally Posted by cbale2000

I actually thought of making a drive system like this, but doing it with traction wheels and have one set actuate up and down to change directions, a bit like some of the octocanum and similar drives do, but with the entire drive module (the benefit being you'd have a sort of omnidirectional drive system with traction wheels).

Eventually I concluded that the system would weigh too much, use to many motors, and be too complex to be practical. That said, it would be cool to see someone make it work.

Lobster Drive

[Chris is me]

The reason H drive has more forward traction than mecanum or omni is because more of the robot's weight is supported on the wheels pointing forwards than the wheels pointing sideways. In this configuration having more sideways wheels cancels out that effect.

With some specific exceptions, simply increasing the number of wheels on the ground does not significantly increase traction. So this drive is going to perform exactly as well as a holonomic 4 omni drive in terms of traction or manuverability.

In addition, once you put more than 4 wheels on the ground you run into problems with maintaining wheels contact. Unless your frame is perfectly rigid with every wheel at exactly the same height (and a perfectly rigid drive doesn't exist) you'll have some wheels supporting far more weight than others, this disproportionately influencing the direction of travel.

[EricH]

See if you can locate any tech specs for the only "linkage drive" ever used in FRC--"Twitch" was the robot name.

4 omni wheels mounted in swerve module-type devices, rotated 90 degrees by a single pneumatic cylinder. It was used in 2008 for making turns at the ends of the field.

That might be worth trying out in the offseason; the "swerve modules" could be just large pieces of C-channel or box tubing (or, if you have any around, the 2010 KitBot risers with some extra well-placed holes).

[SoftwareBug2.0]

Originally Posted by Chris is me

In addition, once you put more than 4 wheels on the ground you run into problems with maintaining wheels contact. Unless your frame is perfectly rigid with every wheel at exactly the same height (and a perfectly rigid drive doesn't exist) you'll have some wheels supporting far more weight than others, this disproportionately influencing the direction of travel.

I think the number you're looking for is 3.

[Max Boord]

Originally Posted by cbale2000

That said, it would be cool to see someone make it work.

180 combined that with an airplane propeller in 2009.

[asid61]

Originally Posted by EricH

See if you can locate any tech specs for the only "linkage drive" ever used in FRC--"Twitch" was the robot name.

4 omni wheels mounted in swerve module-type devices, rotated 90 degrees by a single pneumatic cylinder. It was used in 2008 for making turns at the ends of the field.

That might be worth trying out in the offseason; the "swerve modules" could be just large pieces of C-channel or box tubing (or, if you have any around, the 2010 KitBot risers with some extra well-placed holes).

Twitch drives are pretty cool if you can pull it off. You don't need to use omni wheels though; regular traction wheels will do fine.

About the OP:
Cool idea. How would you make sure all 8 wheels are touching the ground though? This would save a lot of space depending on motor configurations. Using a shifter to shift between wheels on each corner bevel gears would net you the ability to tank, slide, and drift. Weight would be a big issue though with the extra 4 wheels and shifters.

[pimathbrainiac]

Originally Posted by cjl2625

I have an idea for the code if you rearranged the layout to something like this:

You could do regular 4 wheel swerve calculations, and then end up with an (x, y) vector for back left, back right, front left, and front right. For each of those corners, take the x value and send it to the horizontal wheel, and take the y value and send it to the vertical wheel.
Might be better ways of doing it, but that's my idea.

Edit: I'm starting to realize that all 8 wheels might not be independent. In that case, my idea probably won't work.

Actually that's probably a better idea than my current one, even with each wheel not being controlled independently, because both of the wheels on each side would end up being the same speed no matter what, because the robot can only move in a straight line and rotate. It's an interesting idea, and the layout makes more sense than my current idea.

Originally Posted by Chris is me

The reason H drive has more forward traction than mecanum or omni is because more of the robot's weight is supported on the wheels pointing forwards than the wheels pointing sideways. In this configuration having more sideways wheels cancels out that effect.

With some specific exceptions, simply increasing the number of wheels on the ground does not significantly increase traction. So this drive is going to perform exactly as well as a holonomic 4 omni drive in terms of traction or manuverability.

In addition, once you put more than 4 wheels on the ground you run into problems with maintaining wheels contact. Unless your frame is perfectly rigid with every wheel at exactly the same height (and a perfectly rigid drive doesn't exist) you'll have some wheels supporting far more weight than others, this disproportionately influencing the direction of travel.

From the sides or the front, where most robots would end up pushing, the robot would be able to push back without any problems, because of the direction of the wheels themselves, with a reconfiguration to cjl2625's idea. Also my team made a west coast drive without the dropped center (robot was wider than it was long) work last year. I don't think the maintaining contact thing will be an issue. As for the weight issue, I see what you're saying. That could be an issue.

As for something I've seen in a few posts in this thead: This would probably use four motors to avoid the weight issue with 8 motors. We'd have to check in offseason testing, though, since we don't have much to do to prepare for our offseason competition.

Anyways, if I can't convince my team anyway, we'd probably end up testing a butterfly drive or the like.

[cbale2000]

Originally Posted by nathannfm

Lobster Drive

Impressive, probably the most practical way to do that too.

Thanks for that link, it made my day.

[pimathbrainiac]

So if figured out the math/code for this using cjl2625's version of the drivetrain.

Here's a segment (Java, btw):

    final double DISTANCE_X = 1.0;
    final double DISTANCE_Y = 1.0;
    private double leftY;
    private double rightY;
    private double frontX;
    private double backX;
    //rotation is cw
    private double rotationX;
    private double rotationY;
    private double pi = 3.1415926;
    private double curr_gyro_angle_degrees = 0.0;
    private double curr_gyro_angle_radians = 0.0;
    private double temp;
    
    public void TakeJoystickInputsAndDrive(Joystick left, Joystick right)
    {
        calculatedDrive(-0.5 * left.getY(), 0.5 * left.getX(), 0.5 * right.getX());
    }
    
    void calculatedDrive(double y, double x, double rotation)
    {
        //Field-centric adjustments. Comment out for robot-centric.
        curr_gyro_angle_degrees = gyro1.getAngle();
        curr_gyro_angle_radians = curr_gyro_angle_degrees * pi/180; 
        temp = y * Math.cos(curr_gyro_angle_radians) - x * Math.sin(curr_gyro_angle_radians);
        x = y * Math.sin(curr_gyro_angle_radians) + x * Math.cos(curr_gyro_angle_radians);
        y = temp;
        
        rotationX = rotation * DISTANCE_X;
        rotationY = rotation * DISTANCE_Y;
        leftY = y - rotationY;
        rightY = y + rotationY;
        frontX = x - rotationX;
        backX = x + rotationX;
        drive(leftY, rightY, frontX, backX);
    }
    
    void drive(double y1, double y2, double x1, double x2)
    {
        //left, right
        robotDrive2Y.drive(y1, y2);
        //front, back
        robotDrive2X.drive(x1, x2);
    }

This code runs in a command called "DriveWithJoysticks," which is the default command for drivetrain.

Any problems with the code/math that you can see at the moment? I want to make sure this is sound before I pitch this to my team.

[Brandon Zalinsky]

Originally Posted by cbale2000

I actually thought of making a drive system like this, but doing it with traction wheels and have one set actuate up and down to change directions, a bit like some of the octocanum and similar drives do, but with the entire drive module (the benefit being you'd have a sort of omnidirectional drive system with traction wheels).

Check out 3958 in 2012. They used that exact design, which was successful for them.