OP - I’d use caution when using this style of blanket analysis. Every pro or con is rooted in some physical fact about the motor. Depending on the use case, each fact might be a pro, or might be a con, or may not matter at all.
Falcon is an integrated motor and controller.
If ease of repair of each individual component is a priority, this is a con.
If keeping the design compact as possible is a priority, this is a pro.
If you have enough money to replace both, and also have space to spare, it doesn’t matter.
I know you mentioned you’re trying to sort out the details - I assume this means you’re still in the early learning phases. Keep in mind in the learning process - it’s hard to jump straight to the end. If you really want a solid answer on “which is better”, understanding the underlying principles of how motors work and interact with a robot is the first step. From there, you work toward understanding how to apply these principles toward decisions like these motors.
The good news: Both of these motors are super powerful and easily controllable, and built for FRC purposes. Though I can’t say they’re completely interchangeable, I find it hard to come up with a situation where one would definitely work and the other would definitely not.
Rearrange one letter by accident. Flacon is a small bottle, while Noe is either the name Noah in French or the first three letters of noetic. I like small bottles, and it took less effort to mess that one up, so therefore the Falcon (flacon) is superieur.
When you run path following algorithms, the positional error accumulates. From what I understand, the issues 254 (and likely 1690) faced are actually with the positional resolution, not the velocity resolution. The 0.050" resolution that somebody calculated earlier seems like it could be fairly coarse, though I don’t know from experience.
Based on my limited experience with the NEO and Spark Max this off-season, you are mistaken about the first three claims in this post.
On a swerve drive with a 20 :1 steering gear ratio, the effective cpr at the wheel is over 800, so the angle is measured to within half a degree. Just like with the falcon though, it is important to minimize backlash.
We were also able to plug an absolute magnetic encoder into the spark using an analog encoder breakout board from CTRE, and read the values.
We also ran a position control loop on the Spark Max, and found that the system performed much better than our last years swerve steering. (It’s able to turn 90° accurately in < 1/10 second)
As to your final statement, I have not tried to run a velocity control loop yet, but I do know that velocity control is not necessary to have a competitive auto mode. (You guys seem to have done a solid two hatch this year and we did a 4 cube auto in 2018 without it.)
Here are my pros and cons:
Easier packaging (get to chose where the controller goes)
Cheaper (not just because teams already have them)
Heat from the coils dissipates nicely through the front of the case
Lots of on field testing (with mostly good results)
Spark max firmware continuously gets new features
The encoder cable comes with a horrible connector for the application (imo) and shortening or lengthening that cable is a real pain.
The case if the motor must be removed ro press on pinions, and the screws that hold it on are a terrible design (too small of hex key and too strong of loctite)
Constant updates to the firmware mean that I’m not sure the code we are writing now will work in build season, and the new firmware doesn’t get the advantage of on field testing
You should never need to press a pinion on
Teams have good experience with the motion magic and other control options
Library is probably more feature complete
No encoder cables required
High resolution feedback in case you want to use velocity control on a system that will go slow (relative to free speed)
Replaceable output shaft
So powerful it could likely torch itself (or pop the 40A breaker) in less than a second without software limits (this could be addressed in firmware)
Requires buying a replacement shaft or all new pinion gears
The coils will conduct their heat into the back of the motor (where the motor controller is)
On field reliability is a unknown factor
Toasting a motor kills its controller and encoder
Can bus will have to run to all motors
Cannot plug in external encoders.
If both motors came out last year, both showed good reliability, and my team had experience with the talon SRX, I would recommend we invest in the falcon. However, as it stands, I only recommended that we buy a few for testing. I think for any team that has a bunch of neos and is happy with them, it’s not worth being an early adopter.
This is not really true. I’ll do the calculation at the NEO stall current, which is obviously over the current of the main breaker, but it scales even once you limit input current to the motors.
The NEO generates 3.36Nm of torque at 166A and 12V. That makes for 1992W of input power.
The falcon generates 4.68 Nm of torque at 257A and 12V. To generate the same amount of torque at stall, you would apply (3.36/4.68)*12V = 8.62V. Accordingly, the motor will pull (3.36/4.68)*257A = 184.5A. This amounts to a 1582W of input power, around 400W less than the NEO.
Extra power in a motor is not wasted: it goes directly into allowing you to operate at a lower input power.
On the same token, for the average team, CIMs are functionally the same as well. There are advantages to be gained from moving up to stronger motors, but there are bigger changes a team can make to improve without spending extra money.
Something that seems to not to have been mentioned is the cooling options for the Falcons. This provides more options for how teams cool their motors during and after matches.
I wouldn’t call the Neo “tried and tested”, personally. I have real concerns about the quality of the firmware running on the spark max. We had multiple times last season where the controller Would refuse to drive the motor. During these times, the controller would report everything as normal while in a clearly non normal state, with the only remedy being power cycle. Fortunately this only took out our drive once in a real match, but it was a constant fear until the end of the season.
The motor is probably fine for teams to use, but I wouldn’t use time on market as an analog for risk.
I also personally view the built in controller on the Falcon as a huge win as it frees up space on the base plate which is always a giant pain to manage. To each their own though!
What’s really nice about if for me is that you can use motion magic for arms or elevators and not have to worry about backlash. For drivetrain applications, we already plug our encoders into the rio, but teams that use the ctre motion profiling it is a huge advantage.
We’ve also had this issue with our very minimal testing of the neos. It makes me happy that it wasnt my fault it happened but also turned off of using neos next season. Is there any other weird neo specific thing you noticed throughout the season?
The Falcon looks like a great package, and the integrated controller reduces wiring connections.
The Falcon is quite a bit longer than the NEO. This may not matter to most applications, but the compact length of the NEO opens up some really useful possibilities for packaging it within assemblies (Team 33’s off-season swerve, Flipped NEO gearbox in tube WCD chassis). I suppose that such designs could be reconfigured to fit the Falcon, but sometimes smaller is better.
This is a great point. I was ready to refute it and started tinkering in Excel, and you’re totally correct. If you’re running under 12V, the Falcon outperforms the NEO by a good margin.
Here’s the scenario that I just put together.
I have an elevator with a NEO on it, and it’s set up to hold in place at 3V. That means that the NEO is pulling 41.5A and delivering 0.84 Nm of torque, which takes 125W. If you scale the Falcon curve to match the free speed of the NEO curve, then the Falcon will hold the same torque at ~2V, drawing 42.4A for an input power of 84W, which is 33% lower.
Gotcha, thanks. The cumulative odometry error was not something I had considered.
In our use case, though we closed-looped on velocity to and motion-profiled to achieve a position, we had limit switches to reset odometry to known numbers at the limits of travel. This would not be the case for a drivetrain.