DevilBotz 2876 has been using the XRP robots for our 2nd Annual MiniFRC competition. Students have noticed differences in behavior between the Servo 1 and Servo 2 ports.
We have tried both XRP WPILib FW v1.0.1 and FW v1.1.0 and they both have the same behavior.
We aren’t even simulating/running any code on the XRP, so this is just after initial boot up.
We are testing using both 180 servos and continuous (360) FS90R servos. Servo 1 port seems to work as expected for both. However, Servo 2 does not behave the same way. E.g. at bootup, when both ports are set to angle=90/position=0.5 (i.e. 1500us duty cycle), the same motor behaves differently. I used a cheap digital scope and confirmed the duty cycle is 1500us for both PWM signals, so am at a loss on how to debug further. Perhaps there’s a signal noise issue?
Hmm is the measured output at both servo pins reading 1500 when commanded to 90 degrees? There isn’t anything too special going on with the firmware for either servo (they both use a PIO program for timing)
Yes, we are stumped. The Servo 1/2 pins are set to 90’ (1500 us) at boot. I’m not even running a simulation, so the default behavior is different between the two sets of servos. However, when I probe the signals, the PWM waveforms both have the same period (20 ms) and same duty cycle (1500 us). I’ll try to capture the waveforms for you both to look at.
The 180 servo that is included with the XRP
kit also behaves differently, if you want to try it out.
The only thing I have configured differently is we are using “STA” mode to connect to a a local access point. I’ll try changing it back to defaults to see if that makes any difference.
Yeah the default state for the servos (when disabled) is to be set to 1500 us (which should shut off most bidirectional ESCs of those are used).
Also worth running a robot program that sets both servos to the same angle and verifying with the scope that the PWM signal is the same. If they read the same, then there might be some other variable at play
We already tested with robot code using the same angle/code for both servos which is why we tested with the default state w/o robot code to mainly rule out any bugs/issues with the robot code itself.
We thought the 360 servos were defective, but then another mentor confirmed they work fine when driven using an Arduino. That’s when we dug deeper and realized Servo 1 and Servo 2 ports behaved differently. Our initial code was developed and tested using only Servo 1, which is why we didn’t see this issue in our initial development.
I see the same behavior. Servo 1 is stationary, Servo 2 spins fast. If I set it to 45 each, Servo 1 spins in one direction, Servo 2 spins in the other direction.
Very strange. I definitely don’t know why this would be happening, and I’m unable to replicate, but some things to try/do:
Does a different servo of the same model exhibit the same behavior?
Does a different servo of a different model exhibit the same behavior?
Does a different control board exhibit the same behavior?
Since you have an oscilloscope, could you please send waveforms of the following:
Servo 1 IO pin
Servo 2 IO pin
Servo 1 5V pin (AC coupling)
Servo 2 5V pin (AC coupling)
If you have a multimeter, please measure the voltage on both 5V pins (ideally with millivolt resolution).
I don’t have any continuous rotation servos on hand, but the handful of standard servos on my desk (including the one that comes with the kit) all behaved the same on ports 1 and 2. Both of my 5V pins measure 5.203V and 5.202V, and the 5V waveform looks like this on my end:
This subject caught my attention and inspired me to do some investigation. With some very basic code that sets both server 1 and server 2 to (90), My oscilloscope shows a pulse width of 1400 microseconds on both servo headers. As would be expected, the standard servo would go to a position close to 90 but not exactly 90. With the same value a continuous rotation servo (360 deg) rotate slowly in one direction.
To attain a pulse width of exactly 1500 microseconds I had to command the servos to go to 100 degrees (100). Using the same script with both servos receiving a command to go to (100) it produced a 1500 microsecond pulse from each output. This caused the standard servo to move to the 90 degree position and the continuous rotation servo to stop spinning.
These results are exactly what I would expect for standard and continuous rotation servos, with the exception of needing to command (100) “degrees” to get a fifteen hundred microsecond pulse.
Good catch, I also see 90 degrees resulting in a 1400us pulse. Looks like XRPLib actually uses 0-200 degrees:
This is likely not relevant to the original problem in this thread, but @Fgrossman and @bamiller I think it would be good for XRPLib to use 0-180 degrees for servos with 90 degrees corresponding to 1500us pulse width, because that’s what people expect. Or better yet, allow the user to optionally specify min/max pulse widths and corresponding min/max angles, because many servos have different angle ranges and acceptable pulse widths.
The issue happened on multiple servos of the same model (Feetech FS90R). The servos all worked fine on a different Arduino board.
I have a few different model servos on order (Feetech FT90R and SG92R). I should receive them by Sunday.
We have multiple XRP boards exhibiting the same issue.
I’m out of town at the moment, so will get you the waveforms on Sunday. I have an Espotek Labrador open source USB based “oscilliscope”, so hopefully that is good enough.
Ditto.
We see the different behavior using 180 servos, too.
I received the Feetech FT90R servo today. The FT90R is the digital version of the FS90R. Interestingly enough, the FT90R behaves correctly on both Servo Ports! For this test, I used blockly to set the servos to 100 degrees (1500us). The FT90R was stationary on both ports. However, the FS90R was stationary only on Port 1 and ran fairly fast on Port 2 (same as the video from my original post). Do you think there’s enough noise on the Servo 2 PWM signal that is causing the FS90R (analog) to act weird?
4/5) I used a multimeter and measured 4.96V on both servo 5V pins.
I’ve attached the waveforms for servo 1 and 2. Note, the PWM was set to 90 degrees using XRP Micro-Python, so @AkaMrBill indicated, the expected duty cycle is ~1400us.
I was using 2800 mAh Rechargeable batteries (~1.28 V each). I swapped in Alkaline batteries (~1.49 V each), and the Servo 1 and 2 5V power read 5.21 and 5.22 V respectively. However, the behavior is still the same:
The FS90R servo still behaves differently between Servo 1 and Servo 2 ports.
The 180 servo that comes with the kit does not respond at all on Servo 2
I connected the 180 servo to Servo Port 1 and set the angle to 0 and 200, and the servo moved as expected.
I ran the same test using Servo Port 2, but the 180 servo didn’t move at all.
The FT90R (digital) servo seems to work fine on both ports
It would be great if others in the community try the same 0/200 degree test using the included servo on both ports 1 and 2 to see if they can reproduce my findings.
@SparkFro, I can send you my XRP and Servos if you’d like to dig in further.
Another data point, I received the SG92R360 servo today, which appears to also be “digital” and it also works as expected on both ports. So, seems like our XRPs are having problems with the “analog” servo variants on Servo Port 2.
That is fascinating. The only thing I can think is that the Servo 2 port is closer to the 5V buck regulator, so maybe it’s just enough to cause some servos to perceive that as a signal? If you have some capacitors around, could you try adding a 100uF capacitor to the 5V rail to see if that makes the servos behave properly?
Another thing I’d be curious to try is connecting your servos to various combinations of pins between the servo connectors with jumper wires. For example, connect to the 5V and GND pin of Servo1, and the signal pin of Servo2; then vice versa. Or the GND and signal pin of Servo1, and the 5V pin of Servo2; then vice versa.
This one really has me stumped. Would definitely like to understand the root problem here, so if the ideas here don’t gives any answers, would love if you could send me a board and servo so I can try to find the root problem.
Very interesting. Maybe the buck regulator noise is somehow coupling into the Servo2 PWM signal? Last idea is to add a small capacitor (like 0.1uF) to the signal pin to try filtering it.
Yes, would be happy to have your board and servo to debug. We can pay for the shipping, but you’ll need to fill our return form first. Please link to this thread so the folks handling the return form know that I sent you.
