help understanding failures related to DF Robot SER0062
James.Ma 2026-10-13 00:24:21 28 Views1 Replies Hi All
New user here looking for help and advice.
Please do not think there are any fingers being pointed here, really just want help and advice to best practices.
I have included the initial RCA but the only point I am interested within this forum is what is happening with the servo?
We have had a total of 4 servos where they drawing more current and blow fuses, but these last 2 are causing bigger system level issues.
We are running the motors off an UNO, should we slow them down? (we make our current motion shown in image in about 0.7s)
what can we do to improve reliability?
thank you in advance.
Description: The servo motor system of PP has been relatively stable since launch in July25. However, in the 3 months there have been 2 system level PP failures in the field. In both cases, Service is reporting that they find a computer failure in recovery mode which, after being replaced, later find the servo motor is not working.
SNs: 2580(Today->12Oct26), 2570 (28July2026)
Reported: BD on 12Oct26
Systems Effected: PP, XCP
CAPA Report: 12Oct26 by JM
Key Parts:
E31-018 Servo Motor -> DF Robot SER0062 45KG TORQUE BRUSHLESS WATERPROOF Servo Motor; digikey number: 1866-2014
E33-020 Rev 1.2 Main PCB
RCA hypothesis:
We cant RCA the computers, they were replaced.
Most likely what has occurred is the following: The servo Load increases -> Increases Servo Current -> Voltage surges -> Surges breaks USB isolation with the PC
Why the servo load increases is unknown, it maybe mechanical binding within the servo or an electrical failure within. The previous work section shows it is something within the servo.
The servo can run off substantial power (7A), it should not fail, but it may induce a failure elsewhere/
Failure testing of the original design, by stopping the motor abruptly, was performed for the initial DR and this never induced a failure and always blew fuses.
Previous Work: For the failure of 2580, the camera centering mechanism came back to HQ in Sept26 allowing it to be examined . The analysis showed entire camera centering arm required about 5-10x more force to move than (shown in images below, orange arrow) compared to a new system. When the mechanical linkage of this system was disconnected from the IGUS track, the segment with the servo motor was the part that was hard to move. Thus, the motor was taken apart but the exact failure was hard to determine as the gears were removed which caused the force to move the motor to drop.
Plan of Attack -
--The new E33-020 Rev 1.3 (Rev 1.2 Current) has 2 new TVS (transient voltage suppressor) over the lines supplying the servo, old version has diode protection.
--Slow the Servo down so it does not fail (if relevant).
--Get general recommendations on DFRobot servo use and speed (perhaps from user forum)
--Add USB optoisolator on USB between the computer and Microcontroller (first check with Vendor to get recommendations)
![]() | ![]() |
hi,
Your RCA lines up with what I know about this servo. The SER0062 is rated for 6.0-8.4 V with PWM control (500-2500 µs) - a brushless 45 kg unit, so it can pull serious current under stall. If the centering arm takes 5-10x the force to move, the servo is basically stalling against the mechanism, and stall current is exactly what pops fuses and slams the supply rail. The USB isolation dying afterwards is the classic downstream symptom of a rail surge.
On slowing it down: yes, ramp the PWM speed (soft-start, e.g. step the pulse width over ~200-300 ms instead of slamming to target) - that cuts the mechanical shock and the current spike on each move. But treat it as mitigation. The root issue is the mechanism binding - fix that and the current problem mostly goes away.
Other things that genuinely help in your situation:
Power the servo from its own supply/battery, never off the same rail as the microcontroller; add bulk capacitance (e.g. 470-1000 µF low-ESR) right at the servo connectorThe new Rev 1.3 TVS diodes over the servo lines are the right idea - keep themA USB opto-isolator between the PC and the controller is exactly what you planned; that's the correct fix for the PC failuresWatch stall: if a move doesn't complete in the expected window, command stop instead of holding full torque
Jason.Miao 


