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

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

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

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

[Nate Laverdure]

Man, the questions keep getting harder to answer. I love it.

Originally Posted by Andrew Schreiber

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

That's fine. In my mind I mix the two anyway. Plus this gives me an opportunity to display my answers in a table:

[Kevin Leonard]

Competitive success and learning about engineering do not have to be separate ideas.

There's a student on our team right now who is disgruntled. He thinks we focus too much on competitive success, and he believes that building the same traction drivetrain each year doesn't help students as much as building something crazy, like a kiwi drive, that may not contribute as much to competitive success.

I'm going to try to address both your situation and my teammate's situation simultaneously, so bear with me.

In my humble opinion, students working with a kit-bot chassis can learn just as much, if not more as students working on a kiwi drive- however these might be different things.
There is so much to learn about a six-wheel drivebase that you can't learn from a kiwi drive. Factors involved in pushing matches, like current draw and breaking traction, as well as the advantages and disadvantages of different gearing ratios. I've learned near everything I know about these topics from my involvement in FRC on a team that uses nothing but traction drivebases.

And as you said, your shooter didn't always work when you wanted it to. By investing time into your kiwi drivebase, you lost time to work on your scoring mechanisms, which ended up unreliable. Tons of engineering hours can be put into making these other systems great. Reliability is much more difficult to engineer into a system than teams like 1114 and 254 make it seem, and having some time to work out the kinks in your subsystems- whether through prototyping or through practice time- is what makes these teams great.

And despite what some people might say- it is possible to be competitive with a non-traction drivebase in the right game if you so choose. The two teams that come to mind are Team 2052, KnightKrawler from Minnesota and Team 1425, Error Code Xero from the Pacific Northwest.
2052 uses a mecanum drive most years, and 1425 uses some sort of kiwi drive (correct me if I'm wrong). These teams are successful not because of their drivebases, but because their scoring mechanisms are so well-tuned and their drivers so practiced. 2052's drivers in 2013 were among some of the best in FRC.

What would I suggest for next year? There is no situation that has yet occurred in FRC where a 6-wheel traction drive is a bad idea, and the kitbot is a good and affordable drivetrain that can provide many lessons in engineering.

However, if you intend to stick with a Kiwi drive, figure that out Week 1 and have it built by the end of week 1. Then work on your scoring mechanisms and have your drivers start practicing with driving Week 1.

And good luck.

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

[asid61]

The thing is, having already made a "kiwi" drive makes the next year's drivetrain much easier. Maybe not day 1, but defeinitely much earlier design-wise. Whenever doing a new drivetrain, be it WCD or kiwi or swerve, it should always be prototyped in the offseason. Doing radically new things during the season tends to have problems in my experience.

Personally, I always say "play for the endgame". This is true for many competitions that I've seen. By "play for the endgame", I mean that selecting the most effective drivetrain and practicing with that will turn out better (eventually) than using easier drivetrains (like kitbot) and being unable to modify effectively.

To OP:
This looks super clean! The creativity aspect of using 3 wheels in an equilateral shape makes this worth it IMO. New ideas get us places. Even if we don't like those places very much lol.

Now, about the kiwi drive:
-Does wheel slippage make for lower efficiency? Have you tested the electrical current levels against a 4-wheel or 6-wheel drive for the same speed?
-Is programming very tricky? Is it easy to implement with a different wheel spacing?
-How much does the basic chassis weigh, not including electronics (with or without motors)?
-Did you have tipping problems due to the 3-wheel design?
-Did the pointyness help you very much?
-What kind of traction did you see with this?

[Ether]

Originally Posted by asid61

The creativity aspect of using 3 wheels in an equilateral shape makes this worth it IMO.

The fielded design did not have equilateral placement of the wheels. That's why I asked about inverse kinematics.

[Nate Laverdure]

Originally Posted by asid61

Have you tested the electrical current levels against a 4-wheel or 6-wheel drive for the same speed?

What's interesting about omni and mecanum drives is that the rollers have small but significant friction (especially when you apply an axial thrust load!). When you arrange 4 omni wheels in a rectangle, you get a drivetrain that prefers to travel in the cardinal directions and dislikes traveling in arbitrary, off-cardinal directions. With a triangular design you don't have this issue, but with a hexagonal design you would. When it comes to the number of drive wheels on a kiwi-bot, any odd number greater than 2 would work!

Originally Posted by asid61

How much does the basic chassis weigh, not including electronics (with or without motors)?

Originally Posted by asid61

Did you have tipping problems due to the 3-wheel design?

Nope. The wide-set front wheels ensured that a very small amount of weight was cantilevered outside of the supported triangle. Also the robot's CG was extremely low even when carrying a ball. Bumpers were slammed to the bottom of the bumper zone. I just wish I could have gotten the battery lower and less exposed.

Originally Posted by asid61

Did the pointyness help you very much?

Actually, the flatness did. The chassis shape gave us an extremely wide, flat front that we used for ball corralling and a blocking-style defense.

Originally Posted by asid61

What kind of traction did you see with this?

Wheel static COF in the direction of travel is supposedly 1.0 (compare to the KOP HiGrip). We did not test this. We also chose this design path with the understanding that we would avoid pushing matches and attempt to avoid defenders instead. Even with an open field, I find that you can do a lot of high-quality defense without needing to touch your opponent. Unless they're really aggressive, most drivers will choose to avoid defenders instead of barreling straight through them.