Hi,
recently our team has encountered a problem- Lamprey Absolute Encoder having random resets during rougher drives and after a few minutes of driving. We know it’s not a problem with the cables or our breakout board\roborio\any of the encoders since all have been replaced at least three times since encountering this problem.
We are using roborio 2 and connect the encoder to an analog in port(5.5v)
The second time we replaced the encoders it worked for about 2 hours and then it happend again and we were back at square one.
If anyone has encountered this problem before and\or has any idea how to help we’d love to hear your opinion
Yes, We have 2 that only have a orange light. This past weekend we were hit with random loss of calibration and other odd behavior. We will be going to other encoders in the future.
We used a Lamprey encoder for the first time this season because it fit well in our application. We’ve had terrible problems with it. Sometimes when we turn the robot on, we find that calibration is lost. There is no blue light, just the orange one. This doesn’t happen often, but having it happen at all is unacceptable. We’ve cut pins 5 and 7 and have now cut pin 1. We are using it plugged in to a Spark Max data port. Luckily, we are just using it to initialize a relative encoder, and for our first competition we are going to initialize by manual positioning in the pit since we haven’t been able to get either of two Lamprey encoders to be reliable enough to stake a match on.
I wish I had some advice about how to solve the mentioned problems, but I don’t have any. I’m just adding another data point to commiserate.
Let me give you all the details I can about our setup:
From a physical standpoint, the encoder is mounted such that the face with the chips is about 1/8" from the top of the magnet. The encoder is mounted to an aluminum plate, which is on the side opposite the magnet. I’ve put a nylon washer on the bolts between the encoder and the plate to keep it spaced off of the plate (so that the little pins that stick out of the back of the encoder don’t get crushed into the plate).
From an electrical standpoint, the encoder has a short 10-pin IDC cable (~4") plugged into this breakout board: Gadgeteer Breakout Module (5 Pack) - CTR Electronics . From there, I’ve soldered wires onto the 5V, ground, and analog output lines. Those are plugged into the analog input channels on a RoboRio JST connector board: JST Connector Boards – Swyft Robotics Shop . Of note, I have NOT cut the RX and TX lines on the IDC cable, but I would think that what I’ve done with the breakout board isolates those lines in the same way that cutting them would. I certainly can cut them if you think it would help.
From what I’ve observed: I have 4 of these encoders on the robot, and I’ve observed the following behavior on at least three of them. Perhaps all 4, but I can specifically remember seeing it on three of them in the last day or two. On each one, I’ve gone through the basic calibration procedure and gotten the green light. After pressing the button, the light turns blue and all seems to work fine for a while. At some point in the future, I’ll observe that the lights on the encoder are orange, which I believe suggests that it has been reset to a un-calibrated state. I can definitely reproduce it by powering off and then powering in the robot several times. I don’t know if the powering on and off is the only time that it happens, though.
I appreciate the generous offer to replace any defective sensors, but it strikes me as unlikely that the devices themselves are defective - there would have to have been at least 3 defective devices on my robot. I’m guessing it has something more to do with my particular setup (and the setup of the other people in this thread).
Does any of that help to understand what might be the problem? Would it help if I tried to get some debugging information off of the UART ports? I’m not entirely sure how to do that, but perhaps it can be hooked up to the RS232 port on the roboRio and I can access it via the SerialPort class? If so, I think I would need to know the baud rate of the device. Do you know what that is?
All interesting data. I’m certain the sensors aren’t “defective” but there is clearly something that is able to reset the micro on the sensor…an errant shock maybe or something I didn’t test for.
There is no state where the device would only have an orange light. if it’s rebooting then you’d likely see at least the orange and red light waiting for the basic cal.
the easiest way to use UART is to buy an FTDI to USB device and just look at the data in a serial monitor like Arduino or putty.
You still have to make a cable or other mod to get to the pins though…FYI the new generation has native USB so this is much easier.
This all sounds like “emc” of some sort. The button signal may be getting pulled high or low or it’s sitting very near the threshold and tricking the board into a reset.
As you may recall, our team was having similar issues in 2020. You worked with us to try to isolate the issue, but we did not get very far before we had to suspend the troubleshooting to get ready for our event and then shortly thereafter COVID shut us down.
We don’t have any new info to provide, but maybe the info we shared with you back then would be useful in helping to diagnose this issue.
Once again, thank you for all your help back in 2020. I hope that you are able to get to the bottom of this as we would love to be able to use these encoders in the future. The form factor is perfect for our swerve modules.
Edit - you mentioned that this might be “emc” affecting the electronics. On our 2020 swerve modules, we had a NEO motor with a single stage VP gearbox sitting directly above the board (co-axial with the centerline of the magnet/board) and a NEO 550 sitting directly next to the board (within an inch of the edge of the sensor board). Could the magnets / fields of these two motors contribute to an EMC issue? We also had a lot of other potentially “noisy” devices in relatively close proximity including a pneumatic compressor that was within 12 inches of at least one of the sensors.
@ajlapp, I just checked on one that had be reset that I haven’t recalibrated, and you are correct, it is an orange and red light.
I happen to have that almost that exact SparkFun board sitting in my workshop (I have this older model: FTDI Basic Breakout - 5V - DEV-09115 - SparkFun Electronics ). Do you have any tips on how to wire this up with the encoder, and what I should be looking for on Putty that might be useful in diagnosing the problem?
Just wanted to chime in the we are also having this issue, primarily with only 1 of 4 lampreys. It seems to lose its calibration occasionally on powerup (red+orange) and our field setup folks have learned to calibrate it quickly. I would like to resolve this, but it is so random.
I did have a ground-fault on this corner and replaced the Talon, but maybe it already damaged the lamprey on that corner? I could replace the lamprey again to see if the issue goes away now that the ground fault is resolved.
I’m less a mentor on their team and more someone they occasionally bounce troubleshooting ideas off of, so I don’t know the full details, but 1640 is confident that they’re not getting hit by a defect. On their practice bot, the rear left pivot specifically would lose calibration after some time. The only consistency was the location; swapping out the module for spares (which meant a different Lamprey encoder too) exhibited the same issue after a while.
When I suggested that it was almost certainly something electrical or magnetic going on, they pointed out that specific module was very near their 4-NEO climbing gearbox. They tried covering their gearbox in foil, and it seemed to work, but this was just a day or two before competition; not enough time to say it made a difference with any confidence.
It’s unclear to me if the issue presented itself on their competition bot at the Hatboro-Horsham event last weekend (I wasn’t there, but I was in communication with one of their students); I was actually under the impression it didn’t, but Gdeaver’s post says otherwise, and they weren’t looking at replacing the sensor altogether last week. I reached out to a few team members for further details.
Response received. It’s unfortunately still unclear.
They are sure the zero point became off several times, which is a separate yet still troubling issue. However, due to the frenzied nature of competition repairs, the student I talked to can’t remember if the sensors ever lost their calibrations as described in this thread (and on their practice bot) or not. He didn’t remember the issue in this thread ever happening at competition, but also realized that they did indeed redo the full calibration process several times, and can’t quite remember why. That doesn’t make sense if they just needed to re-zero them; it’s possible it was a step they took after a sensor lost its zero point twice, but unfortunately the student is unsure. He says it’s possible they did experience the issue and he forgot.
The issues they know they had at competition were not limited to a specific corner, like they were on the practice robot. As they’re changing encoder solutions for their second competition next week, they won’t have much more data to provide.
@ajlapp: It seems that there is a possibility that electrical noise is trigger the reset line. I tested it statically and it seemed to be pulled high, but do you think that adding another pull-up resistor would improve this? If so, what value would you suggest?
One other theory which I will test tomorrow: perhaps the voltage on the analog inputs on the roboRio is not stable enough during the boot up that Lamprey sees a low current and interprets it as if the button is pressed? I will try powering them via the VRM tomorrow to see if that solves it.
This morning I tried to power the encoders from the 5V, 0.5A port on the CTRE VRM. So far, so good! I’ve power-cycled at least 20 times and I haven’t seen any of the encoders reset themselves. I’ll keep my fingers crossed, and post here if I do see anything get reset.
For anyone else experiencing this problem, you might want to try this.
I’m pleased to say that we haven’t had a single encoder reset over the past few days, which must have covered dozens of reboots. So I think we’ve solved it (although I’m keeping my eyes on it and my fingers crossed).
@JimB1918 , I would be surprised if you needed to do the same thing for encoders powered by Talons, as presumably you’re getting a clean power supply there. And many people have used this setup successfully. One thing to double-check is that you’ve cut the RX and TX lines, as is discussed here: Hollow Bore Absolute Encoder by 221 Robotic Systems - #132 by ajlapp . If that doesn’t work for you, you can try incorporating my solution. The way you’d have to do this is to cut the power line from the 10-wire IDC cable (pin 2) and solder a wire extension onto that. Then plug that wire extension into any of the 5V ports on the CTRE VRM. Cutting those little IDC cables can be a tricky proposition, but I’ve found that if you kind of roll them around in your fingers a bit, you can separate the individual wires from each other, making it easier to cut what you want without accidentally snipping something else.
Confirmed that we have removed the Rx and Tx already, as they were unusable at all on the Talons without doing that, but I also presumed we would be getting stable 5V from the Talons, but we still have Lamprey’s that lose their calibration from time to time. We do think that the one that we have issues with is quite close to the compressor (3-5 inches away) and are going to put a faraday shield between (aluminum foil) to see if it clears up.