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

[Nate Laverdure]

This season Team 122 built a 6-CIM Kiwi Drive. Why was this a bad idea?

Here's an opportunity to freely provide your feedback-- either negative or positive.

As it turns out, "you should have just built the AM14U chassis" actually meets the criteria for an acceptable criticism here in this thread! But just barely. This assertion can be improved if you provide reasons: Would it have saved time, money, and energy? Would it have been more reliable? Would it have spared 2 CIMs which could have been more useful if they were powering a manipulator instead? Would it have resulted in a robot design that better met the specific game challenges? Would it have given us more learning opportunities and added more useful lessons-learned to our knowledge base, leading to a more-capable team in future seasons?

Both technical and nontechnical criticisms are acceptable here. Did this choice of drive system lead to less engineering inspiration that another option could have provided? If we (intentionally or unintentionally) chose to ignore the most-competitive robot design that we could have accomplished with our team's resources and built some less-competitive thing instead, did we fail to meet some key goal of FIRST? By not being as competitive as we could have been, we were acting as a bad citizen of the FRC community?


In the offseason, we started down the path to this design by building a small demonstration robot using all COTS parts. Intended as a programming test platform, this bot used 4 CIMS and 4 omnis arranged in a square:


In week 1 of the build season, we prototyped the proposed drive system using 3 CIMS and 3 omnis arranged in an equilateral triangle:


Here's the rolling chassis in week 3 of the build season:


And here's the final robot at our first event:


The system was designed for ~10 ft/s in the "cardinal" directions (the three directions parallel to the drive axles) and ~6 ft/s in the "ordinal" directions. It used AndyMark 6" dualie omnis and the absolutely bulletproof, excellent, single-speed 10.71:1 Toughboxes. To the driver, the system felt very smooth to drive and had more than enough acceleration to do complex maneuvers around opponents. It required an intermediate amount of maintenance; over 20 matches played across 2 competitions, the wheel-retaining screws that thread into the blind holes on the gearbox output shafts needed to be tightened or replaced 4 or 5 times-- even with mentor-supervised applications of Loctite.

Happy to provide more data upon request.

[wt200999]

Do you have any videos that you can post, both during initial prototyping and during matches?

You may be looking for criticism, but I love to see alternative drive trains like this at competition, and that looks like a fun test bed for your programming team. Do you use any sensors on the drive base for auton or to assist the drivers?

[Samwaldo]

I can imagine that with enough practice, this bot could do alot of out manuevering, and avoid the defense. This drivetrain reminds me of 33 this year. 4 omnis but they had the speed and drivers ability to succeed.

Personally I would up the speed. To somewhere 15+ ft/s

Theres no such thing as the best or worst drivetrain. Every drivetrain can be competitive. You guys also got to learn alot with the interesting shape.

Personally i like tank with alot of torque so i can run cycles while pushing a bot with me (i did that a few times. It was a blast and hilarious to watch).

[colin340]

[quote=Samwaldo;1385185]
Theres no such thing as the best or worst drivetrain. Every drivetrain can be competitive.
/QUOTE]

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

[Andrew Schreiber]

Having run a drive like this in FTC I'm always curious to see what the sensor set up other folks are running. We had encoders on each wheel and closed loop velocity control. We didn't have a gyro on that bot but I think it would have been useful.

What sort of control set up did you have? Feedback?

Did the 6CIM help with acceleration?

[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!

[Nate Laverdure]

Originally Posted by Andrew Schreiber

What sort of control set up did you have? Feedback?

We used a 250-count US Digital encoder on each gearbox. Using this sensor data we had PID control over each velocity component, although I believe we typically only used the P and I terms.

We experimented with a few different IMUs, gyros, and accelerometers in a 4-week-long effort to develop true field-centric control:
-- Adafruit 10-DOF IMU (p/n 1604)
-- DIYDrones ArduIMU+ V3 (Sparkfun p/n DEV-11055)
-- KOP Analog Devices gyro & accelerometer (AndyMark p/n am-2067)

In the end, however, we decided to use the KOP gyro only and limit field-centric control to autonomous only. During teleop we used robot-centric control.

Originally Posted by Andrew Schreiber

Did the 6CIM help with acceleration?

I didn't really make any scientific comparisons between the actual performances of the 3-CIM prototype and the 6-CIM final design. I really missed a learning opportunity there.

Intuitively, doubling the CIM count cut the per-motor current draw in half. In situations where we drive the fully-loaded robot straight into the wall at full voltage, this draw (sometimes called the "pushing match current") reduced from 101 A to 52 A.

However, there was also a non-technical reason that we chose to dedicate 6 CIMs to the drive system: in 2012 and 2013 we fielded robots with only 2 CIMs on the drivetrain! As you might have guessed from the 5-sided chassis, with this year's design we wanted to make major changes from our past behavior in as many ways as possible.

[Andrew Schreiber]

Originally Posted by Nate Laverdure

However, there was also a non-technical reason that we chose to dedicate 6 CIMs to the drive system: in 2012 and 2013 we fielded robots with only 2 CIMs on the drivetrain! As you might have guessed from the 5-sided chassis, with this year's design we wanted to make major changes from our past behavior in as many ways as possible.

Did you find this change to be beneficial? Not to call you out but your team missed eliminations at both of your events, was the issue the drivetrain or did it fall elsewhere?

If it was the drivetrain, what was the main reason it was ineffective at playing this game? Would you run this system again in different situations or do you feel it is unsalvageable (if so, why)?

Also, if you don't mind me asking, what was the reasoning for using only 2 CIMs on your drivetrain in 2012 and 2013?

[Nate Laverdure]

Originally Posted by Andrew Schreiber

Did you find this change to be beneficial? Not to call you out but your team missed eliminations at both of your events, was the issue the drivetrain or did it fall elsewhere? If it was the drivetrain, what was the main reason it was ineffective at playing this game?

These are the tough questions that I was looking for.

If you look at just the robot performance, I don't think we made any real improvement from previous years. Last year we had a workable drivetrain, an anemic frisbee shooter, and a sad floor pickup. This year we had a workable drivetrain, a mediocre ball pickup, and an often-broken ball shooter.

Some of the project engineering changes we made this year were beneficial: our actions during the early build season loosely resembled the engineering design process. We didn't start robot design until we had a game strategy, and we didn't start fabrication until we had a design. We allowed ourselves to "close the loop," returning to the strategy and design steps on occasions when it felt warranted. Every machined part existed in a working CAD model before it existed in real life.

Although we made those incremental improvements, we still didn't prototype nearly enough (I don't know where we would have found the time!) and I don't think our strategy decisions were entirely based on a realistic understanding of the game dynamics (not sure how to solve this one either). We're also at serious risk of backsliding towards our previous behavior.

I believe the single biggest reason for our poor performance was lack of practice. Our total practice time measured in the single-digit hours.

Originally Posted by Andrew Schreiber

Would you run this system again in different situations or do you feel it is unsalvageable (if so, why)?

I think I would totally use this system again in an FRC game, even if it turns out to be inherently flawed. I think this probably means that I'm never going to get a blue banner :/

If I used it again, I'd make a few changes. At the top of my wishlist would be (1) better access for repairs, (2) better wheel retention, (3) a chassis design that doesn't rely on the gearbox frame for internal support, and maybe (4) some follower wheels for additional position-based sensor feedback.

Originally Posted by Andrew Schreiber

Also, if you don't mind me asking, what was the reasoning for using only 2 CIMs on your drivetrain in 2012 and 2013?

Of these questions, this one is the easiest to answer: There were no reasons for these decisions. All our team had was a weak desire to conserve weight and zero understanding of the physics of electric motors. We didn't follow anything resembling the engineering design process, and we certainly didn't do any math before building a robot subsystem.

My primary goal for the 2014 season was to be a better mentor to the students who want to pursue engineering. Working towards the engineering design process, justifying design choices with analysis, and breaking down unjustified beliefs that don't stand up to rigor were the major areas where I spent most of my energy this year. I feel like I was only partially successful and have a lot to learn.

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

[Andrew Schreiber]

Originally Posted by Nate Laverdure

These are the tough questions that I was looking for.

If you look at just the robot performance, I don't think we made any real improvement from previous years. Last year we had a workable drivetrain, an anemic frisbee shooter, and a sad floor pickup. This year we had a workable drivetrain, a mediocre ball pickup, and an often-broken ball shooter.

Some of the project engineering changes we made this year were beneficial: our actions during the early build season loosely resembled the engineering design process. We didn't start robot design until we had a game strategy, and we didn't start fabrication until we had a design. We allowed ourselves to "close the loop," returning to the strategy and design steps on occasions when it felt warranted. Every machined part existed in a working CAD model before it existed in real life.

Although we made those incremental improvements, we still didn't prototype nearly enough (I don't know where we would have found the time!) and I don't think our strategy decisions were entirely based on a realistic understanding of the game dynamics (not sure how to solve this one either). We're also at serious risk of backsliding towards our previous behavior.

I believe the single biggest reason for our poor performance was lack of practice. Our total practice time measured in the single-digit hours.



I think I would totally use this system again in an FRC game, even if it turns out to be inherently flawed. I think this probably means that I'm never going to get a blue banner :/

If I used it again, I'd make a few changes. At the top of my wishlist would be (1) better access for repairs, (2) better wheel retention, (3) a chassis design that doesn't rely on the gearbox frame for internal support, and maybe (4) some follower wheels for additional position-based sensor feedback.


Of these questions, this one is the easiest to answer: There were no reasons for these decisions. All our team had was a weak desire to conserve weight and zero understanding of the physics of electric motors. We didn't follow anything resembling the engineering design process, and we certainly didn't do any math before building a robot subsystem.

My primary goal for the 2014 season was to be a better mentor to the students who want to pursue engineering. Working towards the engineering design process, justifying design choices with analysis, and breaking down unjustified beliefs that don't stand up to rigor were the major areas where I spent most of my energy this year. I feel like I was only partially successful and have a lot to learn.

I'm going to cheat and ask the same questions from both a competitive robot perspective and a team growth perspective.

Do you feel that this drive system was a beneficial use of team resources?

What did you gain by utilizing this system over other options (notably the AM14U KOP Chassis or comparable VexPro Options)? What did you lose?

Do you feel the pursuing this drive system positively or negatively impacted your efforts on other systems/pursuits?

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

[scottandme]

Great thread so far. Given finite resources, how best to allocate them?

Originally Posted by Nate Laverdure

As it turns out, "you should have just built the AM14U chassis" actually meets the criteria for an acceptable criticism here in this thread! But just barely.

Not just barely - you say it yourself...

Originally Posted by Nate Laverdure

Here's the rolling chassis in week 3 of the build season:
<photo>

Kitbot: Day 1
Kiwi: Week 3

Originally Posted by Nate Laverdure

Last year we had a workable drivetrain, an anemic frisbee shooter, and a sad floor pickup. This year we had a workable drivetrain, a mediocre ball pickup, and an often-broken ball shooter.

Frisbee shooters, floor pickups, ball pickups, and ball shooters don't come in the KoP. A "workable" (or better) drivetrain does come in the KoP. So where best to allocate resources? Into trying to replace/improve a system that already works, or into a system that doesn't exist and has less prior art to draw from? Rule to thumb is to sink resources into endeavors that provide the greatest gain for the smallest effort. Plenty of teams winning events with the kitbot. Plenty more who build custom drivetrains that are worse than the kitbot.

Originally Posted by Nate Laverdure

Although we made those incremental improvements, we still didn't prototype nearly enough (I don't know where we would have found the time!) <snip>

I believe the single biggest reason for our poor performance was lack of practice. Our total practice time measured in the single-digit hours.

See above: Day 1 to Week 3. You just got half the build season back. I would guess that building the kiwi probably costs at least as much as buying another kitbot. Use those funds to buy another kitbot - boom, instant practice robot/drivetrain mule for your drivers to use starting week 1, while other subsystems can use the "real" kitbot for systems integration.