Definitely. Making stuff on top light weight, is far more helpful than making stuff down low (the drivetrain) light weight.
We’ve hardly ever tried to make the drivetrain light, and the only times we’ve had trouble with tipping have been when we went to a wide robot…and we’ve finally learned our lesson about that, I think.
I think you might find this plot surprising:
(Assumes a robot geared for 15 feet per second free speed and a 250A total robot current limit).
Your design was very similar to ours. We, too, went with butterfly and had what we thought was a quick scoring machine that wouldn’t be pushed by defenders.
We used VexPro 4" Mecanums butterflied with (initially) 4"x2" Colsons, which have a really high friction coefficient. Week 1 was with CIMs for the drivetrain but we switched to Neos after our first tournament. The justification was for reduce weight to fix our hab climber and hatch intake, but the power of the brushless motors greatly enhanced the usefulness of the mecanums. Even then we still could be pushed around, so the kids also made the decision to switch out the Colsons¹ to 4"x2" wheels with Blue Nitrile traction grip after our second tournament. This has worked better.
The drivetrain story and its subsequent evolution was impressive enough that the judges for our division at Michigan State Championships bestowed on us The Industrial Design Award.
We were lucky in that our teams is in Michigan and defense had become an issue fairly early in the season at many of the districts. So we realized that we needed to get in the weeds and figure it all out.
My kids started strategizing and then practicing defense and basic counter defense. There are keys to good defense that a majority of teams haven’t picked up on yet since they never saw it done well.
Most teams think of getting through defense like one-on-one hockey or basketball, the robot giving enough juking moves to get an opening and then powering through the defense to score has won and there will be much high-five slapping amongst them!
But I’ll give you the basics of a good defender:
a) I think its well established that this years game is mostly based on cycle times. The team with the lowest cycle times (+ hab bonus) will win.
b) Therefore the goal of a smart defender should not be to actually stop pieces from being loaded. It’s simply to do everything possible to delay the other team from scoring. If you cause a 5-sec cycle time robot to take 20 seconds before they power through you and score, that’s a huge win.
Its also why the park-in-front-of-the-rocket strategy is highly sub-obtimal use of a robot. (And this weekend, I saw way too many teams teams employing it even on Houston Einstein). Sure you shut down three ports, but every decent drive offense team will simply go elsewhere and keep up their cycle times, while they come up with a strategy for one of their less capable alliance partner to push them out of the way after everything else has filled.
Anyhow as you can tell my kids are looking forward to having fun this weekend.
¹ Postnote: After we had replaced the Colson Wheels and they were sitting on the table, it became apparent what the real problem was. They come from the factory gently arced so despite being two inches wide the actual contact point is actually only around 1/2". I’m pretty sure if we simply would have sanded them flat they would have worked much closer to the way the design kids had calculated.
Not a “high-ranked” robot, but here’s our max weight robot at it’s “balance point”.
Aside from optimized gearing, don’t forget to take into account the actual robot size, bumper material, and bumper shape WRT being able to evade defense.
Hey FOPC pit neighbor! Our robot had a very similar balance point. Very annoying when you’re actually trying to tip it over to work on the underside 
I don’t necessarily agree with this, although in some circumstances it may be true. From my observations very fast bots easily avoided defenders most (not all) of the time. When leaving a loading station, these teams would aim at the defender --who was usually parked between the rocket and the cargo ship, then at the last moment juke and head to the opposite rocket or side of the cargo ship causing the defender to chase. Since the defender was almost always slower, they caught up just after the cargo/hatch was placed.
AriMB is so right when they said, “Any time where you’re engaged with a defender is time you’re not scoring.” So, don’t engage–avoid.
Luckly, at the SBPLI regionals this year we were fortunate to have Zebra Technologies be permitted by FIRST to test a new real-time location tracking system (DART). It’s the same one they use for the NFL to track players and the football.
According to that, team 1796 hit 16.7 fps!!! We were the second fastest at only 14 fps. That’s real speed, not what everyone calculates their robot to be able to do. Robotigers (1796) used that speed and avoided defenders quite well.
Another component of defensive speed to take note of is sprint vs top end. This year’s game is essentially 1/2 field scoring (or less). You don’t need top end speed, you need very fast acceleration.
Sweet COG, is it same fore and aft?
With regard to simple drivetrains, by far the best on defence is tank tread. I haven’t seen this style much, though, probably due to 2016 being about the only game where this makes sense because it’s about the one way not to be beached.
With regard to more complex drivetrains, swerve or butterfly are both good options for both defence and offence. Swerve because it’s possible to make a reasonably hard to push configuration, and you can use traction wheels, among other things. Butterfly because you can have both traction and agility.
Yup. Our COG sits dead center just above the middle wheels on this robot with the intake folded in.
(When the intake is folded out it can’t tip forwards and it’s even harder to tip backwards.)
Also, if you have not experimented with autoshifting, I highly recommend it (especially in combination with a smooth shifting mechanism such as a ball shifter). It really is seamless if you do it right, and it’s not hard to do right.
I feel that driving has just as much impact as the design. I’ve seen so many matches where the offensive team just wants to brute force their way past defense when there were open areas on the opposite side. I’ve also seen counter defense players pin the defender yet the offensive robot still want to be on the same side despite scoring opportunities on the other side.
As well as, acceleration and top speed (or swerve) mean nothing if you can’t control it. 16 fps from point a to point b is great for rushing to the loading station or playing d. 16 fps while hitting everything in front of you, no good.
This is true at least in theory, and somewhat in practicality. I think blue nitrile on carpet is grippy enough that even with only 100lbs on it, you’re still getting loads of grip. I think in general you can design around keeping traction even with a light robot.
With 6-motor drives in a game where it’s optimal to gear for short sprint distances, this is doubtful. It’s especially doubtful with NEOs (see the graph I posted above).
Ok - not doubting - curious for my own understanding:
I see for a 6-NEO drivetrain geared for 15 ft/sec, the Y axis shows ~400 lbs of applied force. Is this the force the wheels apply to the ground assuming infinite coefficient of friction?
Yep.
Edit: As a challenge, see if you can figure out why current limiting results in a higher output force at stall (note that the plot does not take into account brownout protection).
Ah Ok, hence the “doubtful” portion - a 100 lb robot delivering 400lbs of force to the ground requires a minimum static coefficent of friction of 4.0. This is absurdly high. Thank you, I have learned today!
I saw that inversion and was confused for a short bit, but I believe it makes sense…
Assuming you have modeled a battery as a non-ideal voltage source…
Battery voltage will drop with increased current. Since P = V*I, and V & I are dependent on each other, there is an optimal V-I combo for maximum power delivery from the battery.
Six Neo’s near stall will draw a LOT of current. So much so that it will pull the battery voltage way down. Without brownout protection, the pull-down will be quite extreme. So extreme that the battery voltage will drop down to the point where V has gotten smaller, such that the output of the motors has been decreased.
Putting in a current limit pushes your operating point back toward that optimal V/I point of battery operation, where enough energy is delivered to your motors to get higher rimpull force.
That being said, I would assume that 6 un-protected stalled NEO’s would start to do damage to a battery if left stalled for any length of time. This isn’t a region of operation you want to live in if you can help it.
Correct! It’s a funny quirk, that.
For a post-season analysis, perhaps poke around with a one of the few calculators that help draw out what’s happening with the acceleration profile. Just by inputting a few parameters, it looks like your robot takes ~9 feet to accelerate to full speed. For perspective, this is about half the distance from the player station to the rocket. The root causes seem to be the robot weight, the target gearing, and only 4 motors on the drive.
Moving to 8 NEOs reduces the acceleration distance to 5.5 feet.
Assuming a 12:80 reduction for the Mecanum and 4 NEOs, changing the 12-T to the 10-T pinion (217-6334 on this page) changes the acceleration distance to 6.0 feet, and actually reduces total time to target (the rocket) by ~10%.
As far as pushing is concerned, I took ‘pushing’ out of my calculator since it focuses on strategic offense and power management.
Here is my calculator. It links to a few sources of the math:
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
