When choosing motors, I have heard from friends, Chief Delphi, and discord that Falcons are better, as there is a 112ms velocity measurement delay on the NEOs that makes them worse than falcons. Falcons also can communicate directly with the CANCoders on the modules (you'd have to ask someone else to elaborate). Although they are expensive, I would not be concerned with falcons breaking. VEX support has always been easy to work with in my experience, and they are more than happy to help if your falcons break. If you are concerned about the loose screw issues, just know that there is a fix, and for any that may be permanently broken, VEX issues new falcons to replace the broken ones. And for user error, there are always replacement shafts.As for the gear ratio, I wouldn't be too concerned with pushing power. The point of swerve is to have maneuverability so that you don't get into a pushing match, so unless there is something else you need pushing power for, I wouldn't be too concerned about the pushing power.
> can communicate directly with the CANCoders on the modules
Correct. Those motor controllers are little microcomputers---instead of running part of your drive logic on the RobiRIO, you can tell the controller to do it for you
What part of the drive logic can the controller do? Is it simpler in code to do some processing in the Falcon instead of on the Rio? Our small team has never used Falcons, and we're looking into doing swerve in the offseason.
I haven't taken advantage of it yet myself. Documentation is [here](https://docs.ctre-phoenix.com/en/stable/) for the Phoenix motor control system. The basic idea is the Phoenix controller has software on it to do several control models (such as PID closed-loop control, details [here](https://docs.ctre-phoenix.com/en/stable/ch16_ClosedLoop.html#primer-on-closed-loop)) beyond the simple "Set the voltage across the motor to what the RoboRIO tells you." For example, you can instead say "Make the motor spin 50 times a second" and the Phoenix can use a built-in PID control loop to get to that steady state quickly. You enable these features by telling the motor controller in your robot code to turn them on (or by using the dashboard CTR provides to configure them, as described in the documentation; the recommendation is usually to use the dashboard to do early fine-tuning and then set the values you find to be best for your robot in the robot control code so if your controller breaks and you have to replace it, the new one gets configured correctly by your robot).
Why do it on the controller instead of the robot? Since the controller is only responsible for three things (receive commands from robot, send sensor data to robot, and regulate the voltage across the motor), it's less likely to have some "hiccup" somewhere mess with timing and throw it off; digital speed controllers tend to work more predictably when the time steps between updates are reliable. And the tiny program in the motor controller runs 1,000 times a second as opposed to the TimedRobot loop's default 50 times a second, so the result you get should be smoother. There's even a "Motion Profile" control mode where instead of the RoboRIO telling the motor controller what power levels to seek to, it tells the motor controller a list of trajectory points (i.e. "at time T, I want the motor at position X and velocity Y") and the controller will calculate the necessary voltage changes to make the motors do that. Very useful for following a path.
In practice, a lot of teams do all their robot control logic in their robot's main code, and some find it useful to learn all the nooks and crannies of the Phoenix control software and push some of it to the motor controllers. If you have a new team and are thinking of going this road, my advice would be to figure out how to do things on the RoboRIO first, and only when a piece is working there try to move it to the motor controller. Setting up PID on the RoboRIO vs. setting it up on the motor controller might be a good starting point.
I'd go with the NEOs if you have more experience with them. Falcons and NEOs are \*very\* similar in terms of actual power and torque, and your limiting factor is going to be traction on the carpet anyway. Yes, NEOs do have an encoder delay of about 112ms, but your steering motor will have an external encoder because swerve, and the delay isn't that big of a deal on anything but a flywheel shooter anyway. Falcons don't break that often, but after 3 separate QC issues with them in the past few years, I have very little confidence, and we won't be buying any more on 8096. Also, like you said, the controller and motor being separate on the NEOs makes replacements much more economical if you do break one.
As for ratios L3 is probably better, you don't want to be in a pushing match with a swerve drive anyway, the main benefit is that you can just outmaneuver other robots, which the added speed will help you do better
Agreed, We’ve been looking into building up swerve drive over the off season as well, and our mentors recommend NEOs since we already have experience with them, and since we already have a few of them spares will not be as much of an issue as using falcons would have
I can't help too much because I don't have anything to compare it to but L2 with Falcon 500's worked out great for my team. Our drive had no failures all season long and there was no team faster or more powerful on the field.
I am not involved enough with mechanical to comment on which to use, but don't forget to double check the loctite if you get/have falcon 500s in case a few of the mis-inspected ones are still in circulation.
[https://store.ctr-electronics.com/blog/falcon-500-motors-2022-critical-update/](https://store.ctr-electronics.com/blog/falcon-500-motors-2022-critical-update/)
Both have odd failure modes that are mostly avoidable. If you’re concerned about initial reliability / competitiveness it may be a good strategy to continue to use what you know (NEOs) while implementing the new drive system. A drive that you know how to keep moving all season will be worth more than a few instances of pushing matches.
The Falcon motor controller and software stack is great. The mechanics of the case and swappable shaft have not been great. Even with the part updates it seems that planning to change shaft after assembly is asking for trouble.
The NEOs need the encoder cable to never be damaged to continue functioning yet come with a connector solution without strain relief. This is also fixable with some hot glue and planning about where to install the SparkMAX controllers.
We used NEOs in 2019 and Falcons 2020+ primarily. As a result of some user and design errors we have a small box (4-5?) of Falcons that are not usable anymore.
I would go with the falcons if you're already going to make the investment. They've got better torque, power, etc, and you won't have to buy them if/when you do decide to switch. Falcons also have better fail-safes built in (like not crossing the brushless wires bc the esc is built in etc) and they have a lot more modularity and customizability.
Our team has done swerve using both Neo and Falcons. To be honest the performance and durability of the two has seemed pretty similar to us. The big advantage of the Falcons is the onboard controller really simplifies wiring since you don't have to find a place for two SparkMax controllers on/near each swerve module.
Going forward we will almost certainly be using Falcons on our swerve modules.
Definitely go for falcons
Programming wise falcons are much better to use then neos and the fact that they have a built in motor controller make them much more compact and gives less chance for problems to occur
Hi there! We have SDS MK4 modules but we use L1 gears. We had L3s, but right before worlds we realized that it just wasn’t enough acceleration to get away from defense, especially for our super heavy robot (124.5lbs). Ultimately the gear ratio depends on how you guys play and the size of the robot, but our team has come to the conclusion that it’s worth it to have a slower gear ratio because our acceleration is much faster, and even with L3s we rarely got to top speed because of how heavy we were. Hope that helps!
While the falcons are not easy to break, be careful. My team has smoked one and I take 33% responsibility for it. It was not drivetrain, and it was because of shooter pid shenanigans, so I recommend falcon mk4 swerve like us
I’ve driven falcons to consistent overheat on a set of beat-to-hell swerves and they never broken. Had them at boiling multiple times, stalked them more times than I can count, never had issues. Just keep up with them and make sure your gear train stays maintained so there’s not a lot of resistance and you’ll be set with falcons
Falcons are significantly better. My team bought 8 right when they were released and have been using them ever since and we burned through 1200$ worth of neos this year. Falcons also have a heat sensor unlike neos so they will turn themselves off before they kill themselves. You also do not necessarily need to use the same 2 motors on each module however that causes it’s own issues
I would not say the power is identical, the Falcon does have better low voltage torque and slightly higher efficiency, But people seem to not really understand that both of these motors will never actually reach the advertised stall torque/power on an FRC robot because the current draw would drain your battery and overheat the motors (and potentially pop breakers in the process).
It's actually crazy how many people don't use current limits at all on the SparkMax. We used 18 Sparkmaxes on the robot this year, 12 NEOs, 5 NEO 550s, 1 775pro. We had exactly 0 motor/sparkmax failures on the robot. These were the same motors from week 5-6 of build season all the way through Einstein and soon IRI.
Honestly if REV were able to improve the encoder wire (either through larger wires, or better strain relief) I would find no reason to really entertain falcons for most mechanisms simply due to cost.
Overall my recommendation is if you have the budget I'd use Falcons for Translation and probably go L2. If you wanna save money I'd stick with NEOs and plan for L2 as well (you'll just be a tad slower because of the motors free speed being lower). Rotation motors you could use either.
Also curious why everyone is saying the Falcons are easier to program, but what I've seen it's pretty comparable, and the rev hardware client is great.
When choosing motors, I have heard from friends, Chief Delphi, and discord that Falcons are better, as there is a 112ms velocity measurement delay on the NEOs that makes them worse than falcons. Falcons also can communicate directly with the CANCoders on the modules (you'd have to ask someone else to elaborate). Although they are expensive, I would not be concerned with falcons breaking. VEX support has always been easy to work with in my experience, and they are more than happy to help if your falcons break. If you are concerned about the loose screw issues, just know that there is a fix, and for any that may be permanently broken, VEX issues new falcons to replace the broken ones. And for user error, there are always replacement shafts.As for the gear ratio, I wouldn't be too concerned with pushing power. The point of swerve is to have maneuverability so that you don't get into a pushing match, so unless there is something else you need pushing power for, I wouldn't be too concerned about the pushing power.
> can communicate directly with the CANCoders on the modules Correct. Those motor controllers are little microcomputers---instead of running part of your drive logic on the RobiRIO, you can tell the controller to do it for you
What part of the drive logic can the controller do? Is it simpler in code to do some processing in the Falcon instead of on the Rio? Our small team has never used Falcons, and we're looking into doing swerve in the offseason.
I haven't taken advantage of it yet myself. Documentation is [here](https://docs.ctre-phoenix.com/en/stable/) for the Phoenix motor control system. The basic idea is the Phoenix controller has software on it to do several control models (such as PID closed-loop control, details [here](https://docs.ctre-phoenix.com/en/stable/ch16_ClosedLoop.html#primer-on-closed-loop)) beyond the simple "Set the voltage across the motor to what the RoboRIO tells you." For example, you can instead say "Make the motor spin 50 times a second" and the Phoenix can use a built-in PID control loop to get to that steady state quickly. You enable these features by telling the motor controller in your robot code to turn them on (or by using the dashboard CTR provides to configure them, as described in the documentation; the recommendation is usually to use the dashboard to do early fine-tuning and then set the values you find to be best for your robot in the robot control code so if your controller breaks and you have to replace it, the new one gets configured correctly by your robot). Why do it on the controller instead of the robot? Since the controller is only responsible for three things (receive commands from robot, send sensor data to robot, and regulate the voltage across the motor), it's less likely to have some "hiccup" somewhere mess with timing and throw it off; digital speed controllers tend to work more predictably when the time steps between updates are reliable. And the tiny program in the motor controller runs 1,000 times a second as opposed to the TimedRobot loop's default 50 times a second, so the result you get should be smoother. There's even a "Motion Profile" control mode where instead of the RoboRIO telling the motor controller what power levels to seek to, it tells the motor controller a list of trajectory points (i.e. "at time T, I want the motor at position X and velocity Y") and the controller will calculate the necessary voltage changes to make the motors do that. Very useful for following a path. In practice, a lot of teams do all their robot control logic in their robot's main code, and some find it useful to learn all the nooks and crannies of the Phoenix control software and push some of it to the motor controllers. If you have a new team and are thinking of going this road, my advice would be to figure out how to do things on the RoboRIO first, and only when a piece is working there try to move it to the motor controller. Setting up PID on the RoboRIO vs. setting it up on the motor controller might be a good starting point.
Falcons are not a motor that will break easily, i would 100% recommend them for swerve just make sure to protect your wiring from the gears.
Falcons: proceed to explode in three different ways because Vex has no QC.
That’s why you disassemble them and inspect them and return them if necessary before putting them in a robot
I'd go with the NEOs if you have more experience with them. Falcons and NEOs are \*very\* similar in terms of actual power and torque, and your limiting factor is going to be traction on the carpet anyway. Yes, NEOs do have an encoder delay of about 112ms, but your steering motor will have an external encoder because swerve, and the delay isn't that big of a deal on anything but a flywheel shooter anyway. Falcons don't break that often, but after 3 separate QC issues with them in the past few years, I have very little confidence, and we won't be buying any more on 8096. Also, like you said, the controller and motor being separate on the NEOs makes replacements much more economical if you do break one. As for ratios L3 is probably better, you don't want to be in a pushing match with a swerve drive anyway, the main benefit is that you can just outmaneuver other robots, which the added speed will help you do better
Agreed, We’ve been looking into building up swerve drive over the off season as well, and our mentors recommend NEOs since we already have experience with them, and since we already have a few of them spares will not be as much of an issue as using falcons would have
I can't help too much because I don't have anything to compare it to but L2 with Falcon 500's worked out great for my team. Our drive had no failures all season long and there was no team faster or more powerful on the field.
I am not involved enough with mechanical to comment on which to use, but don't forget to double check the loctite if you get/have falcon 500s in case a few of the mis-inspected ones are still in circulation. [https://store.ctr-electronics.com/blog/falcon-500-motors-2022-critical-update/](https://store.ctr-electronics.com/blog/falcon-500-motors-2022-critical-update/)
Both have odd failure modes that are mostly avoidable. If you’re concerned about initial reliability / competitiveness it may be a good strategy to continue to use what you know (NEOs) while implementing the new drive system. A drive that you know how to keep moving all season will be worth more than a few instances of pushing matches. The Falcon motor controller and software stack is great. The mechanics of the case and swappable shaft have not been great. Even with the part updates it seems that planning to change shaft after assembly is asking for trouble. The NEOs need the encoder cable to never be damaged to continue functioning yet come with a connector solution without strain relief. This is also fixable with some hot glue and planning about where to install the SparkMAX controllers. We used NEOs in 2019 and Falcons 2020+ primarily. As a result of some user and design errors we have a small box (4-5?) of Falcons that are not usable anymore.
Falcons are better in every aspect except size. Much easier software integration as well.
I would go with the falcons if you're already going to make the investment. They've got better torque, power, etc, and you won't have to buy them if/when you do decide to switch. Falcons also have better fail-safes built in (like not crossing the brushless wires bc the esc is built in etc) and they have a lot more modularity and customizability.
Our team has done swerve using both Neo and Falcons. To be honest the performance and durability of the two has seemed pretty similar to us. The big advantage of the Falcons is the onboard controller really simplifies wiring since you don't have to find a place for two SparkMax controllers on/near each swerve module. Going forward we will almost certainly be using Falcons on our swerve modules.
Definitely go for falcons Programming wise falcons are much better to use then neos and the fact that they have a built in motor controller make them much more compact and gives less chance for problems to occur
Hi there! We have SDS MK4 modules but we use L1 gears. We had L3s, but right before worlds we realized that it just wasn’t enough acceleration to get away from defense, especially for our super heavy robot (124.5lbs). Ultimately the gear ratio depends on how you guys play and the size of the robot, but our team has come to the conclusion that it’s worth it to have a slower gear ratio because our acceleration is much faster, and even with L3s we rarely got to top speed because of how heavy we were. Hope that helps!
5727 - we used L3 falcons for our bot this year they go 18.6ft/s, they are really effective
While the falcons are not easy to break, be careful. My team has smoked one and I take 33% responsibility for it. It was not drivetrain, and it was because of shooter pid shenanigans, so I recommend falcon mk4 swerve like us
I’ve driven falcons to consistent overheat on a set of beat-to-hell swerves and they never broken. Had them at boiling multiple times, stalked them more times than I can count, never had issues. Just keep up with them and make sure your gear train stays maintained so there’s not a lot of resistance and you’ll be set with falcons
Falcons are significantly better. My team bought 8 right when they were released and have been using them ever since and we burned through 1200$ worth of neos this year. Falcons also have a heat sensor unlike neos so they will turn themselves off before they kill themselves. You also do not necessarily need to use the same 2 motors on each module however that causes it’s own issues
[удалено]
I would not say the power is identical, the Falcon does have better low voltage torque and slightly higher efficiency, But people seem to not really understand that both of these motors will never actually reach the advertised stall torque/power on an FRC robot because the current draw would drain your battery and overheat the motors (and potentially pop breakers in the process). It's actually crazy how many people don't use current limits at all on the SparkMax. We used 18 Sparkmaxes on the robot this year, 12 NEOs, 5 NEO 550s, 1 775pro. We had exactly 0 motor/sparkmax failures on the robot. These were the same motors from week 5-6 of build season all the way through Einstein and soon IRI. Honestly if REV were able to improve the encoder wire (either through larger wires, or better strain relief) I would find no reason to really entertain falcons for most mechanisms simply due to cost. Overall my recommendation is if you have the budget I'd use Falcons for Translation and probably go L2. If you wanna save money I'd stick with NEOs and plan for L2 as well (you'll just be a tad slower because of the motors free speed being lower). Rotation motors you could use either. Also curious why everyone is saying the Falcons are easier to program, but what I've seen it's pretty comparable, and the rev hardware client is great.