We chose to use a custom implementation (which should be mathematically equivalent to the ramsete controller in WPILib as they are from the same paper), to minimize code changes between the Falcon testing robot and the MiniCIM robot. We also aren’t a beta team, so this seemed easier than copy-pasting in WPILib code.
We used solely the internal encoder for controls on the wrist. We already had a MagEncoder mounted on the mechanism from before, and when we compared angle numbers from the two, the deviation never exceeded 1-2deg.
This is a flawed test, as the encoders were not zeroed quite the same. However, ultimately the internal encoder was consistent enough for the 2019 game and will likely remain so for FRC purposes.
This is a big deal in the case of 6 MiniCIMs vs 4 Falcons. Of course a robot many pounds lighter would accelerate faster. Very curious to see a like-mass comparison between these setups.
@sanddrag the post states that during 4 falcon tests, the other 2 falcons were mounted but sitting idle. The mass difference is ~7.7 lbs between setups. I’ll let you do the math and see if this results in a significant difference in acceleration between the two setups.
Also, 10lbs lighter (if we pulled off the two idle Falcons), with better performance. Seems like a good thing to me.
I don’t think anyone disagrees that lighter motors are generally better.
I think the point sanddrag is making is that getting slightly better acceleration from a 100 lb robot vs a 107.7 lb* robot shouldn’t be entirely surprising, and there are now two independent variables that need to be tracked before attributing it to purely the motor swap.
*I don’t know your actual robot weight, these numbers selected simply to be nice round numbers
Fair enough, I see the desire for straight motor performance comparison, removing all feasible variables.
From our perspective, we care about overall results. So overall, our 2019 robot would have been 7.7lbs lighter and has the performance characteristics documented, had we used Falcons instead of MiniCIMs.
I know our testing isn’t the perfect scientific answer some want, but practically speaking we’re looking at holistic benefits for teams, including ours. As a beta team (and FRC team) you can count on 1678 to test things enough to validate them for our use cases.
We are not motor performance experts, there’s other people here that are way more qualified to produce and evaluate these motors on a straight performance basis (looking at you @Richard_Wallace)
My team and I weren’t part of the Falcon beta test program— and I think that’s fair, because we were included in a few earlier betas. The kind of data yours and the other Falcon beta teams have shared is more useful for making early adopter decisions than what I measure at the component level.
To perform my usual tests I will need to disconnect the electronics, and that will happen as part of a tear-down analysis. Might have to wait until mid season if 3620 decides to use Falcons somewhere on our 2020 robot.
My very quick look at some math indicates that acceleration gains due to dropping 8 lbs from a ~144 lb robot are actually rather negligible, so it would seem the increased acceleration is due primarily to the motors, not to the mass reduction. Does anyone have a good time-to-distance calculator for FRC robots?
Ignoring the initial spike in velocity for both motors, the 4 falcon setup arrives at 100in/s at 0.25 secs, while the 6 MiniCIM setup arrives at 100in/s at 0.6 secs. Thats double the net acceleration over those timesteps. Seems decisive to me despite perhaps a ~6% mass difference
Something that I was wondering was does brushless motors accelerate better than brushed motors so ILITE’s calculator would be theoretically slower than it should be?
My understanding is the motor specs should account for any differences in acceleration performance. Any better acceleration would be accounted for by the increased torque output of the motor relative to some brushed motors (which should be modeled correctly) and the reduced mass of the robot as a result of using lighter motors (which can also be modeled correctly if you put in the right weight).
Based on some earlier discussions, there is still some question whether you can attach the Falcon motors to your pneumatic system (even in the exhaust loop) since it is not clear that the Falcon motor will be rated as a pneumatic device (meeting all the rules for pneumatic devices).
Using vacuum instead of pressure definitely solves that problem as I do not believe there are any restrictions about what components can be in the vacuum system.
The pneumatic rules are geared around safety as you don’t want a device with pressurized air inside to burst. With a vacuum system, the safety aspects are reduced as the dominant failure mode would be that the component would collapse rather than burst.
I’m actually surprised that no one asked about hooking the Falcon motor up to the pneumatic system during the Q&A. I suspect that the GDC would have said that was not part of the rules that have been released so far and would have deferred the question until after kickoff. But based on how several RIs that participate here have commented, I would encourage someone to get a rules clarification on this if you intend to use pressure to provide cooling.
Were the significant dips in velocity for both the MiniCIM and Falcon setups due to wheel slip, or is there an auto-shifter in there? (or was is something else?)
Also, I just noticed that the current draws seem to be noisier overall for the Falcon sprint (significant sways in peaks/valleys). Would a possible cause be wheel slip? Just trying to understand the differences in this data vs my drivetrain sim.
My guess would be wheel slip, as the tread was rather worn on both robots.
Current measurement is inherently noisy, so I would suspect it is due to a less aggressive low-pass filter on the FX. I’m also not sure if this is measuring stator current or supply current (beta teams are using the SRX class to interface with the FX which supports reading both currents), which could contribute to the noise as well.