We are using these on a team 33 based swerve drive design.
Just curious if anyone else has any other real world of robotics experience with them?
We are using the analog into the Roborio.
We had one we’re pretty sure went bad, but we are still at a competition so could be something else going on, haven’t had time to investigate.
We find them to work ok, as expected they are pretty sensitive to magnet gap.
FYI…if you think you have a sensor that died and you didn’t kill it explicitly then please PM me and I’ll send a replacement.
Thanks - we had already talked with you (another mentor) about what we saw with this one encoder.
We need to order spares anyway…but thanks for the replacement offer
Back to my original reason for updating this thread…does anyone have any feedback on using these for 2020 robotics?
We are using them on a swerve drive, which we have never built before - so we are learning as we go…
Right now i have the encoder data cable into a break out and interfaced to the Roborio analog…based on an anecdote from other team members that PWM was not acting consistent.
Given the encoders can connect over the data cable to Talon SRX controllers, has anyone tried something similar with a NEO and Spark Max configuration?
(I’m not done sorting through the Spark max user manaul and external encoders in brushless mode…but I don’t think it will work?)
thanks!
We are using these encoders for swerve connected directly to Talon SRXs . I initially had problems with random re-zeroing until I removed to Rx pins from the IDC sockets. They have been fine since.
I also have one connected to a SparkMax through a Rev Alternate Encoder Adapter board. I broke out the power, ground and analog wires and soldered them to the analog input pads. I expect a simple breakout board would be equivalent. That has been working fine also. don’t have a lot of time on them but they have survived brownouts and driving practice.
Thanks - I hadn’t researched that Rev had a breakout board like that.
I’m not sure I have an advantage to connecting to the SparkMax versus connecting to the analog on the Roborio for our application.
I’ll discuss with others on the team…
I have noticed an issue combining the Lamprey Encoder with a SparkMax for certain usages - of which the orientation of a swerve module would be one of them. From what I can tell, the only way to connect a Lamprey Encoder to a SparkMax is to run the 10-pin ribbon cable from the encoder to the SparkMax, remove the necessary lines as described above, and then wire the analog output of the encoder to the analog input on the alternate encoder input on the SparkMax (using the breakout board or directly). This generally works fine and you can read the analog values from the encoder on the SparkMax. However, the problem occurs on the transition between 0V and 3.3V. From what I can tell, the SparkMax is taking a rolling average of voltages and then reporting that back. When the encoder is position very close to 0, though, you could get consecutive readings from the encoder of 0V and 3.3V, and then the SparkMax averages them together and tells you 1.6V - i.e., the complete wrong direction!
I couldn’t find anywhere in the SparkMax API to change this behavior. I did see a couple of methods in the JNI interface that looked like they would let you set the number of samples in the average to be 1. The methods were protected but I was able to call them via some sneaky Java coding, but they didn’t seem to actually change the behavior. Would someone from Rev (@Greg_Needel ?) be able to comment on this?
Regarding your other question, one benefit to wiring the encoder directly to a SparkMax (as opposed to the roboRIO) is that you can then use the PID controller directly on the SparkMax, which generally leads to really nice results. Running the PID on the roboRIO would work as well, but is a bit more coding that you have to do and the response rate is probably a bit slower, given the loop timing of the roboRIO code.
Have you tested this sparkMax with any other analog sensors?
The Lamprey should look like an MA3 or any potentiometer to a microcontroller.
I’d be surprised if this behavior was specific to a Lamprey sensor.
These methods are actually for changing the way the velocity is calculated, and not for the averaging and would be added to the CANAnalog class.
Your analysis is correct that the device averages several samples, the averaging behavior is fixed in the firmware at this time. We are looking into the behavior you describe.
I haven’t tested it with any other encoder. I don’t think it has anything specifically to do with the Lamprey encoder, though - I apologize if the wording of my message implied that. My hypotheses is that any analog encoder which can loop around from a high voltage to a low voltage would cause this.
After seeing the issue on the SparkMax, I subsequently wired the Lamprey encoder directly into the analog input on the roboRio and was able to read the values just fine, without any averaging going on. So I’m pretty sure this just amounts to the SparkMax averaging the values coming off of the encoder, which would be fine in many use cases but doesn’t work well in this one. And from what I can tell, there is no way to disable that via the SparkMax API.
Thanks for the quick response! You guys always have great customer service - keep up the nice work!
FYI…we recently sent some inventory to Amazon.
This is both an attempt to broaden our audience for these types of devices and offer fast and reliable shipping via Prime.
Please check out the Amazon product page.
If you used this sensor and feel compelled to offer a review it would be greatly appreciated.
Stay tuned for new Lamprey sensors and improvements for 2021!
Literally just made an entire AndyMark order just to get one of these… wish you had posted this an hour ago!
Do you still recommend disconnecting two pins (RX and TX) ?
Yes.
We’re planning to fix this issue in the next hardware revision…most likely be placing solder pad jumpers so you can selectively add or remove the extra outputs as needed.
Did a version without the secondary button ever come to fruition? Can the second button be removed without compromising the functionality provided that proper tools are used?
Yes and yes.
The flat back version is available from Amazon…
Also the Button on the Andymark version can de-soldered without effecting the board.
The button is used during the calibration of the sensor. For the version without the button (or if you de-solder the button yourself) how do you perform the calibration?
I’m not sure that if you de-soldered the button, that the part would still be considered an “unmodified” COTS part. If the manufacturer provided specific written instructions on how to do this in the product manual, it might be considered a configurable item rather than a modification.
We also noticed that the pins for the connector come through to the back side which means that if you mount it flush (without standoffs) to metal, that all the connector pins would be shorted to each other. Does the “flat back” version still have these pins sticking out the back side?
Sensors don’t need to be COTS.
The button is used during the calibration of the sensor. For the version without the button (or if you de-solder the button yourself) how do you perform the calibration?
There is a surface mount button on the board as well so you only need one to navigate the menus and enter settings.
For everyone’s info…the second button was added specifically to facilitate usage inside the AM Swerve module. They requested an additional interface because it was easier to reach when installed.
The flat back version does have a thru hole connector and those leads are exposed. So for now you have to relieve the area under the connector when mounting or otherwise avoid having it directly on metal.
We will solve this on the next version.