We built a 6-CIM Kiwi Drive. Criticisms please!

[JamesCH95]

Gearing a single drive for 15ft/s seems... optimistic IMO. Can you change out gears to change your drive speed? If so, experiment! Try recording times for a few bench-mark maneuvers, like sprinting half-field, going through a slalom course, etc.

Originally Posted by colin340

Please find me one case of 2 wheel ackerman steering being competitive (single single handily wining a quals match) .


i think you will find there is way more to be learn and from a WCD (8wd is king) 6 cim SS geared to 10-13 FPS for acceleration (LISTEN TO 610)

but yeah needs to be way faster

See 2008 for successful Ackerman robots. Or #40 from 2011, which very successfully executed a two-axle Ackerman steering robot.

610's 2013 drive was 6WD. 8WD is not necessarily 'king' in the tank-drive world.

Samwaldo is right, there's no inherently 'best' or 'worst' drive train design. Like any other FRC mechanism the success of a drive-train hinges entirely on it's execution and proper integration with the overall robot design and game strategy. Devil in the details and whatnot...

[Samwaldo]

Just to elaborate. Some of the "worse" or less competitive drive trains, are the best drive trains when it comes to experience and learning. This is one of those. The students probably learned a lot, which is what FIRST is all about.

NOTE: As a driver (3 years) I would love to try this out!

[Ether]

Originally Posted by Nate Laverdure

Happy to provide more data upon request.

OK, three questions:

1) what was your driver interface? e.g. did you just give the driver direct access to the 3 degrees of freedom (fwd/rev, strafe R/L, rotate), or did you put a layer on top of that to abstract it to a more intuitive level? one mode or several? etc

2) Did you derive the inverse kinematics from first principles, or did you refer to available papers on this topic?

3) Why was field-centric problematic? Were you having gyro drift problems, or did you encounter difficulties with the programming?

[Nate Laverdure]

I'll have a hard time answering these but I'll give it a shot; my ability to converse intelligently about programming is very limited.

Originally Posted by Ether

1) what was your driver interface? e.g. did you just give the driver direct access to the 3 degrees of freedom (fwd/rev, strafe R/L, rotate), or did you put a layer on top of that to abstract it to a more intuitive level? one mode or several? etc

Just two modes:
Robot-centric control allowed the the driver to adjust the setpoint of the PID loops for the 3 DOFs you listed.
Field-centric control added a layer of abstraction: the translation DOFs became north/south and east/west.

My understanding is that teams attempt these kind of field-centric control schemes all the time, but the drift in FRC-grade gyros often makes them unusable after ~10 seconds. Our original intent was to counteract this by integrating the data from multiple gyros with robust "sensor fusion."

Originally Posted by Ether

2) Did you derive the inverse kinematics from first principles, or did you refer to available papers on this topic?

I made sure the literature was provided, but I'm fairly certain my programming student derived everything from scratch. I believe he also threw out a couple of the WPI libraries and rewrote them. The often-spotlighted Matt Kline quote comes to mind: "A good programmer can look at a library, decide he hates it, and code everything from scratch. An amazing programmer can look at a library, decide he hates it, but realize the time it will save him and learn to use it." I hope to work on this with him next year.

Originally Posted by Ether

3) Why was field-centric problematic? Were you having gyro drift problems, or did you encounter difficulties with the programming?

I believe even the KOP gyro was fairly stable. Two main problems stick out in my memory:
-- Issues with communicating with the IMUs via any of the available protocols. One of the IMUs had an on-board microprocessor that supposedly provided built-in sensor integration, but we were never able to get access to this predigested data. We lost ~2 weeks on this. We ended up duplicating this capability by building a Kalman filter that ran on the cRio, ready to recieve the raw input from multiple sensors. I don't quite remember the rest of the story, but in the end we were using only the KOP gyro.
-- Whatever this was. We lost another 1.5 weeks on this.

[Ether]

Originally Posted by Nate Laverdure

the drift in FRC-grade gyros often makes them unusable after ~10 seconds.

Did you try all the suggested ways to mitigate this?

- make sure your robot is perfectly still when the gyro is being calibrated ("still" as in "not moving" and "not vibrating (e.g. compressor off)")

- make sure the gyro is at operating temperature before calibrating

- add a button for the driver to re-zero the gyro when the bot is pointing in the zero direction.

I made sure the literature was provided, but I'm fairly certain my programming student derived everything from scratch.

Would he be interested in posting his equations for discussion on this forum? It's possible they were not exactly correct, and this could have affected your attempt to implement field-centric control.

I believe he also threw out a couple of the WPI libraries and rewrote them.

I don't think the WPILib has any functions that would be usable for your 3-wheel asymmetric kiwi arrangement.

[Nate Laverdure]

Originally Posted by Ether

Did you try all the suggested ways to mitigate [gyro drift]?

I believe so. The "calibrate only when compressor is off" suggestion is an excellent one that I hadn't heard before. I understand that the quality of the KOP gyro varies considerably from batch to batch, and I think we got a good one.

Originally Posted by Ether

Would he be interested in posting his equations for discussion on this forum?

I will ask. He's going to be my intern this summer, so I can assign him this task as a special project

Originally Posted by Ether

I don't think the WPILib has any functions that would be usable for your 3-wheel asymmetric kiwi arrangement.

Excellent catch! We accounted for the asymmetry in the control design.

[cxcad]

Why not build a tex-coast drive? From what I read and understand is that you do not need fancy machinery to build it. I believe 624 did it without CNC.

[Gregor]

Originally Posted by cxcad

Why not build a tex-coast drive?

Stop calling it that, it's unneeded and confuses people.

[Caleb Sykes]

Originally Posted by Nate Laverdure

I believe so. The "calibrate only when compressor is off" suggestion is an excellent one that I hadn't heard before. I understand that the quality of the KOP gyro varies considerably from batch to batch, and I think we got a good one.

I will ask. He's going to be my intern this summer, so I can assign him this task as a special project

Excellent catch! We accounted for the asymmetry in the control design.

Would you mind giving the relative positions/orientations of the wheels, I am trying to determine your theoretical max velocity in any given direction. My guesses are (back center wheel at (0,0) and oriented east/west):
front left: position = (-16,-25)in oriented 22.5 degrees west of north
front right: position = (16,-25)in oriented 22.5 degrees east of north

EDIT: changed front and back to reflect Nate's response.

[Nate Laverdure]

Originally Posted by inkling16

Would you mind giving the relative positions/orientations of the wheels, I am trying to determine your theoretical max velocity in any given direction. My guesses are...

BOLD ITEMS ARE EDITED TO ADDRESS CONFUSION:
back middle: position = (0,0) oriented west
front right: position = (-15.9,-18.5)in oriented 30 degrees west of north
front left: position = (15.9,-18.5)in oriented 30 degrees east of north

There's 120 degrees between the directions of each neighboring wheel.

[Ether]

Originally Posted by Nate Laverdure

The wide-set front wheels ensured that a very small amount of weight was cantilevered outside of the supported triangle.

Originally Posted by Nate Laverdure

back left: position = (-15.9,-18.5)in oriented 30 degrees west of north
back right: position = (15.9,-18.5)in oriented 30 degrees east of north

To facilitate dialog and minimize confusion, are the wide-set wheels front or back?

[Nate Laverdure]

Originally Posted by Ether

To facilitate dialog and minimize confusion, are the wide-set wheels front or back?

C'mon Ether. You know an omnidirectional robot has no front or back.

[Ether]

[edit]OBE. I see you edited your prior post[/edit]

[Kingland093]

The drivetrain looks good!

I would recommend having lots of driver training. My team had a similar issue as you guys in which we lost a lot of time early on in the build season and had very little time for driver training (about 2 hours total) and that killed us at our regional. To me, it's not as much what you're driving but how you drive it.

Hope this helps

[Caleb Sykes]

Originally Posted by Nate Laverdure

Close.

Well, in one direction at least.

Okay, I was thinking that the back wheels were at 22.5 degrees because the 80-20 mounting plates on the back end and on the 45 degree piece looked similar. That makes for a much simpler problem.

This makes me curious though, has anyone ever done a kiwi drive with the wheels not all oriented at 120 degree angles relative to each other?