It now is past week one. How well did the NEO motor work?
0 voters
Also, how were the Spark MAXes?
0 voters
My favorite part of the NEO isn’t how good the motor itself is (even though it is pretty good) but the fact that it will probably cause REV, Vex, etc. to start heavily investing into brushless motors which will hopefully improve the overall landscape of frc.
For all those who dislike them, what’s wrong with them?
For those who do, what’s the advantage?
From a more mechanical perspective I love how compact they are. I can do stupid stuff with them like making a flipped gearbox with the NEOs sitting right behind the wheel. I’ve heard from our electrical and software people that Spark Maxes aren’t that great so I also like how I don’t have to deal with any of that stuff.
What are the motor controllers like? I’m sure there are bugs with them being so new.
Love:
Dislike:
We designed our robot so that anywhere a NEO was, we could swap it with a miniCIM and we added our own encoder mounting. Thankfully we haven’t had to swap for MiniCIMs, but we did need to use our own separate encoders.
That being said, we’re sticking with them for now because 2 NEOs plus our drive gearbox weighs less than just a single CIM.
Could you expand on this a bit? Did you determine that you needed higher resolution? NEO won’t spin if the encoder isn’t working.
Have them reach out to us at [email protected], we’re happy to help. Also take a look at our Code Examples.
I hear ya. We keep our firmware development status public on our Trello board. We dislike frequent updates as much as you, but sometimes we find a bug that requires an update and we do our best to notify each user through email (if we have it), here on CD, and on our website.
The encoders work, but are not accurate enough to be used in place of our usual Grayhills.
I can have the software guys get a list going of their SparkMAX issues, but it’s been 2 steps forward, 1 step back since we got them back in December.
On the bright side, everything worked great at competition.
I’m probably slightly biased especially since our team was part of the beta testing and I happen to be good friends with one of REV’s software developers. Now that we have that out of the way…
For this year, anyone that doesn’t either have a few engineering mentors or doesn’t bother to reach out to REV’s support team and give them a chance is going to struggle a bit (or maybe a lot) with the Spark MAX’s (and from the looks of the poll it sounds like they probably are). The same can probably be said for any newer product, though. Our lead programmer also stated that had he not been able to work with REV so closely he would have ditched them months ago, so major props to the support team. I certainly would have ditched them by the end of week one after a bug took out half the drivetrain and cost us multiple matches, if not for everything I just mentioned (which we did eventually solve, in case anyone was wondering). When they work as they should, the Spark MAX’s have a few features that give them a clear advantage over any of the Talons and they work well (specifically the trapezoidal motion profile is the one our programmers won’t stop talking about). Though I have not been closely involved with the programming team on most matters so I may be misrepresenting/misinterpreting something.
All of the issues we’ve run into have had something to do with the motor controller firmware. Most of the problems we’ve seen would have been a bear to diagnose without a) five mentors with electrical engineering degrees that can diagnose what is happening in hardware, b) the ability to walk through issues step by step with REV to determine the root cause and get to a fix faster, and c) one programming student whose knowledge far outpaces all of us combined that can work closely with REV to diagnose software issues.
That being said, I’m optimistic that once these kinks have been worked out, these will become the new go-to. When they work, they work so beautifully and I can’t imagine going back to the Talons.
My only personal gripe with the NEOs themselves is why did the encoder wires have to be so tiny and easy to break, and somewhat difficult to unplug from the MAX’s? 
In any case, the NEOs are fantastic, and we’re pretty pleased with them.
(edit to include clarification from REV on support)
There’s a lot we would not have been able to do this year without the NEOs. Less parts + equivalent or greater power for the weight than existing options + not having to integrate encoders into mechanisms has been a big win.
I think that, all things considered, the Spark Maxes and Neo motors have great potential. And I think that technical support from Rev has been great.
Pros: The Spark Maxes have examples in all of the major programming languages (Java, C++, LabView), they have current limiting, closed loop positional control, and many other control features similar to the Talon SRX. All in all, when the Spark Maxes work as intended, they are a spiffy little motor controller. However, because this is the Spark Max’s maiden voyage into the FRC world, bits and pieces of its functionality always seem to act buggy from time to time.
Cons: Aside from having several technical difficulties with the ever changing software (like I said, I don’t think anyone has had a problem yet that Rev wasn’t willing and eager to help solve in a timely manner), the things that I really don’t like about the Sparks would be,
Not having mounting holes (as others have mentioned)
Sparse documentation,
Having the power and encoder cables come out of the top side of the Neos (not too big of an issue, but it does make the cables more prone to damage)
And I really wish that they would use a more robust connector for the encoders on the Neos. The connector they use right now is a jst connector with really thin wires, and if that connector were to break (which I have heard other teams have done), it isn’t a very easy fix.
All in all, I’ve personally been fairly pleased with the software side of the Spark Maxes with the Neo motors, but there is still some buggy behavior that I hope will continue to be resolved as time goes on.
We’re currently using NEOs/Maxes for drivetrain. So far, they’re working well, and we haven’t had the software/firmware problems that other people seem to have-- make sure both the firmware and the API are up-to-date, and you’re good to go.
I’ll second the complaints about the lack of mounting holes and encoder connector. Additionally, we’ve opened up one of the Maxes and noticed that the PCBs aren’t conformal coated; a minor thing, but a reliability concern.
I will start this by saying from pretty much week one/two, we knew that if we didn’t use the SPARK/NEO combination, our robot would not make weight, so we are pretty thankful for the NEO motors.
For the most part, we have had no problems with the NEOs. The only problem that we ever had with a NEO motor was when we ran some power wires too close to the JST connectors, which caused some problems that have now been fixed.
However, the SPARK Maxes have been somewhat of a problem. In addition to the other issues that have been covered in this thread, it is quite a pain to have to load firmware onto each of them individually.
As frustrating as it is, I’m personally OK with all the firmware changes - I understand where it’s coming from on a technical perspective, and they do seem to be trying their hardest to support teams. Motors themselves are working very well, documentation and code examples are very clear. One minor change I would make to the SPARK is to add mounting holes to secure the breakout boards, similar to the Talon SRX.
NEO working great on our bot controlling the arm/gripper for cargo/hatch panels. Built in encoder works great for us as we are using the CANEncoder/CANPIDController the SparkMax API provides. So from a software standpoint, we are quite happy. I can’t speak for the hardware and mechanical peeps tho. I’m sure they along with everyone else appreciate the fact that it is lighter and a built in encoder.
We’re using NEOs for the first time this year in our drivetrain, and so far we’ve been blown away. They’re lighter, more powerful, and more efficient than our 775pro drive gearboxes from last year. They’re also extremely consistent: our drivetrain tracks perfectly straight with no closed loop control.
There are 4 minor complaints that I have with the system as a whole:
The firmware has to be updated via the USB cable, there is no option to update or configure motor controllers over the CANbus using the REV utility. CTRE has this feature and it’s (IMO) way more convenient.
The brushless encoder port and CAN connectors are fragile. We’ve already mangled one (we were able to fix it with some rocket surgery on the soldering iron). I’d prefer CAN wires that are hardmounted to the board, and a more rigid connector for the encoder.
The data port doesn’t support an external encoder in brushless mode. I thought I saw something on the Trello board about enabling this through the limit switch ports, which would require an adapter board of some kind to use with the CTRE mag encoders, but would be a welcome addition. Currently we have to plug in our mag encoders to other talons (this year we used our cargo intake) and read the data on the RIO side. Perhaps some kind of remote sensor support would make this easier?
The behavior during a CAN ID conflict appears to just take down the entire CAN network. I can’t recall if the talons do this or not, but I seem to remember them not doing this. I would imagine this would be pretty easy to fix in a future firmware release.
A lot of people complained about the software, and we never actually tested the earlier versions, but we’ve had no issues so far (that are the fault of the API), and it was pretty easy for us to integrate into our gearbox classes. For a brand new product, we’re pretty impressed!
I am going to hold off on my vote until after our first event which is next weekend, but here are my two cents.
REV should have mentioned in the manual that the encoder cable is mandatory for the brushless motor. It is possible we missed it in the documentation, but also possible it is still not there.
They should also make keys that fit the slot. We are struggling to use keys that are too short, so have to rig up a system to keep them in place (I know we could cut the shaft, but do not really have the tools to do that accurately, and as has been said before, they are expensive).
The two above problems cost us a lot of time to troubleshoot. I know the latter is mostly an issue because we are using them with versaplanetary gear boxes, but we do not have to do that with a cim (I am aware that Vex says to cut the shaft, but there are ways to avoid it).
As for the weight/power, so far we are amazed. We also like the built in encoders, but have not used them much as it took us until tonight to get them working (we had to keep them out of the bag because of this).
We were a bit skeptical about using the NEOs this year after teams began releasing testing information, but in practice we have had no issues so far with the NEOs. A lot of performance in a light package. I will say that I still prefer the Talon SRXs, but motor performance wise, no issues with NEOs throughout our week 1 event. Would recommend at the moment.
We’ve run the heck out of them in practice the past couple weekends. 4 Neos have similar performance characteristics to 6 Mini-CIMs, but a heck of a lot lighter and more efficient. So far no trouble, but I don’t believe we’ve tried using the encoder functionality.
If I weren’t so knee-deep in getting the RobotPy libraries for the SPARK MAX working (or if I weren’t on my team), it would’ve been likely that my team would not be using the NEO and SPARK MAX at all.
There was a brief period of time (about 3 hours after everyone here woke up) after the latest firmware update during which my team had not received the memo that the firmware update required matching libraries… that was fun to instantly diagnose when I arrived.
There have also been a few instances where my students have claimed that the PID controller on the SPARK MAX was broken. That was fun to disprove too.