Hi!
Had a strange effect.
Everthing working normal, did a hard restart of ROV power.
At power on the gripper opened maximum and did not stop for a long time.
When system had booted everything worked, but the gripper was dead.
Did more restarts without effect.
Started to check in QGC/vehicle setup
Here were no longer any frame in summary tab
In Joystick tab, button assignment for gripper (servo3) now was “unknown:85”
Also error messages of missing parameters.
After more restarts of QGC suddenly the usual “servo3” is back, (but not at all restarts.)
Now frame can be visible in QGC, but at the same time “unknown:85” instead of “servo3”
It seams that the odd stange restart have burnt the gripper, but also made some software problems.
Opened gripper, have 12V, but the LED marked “green” is not lit.
Need help to find out if the gripper is burned, any way to force movement softwarewise?
And why the software Ardusub/QGC issues is happening.
Ardusub 4.0.3, QGC 4.1.4 and 4,1,2
Bo
So, follow up:
Motors coils burned
Control ESC in Gripper burned
QGC can not be started before ROV/Pixhawk, doing that
results in no servo3 availible, and sometimes no Ardusub frame found at all.
Restarting QGC with ROV running fixes the problem.
QGC 4.1.2 and 4.1.4 same thing
So, is the cause for gripper burning this software problem, or is there two issues?
Ie hardware giving up, and software bug at the same time?
Another finding in the gripper is that the planet gear bolts to the motor was lose and no thread glue.
Not lose enough for generating this burning.
Gripper is an R1 version.
Bo
I brought this up internally a couple of days ago but haven’t yet had a response.
I’m not sure why this would have happened, but it’s clearly not intended behaviour.
In our BTNn_FUNCTIONS, 85 corresponds to servo_3_max_momentary, so clearly ArduSub had the correct parameter value stored, but it’s unclear why QGC wasn’t able to read/get the parameter metadata properly.
Sorry to hear that. I’d recommend you contact support@bluerobotics.com to tell them what happened, and link them to this thread. If a replacement/refund is appropriate they’re the people to talk to
I’m aware that R2 included some hardware and software improvements that increase reliability/robustness (which is mentioned in the Revision History on the gripper product page), so regardless of the cause this kind of issue should at least be less likely to occur in future.
I was able to replicate this for QGC 4.1.4, but not 4.0.5, so it does seem to be a new 4.1 issue. I’ve filed a bug report here:
It seems like two (seemingly unrelated) issues. While I was able to replicate the weird QGC behaviour (missing the parameter metadata), I didn’t have any unexpected behaviour with the servo_3 output - when the vehicle turns on the output of AUX 3 is 0, and when/while the assigned button is pressed it goes to 1900, then stays at 1500 when the button is released.
