When plugged into a Talon I would expect you’d use the analog output…all are 10-bit.
The design of the PWM frequency and timing was set to match traditional servo signals.
That said, we can change this to be more friendly to the WPILib…if you want to PM me the specifics we can update the firmware for future production batches.
Just got my order - look interesting and anxious to try them out.
Made a magnet mount for various round and hex shafts. You can find the code up at https://github.com/JolietCyborgs4241/robot-parts/tree/master/lamprey_encoder_magnet_mounts.
It’s an OpenSCAD file so you’ll need that to generate the 3d models from the code. The code handles round or hex bores and in general is pretty easy to tune (see the comments). It includes a .150 hole which can be cleaned up to a final .159 (21) for a 10-32 grub screw.
Here are a couple of captures from OpenSCAD - I also did a fast 3D print and they look pretty much as expected.
No particular application in mind for these mounts, just something to get things kicked off to learn more.
Feel free to use and if you make some interesting variants, share back.
– Chris Herzog - Joliet Cyborgs #4241
When using the sensor with a Talon SRX you must remove the Rx and Tx lines from your ribbon cable. For some reason the SRX will cause the Lamprey to reboot unpredictably when these lines are connected. We’re investigating the cause but for now this is the best fix.
This issue was not evident during product development. We’re sorry for the inconvenience.
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.
