Motor runaway issue with SDC2130

Good morning,

I have an issue with a RoboteQ SDC2130 controller, which I suspect might be related to a bug in the firmware.

The controller is used in the arm of a DrRobot Jaguar Arm . It controls a DC motor with a relative (magnetic) encoder.

I'm attaching the full configuration profile (profile.xml), but the most important parameters are:

• Operation mode: closed loop count position
• Closed loop parameters: P=3, I=2, D=0
• Maximum speed: 1000; maximum acceleration and decceleration: 2000

The firmware is up to date (FID=Roboteq v1.4a SDC2XXX 11/21/2014) with no MicroBasic scripts running.

The issue is triggered by sending a series of !P commands (go to absolute position) to the controller via serial interface. The list of commands is attached in commands.txt (more details later).

This should cause the joint to move by some distance, and then move back. But in most cases, the joint move very far, very rapidly.

I recorded videos of the arm's behavior, they are available on YouTube:

• The expected behavior
• The actual behavior

The reaction of the motor depends on the timing of the commands (again, more details later). When I send the commands about 25% faster or 25% slower, the issue disappears (for this particular command sequence).

For analyzing the issue, I plotted the data sent to and received from the controller. The attached plots show:

• in blue, the destination position (the value set with the !P command)
• in green, the actual position (as reported by the ?C command)
• in red, the loop error (as reported by the ?E command)

I've taken the liberty of assuming that (loop error) = (setpoint) - (position), and therefore (setpoint) = (loop error) + (position). This value is shown in the plots in black.

The plot in no_problem.png shows the recording corresponding to the first video, where the movement is as expected. The setpoint is caculated to give a smooth trajectory, and the actual position follows the setpoint.


In problem.png, we can see the same data for the second video. At around 1.2 seconds, the setpoint starts decreasing very rapidly (at a speed greater than the configured maximum of 1000). The motor is unable to follow (despite 100% power, not shown in the plot, but reported by ?P), eventually triggering the loop error detection ("safety stop active", as reported by the ?FM command), which is configured as 500ms @ 25%.


The last image, problem_detail.png, shows an enlarged detail of the plot in problem.png. The full message log (sent and received messages) with timestamps is attached in YAML format (message_log.yaml).

This particular sequence of commands was crafted to reproduce the problem, but the issue has been triggered during regular operation, also on two other joints of the arm (where the consequences are more grave due to higher joint mass).

I don't know about the exact implementation of the control algorithms, but my guess is that the calculation of the setpoint trajectory (as described on page 99 of the manual) goes wrong. I initially suspected a problem with the power supply during motor reversal, but the "Undervoltage" flag (from ?FF) is never set.


Some more details on the command sequence: the sequence of destination positions was derived from the following list of destination positions by removing duplicate adjacent values:
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 31, 62, 93, 124, 155, 186, 217, 248, 248, 248, 147, 147, 208, 208, 208, 208, 208, 100, 100, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, -386, 0

Removing duplicate values seems to have no effect. When the above (full) list of positions is sent at either 15 Hz or 25 Hz, the behavior is as expected. Sending the list at 20 Hz triggers the error (in about 9 out of 10 attempts).

Another observation which may or may not be relevant is the following: if the controller is left alone after going into safety stop, after some time (varying between 45 and >100 seconds), the safety stop is released (?FM becomes 0), the motor turns back (in the opposite direction) very rapidly for 500 ms and then goes into safety stop again.

Also, I've been able to trigger the issue manually from Roborun+, by entering the commands "!PR 1 1000" and "!PR 1 -1000" on the "Console" page and rapidly clicking the corresponding send buttons alternatingly. That method ist not reliable, though, as the timing seems to be critical.


Your help is very much appreciated.


Regards,
Martin

It seems like the attachments were not transmitted properly, so I'll post the remaining files separately. Here is the command list.

The message log with timestamps in YAML format.

The controller configuration profile

The detail image

No, the watchdog is not the cause of the problem, it is already disabled (0). Also, sending a !P command every 50ms (at 20 Hz) does not improve the situation.

Furthermore, the output is not turned off (as would be expected if the watchdog was involved), but instead the motor is turned on at a very high speed, until the safety stop becomes active.

As for tuning, the PID parameters are already tuned and work fine. The problem occurs during regular operation. The loop error detection is not the problem, it only becomes active after the motor position starts running away.


Regards,
Martin

Please try the attached beta firmware and report.