NEO Hall Effect Res

So there are three hall effect sensors in the NEO? I am guessing is that correct? If so I assume these will provide more than enough Resolution for anything in FIRST? I am guessing here and looking for feedback on the capability of these hall effect sensors. Are they used by the motor controller to time the pulses correctly to the coils? School me.

You can treat these hall effects sensors as a 42 PPR (10.5 CPR) encoder.
You cannot plug in an external encoder to the MAX data port while using a NEO and its integrated encoder/hall effects, as the encoder pins are shared between the data port and the NEO cable port.
More details:

As a community, FIRST has been used to brushed motors.

The combination of the brushes and the commutator assure that the rotor coils couple properly with the magnetic field of the stator.

I would prefer to see more information published on the NEOs and the motor drives.

For pm brushless motors, the rotor has magnets fixed to it. Driving the motor then requires the stator field to be commutated. In this case, the motor drive is performing the commutation electronically. At least one of the tricks is to know where to place the fields, that is where the hall sensors are involved.

Good to know I guess this is the kind of stuff the documentation will have. How do you get 42 PPR (10.5 CPR)?

3 sensors leading and falling edge trigger = 6 ?

From the announcement thread:

AHAHH! 14 poles. That I didn’t know. Makes sense… Thanks. This is where documentation would help a lot.

Am I the only one who thinks this looks (at least at first glance) like sort of a critical design flaw? Unless the assumption is that the sensors on the NEO are adequate to track rotation, even with gearbox backlash, not being able to connect a separate encoder makes it really hard to utilize these in a drive system (or a number of other systems for that matter). Basically, you’d have to run at least one non-NEO motor on the gearbox to be able to connect an encoder (easily), or just have a speed controller that doesn’t drive anything with an encoder attached to it set as the “master”.

Really hope someone comes up with a good solution to this. ::rtm::

I don’t understand/see your concern? [edit: I misread your post. I see your concern. Your 100% dependent on the sensors and cant use another encoder. I get it. The rest of my post is beofre I understood your post]

I am not sure how its different from our current line up of motors, CIM, Bags, or even 775s. None of these motors have integrate encoders. They are after market, and the CIM still has no ideal on motor encoder. (I am aware of AM encoder) . The NEO mounts like a CIM so your encoders comes off your drive shaft as it should.

For drive, I think 42 CPR is more than enough especially after reduction. The sensors do track motion because the controller use them to control the motor.

So where do you see the limitation?

Ideally, your encoder mounts to the thing you actually want to measure (wheel shaft speed), not a proxy (motor shaft speed). In the particular case of drivetrains, gear lash and chain slack are your biggest contributers to error here.

I would guess cbale is assuming you’re using joined MAX controllers to do PID, and don’t want to just mount an extra encoder and run it back to the RIO?

A big concern is the inability for the built in encoder to detect gear and chain backlash. For example, at the beginning of auto, even though the motor spins (meaning that the built in encoder counts ticks), the actual wheels may not move at first due to chain and gear backlash. To compensate for this we have always mounted our encoders on the drive shaft to measure the actual rotation of the wheel. However, when using a BLDC, as of now it doesn’t seem possible to connect the external shaft encoder to the Spark MAX.

Yes, hence my comment “Drive Shaft” and not motor shaft.

SRX encoder connected to Canifier as an external sensor?

That makes complete sense and I realized that after I posted which is why I inserted my edit in my post, however many teams only run an encoder on the drive shaft of the gearbox. This means only the backlash of the gearbox is accounted for. Any backlash in the chain going to other wheels is still an error in most designs today. Few if any put encoders on all wheels unless they run independently powered wheels like in swerve.

With NEO the problem may be the compounding error. Even if the backlash of the gearbox is small the compounding error of chain on top of the unaccounted backlash in the gearbox creates a larger difference compared to just the chain error with encoder on drive shaft.

My understanding is that using that method prevents you from using the speed controllers on-board PID processing, instead having to rely on the RIO to do it (and frankly, I’ve had MUCH better luck running encoders through the Talons than I have through the RIO). :frowning:

Perhaps a firmware update could add a feature to allow for a speed controller (Talon or Spark MAX) to pull encoder data from a different point on the CAN network (either from a CANifier or a different speed controller)? That would eliminate the issue entirely (not sure what kind of latency issues you’d run into though).

In our case the rpm of the motor and our wheel velocity are decoupled. We have a cvt on our swerve. We need to measure wheel rotation. Works great with a talon srx. Not sure if the complications of 2 controllers are worth it. I think we will stay with 775’s and srx’s. The firmware is mature and programmatically we can assure that the 775’s are not excessively loaded. Would like the efficiency of the neo’s . Motion planning is a fantastic ability of the srx’s. An absolute must for our lift this year. Neo’s seam to have a ways to go to match the capability of srx’s.

The SRX (and SPX, if I’m reading it correctly) will do this, as of at least this March. See Section 9.8 (Remote Features) of the latest SRX/SPX User’s Guide. I would expect the MAX to do this in the near future, if not at the original release.

Were you, perhaps, referring to the software reference manual, rather than the users guide?

Backlash can be a concern for accurate readings, but for many FRC challenges, how accurate does your odometry really need to be? In many cases, you’re already going to have the possibility for error elswhere anyway (wheel slip, changes to wheel diameter with wear, carpet pile, etc).

But remember the big picture of what you’re measuring for. Based on the game, does it matter if your routine is two or three inches away from where your odometry thinks it is? Is odometry going to be your primary (or only) method of positioning your robot relative to your target? What levels of precision and accuracy are really required for this particular game challenge?

Or you just connect your external encoder to the roboRIO instead of to a speed controller. Distributed control can be helpful, but it’s far from the only way to do things.

This is true, but the code could be written to ignore (insert amount of rotation of motor shaft that has no effect on the rotation of the drive shaft), thus compensating for the backlash. The amount of backlash would, without a doubt be ever so slightly different each run, so this number would have to be taken from an average from many test runs.

While it would not be as good as an encoder on the drive shaft, it would be interesting to see how accurate the hall effect sensor in the NEO would be compared to using a normal drive encoder such as the CTRE Mag encoder, and if this method was actually viable enough for precise autonomous routines.

While I agree with your overall sentiment…
I can’t help but point out that we just came off of a game where if you had .5% error in odometry for certain paths you could get a tech foul that could escalate to a card.