Just wondering if you have had a chance to review the log file and have any suggestions on what could be causing these issues?
Thanks
Hi @Ben1,
I’m sorry for the delay. Your sensor or sensor wiring seem to be the issue.
This is how the altitude looks from a healthy sensor:
And this is what yours currently looks like:
That is why I asked if you have anything not stock. That could be generating noise in the i2c line.
I’d check the connections to the bar30 and if there is any potential noise source close to the wires.
If you have an i2c splitter in the ROV, I’d test without it, as longer wires are bad for i2c comms.
I’ll double check the wiring today for the BAR30.
Our Blue ROV2 is stock from BR and the software has been updated only with the stable release. We have added the Newton gripper and Ping360 sonar following the BR guides.
With that, what components within the electronics tube could potentially generate the noise seen in the i2c line?
Thanks
I’d be more concerned about the power module. The ESCs wires to the motors could be an issue too.
Also double check the connectors and the potting in the bar30 for bad connections and (partially) broken wires
We are experiencing a similar issue when in depth hold on a BL300 ROV. This seems to be the best place to put this question but please relocate if appropriate. Consistently either the Forward Vertical thrusters or Starboard Vertical thrusters will cease spinning at all and the vehicle will begin to slowly pitch or roll as the other thrusters try to correct. No problems when in manual control. All software updated, thruster direction checked. Any suggestions greatly appreciated.
Hi,
We’re experiencing a listing issue in stabilize flight mode also. When we change from manual to stabilize, it seems to work perfectly, i.e. locks onto the virtual horizon, but over time, maybe 2 mins, the list (and I believe trim) gradually keeps growing, up to 30degrees.
We often get errors such as EKF{X}IMU{Y} forced reset, EKF Lane Switch, and EKF3IMU0 stopped aiding and EKF3IMU1 stopped aiding.
Have recalibrated all sensors multiple times. Now I’m assuming it may be a wire somewhere, or the pixhawk.
What logs should I check, and what channels should I compare to diagnose the problem?
For info, we have a a RPi3b with BlueOS 1.1.0 beta 28 and a Pixhawk with 4.1.1, a ping 360, and a DVLA50.
Regards,
Kieron
Hi @XYZEng
Make sure you are running ArduSub 4.1.1beta7.
if the issue persists there, check in the binary logs if ATT.DesRoll and ATT.DesPitch are not zeroed in stabilize/depth hold modes
2 Likes
if used in Stabilize MODE or Depth Hold MODE for 5-10 minutes, it will roll or pitch.
When set to Manual MODE, it will return to horizontal position.
We tried BlueOS1.1.1,ArduSUB4.1.1,QGC4.2.8
but it was the same.
We have tried with various different versions on 6 different BlueROV2 and it was the same.
Please let me know how to solve this problem.
Can you provide a log where this happens with ArduSub 4.1.1 beta7?
I can’t reproduce the issue.
@williangalvani
I sent it as a message because I’m not sure what’s in the log files.
Please do not share anything from the log file except for the bug section.
Hi @Itaru ,
From your logs I can see the bug itself is not there. The bug meant that the roll and pitch targets were drifting, which I don’t see in your logs.
I do see that the ROV is shaking, though.
Is your ROV in open water? you could probably play with the roll (ATC_RLL) and pitch (ATC_PIT) gains to improve attitude handling there.
for starters, I recommend setting the D terms to 0.0036 and P terms to 6.0. as you increase the D term, you might want to lower FLTD as well. FLTD is the “frequency cut” for the D term.
Thank you @williangalvani
I have never changed those settings before.
Should I set them as follows?
ATC_ANG_PIT_P: 6.0
ATC_ANG_RLL_P: 6.0
ATC_RAT_PIT_D: 0.0036
ATC_RAT_RLL_D: 0.0036
I plan to test them tomorrow.
Yes that is correct. Please let me know how it goes.
We have been using many units of BlueROV2 for several years now for extended periods of time.
They have been stable and working as we purchased them, but in the past few months they have suddenly become unstable.
All of our BlueROV2 are unstable, not just the new ones.
Why is this?
The only thing I can think of is that I have increased the version of BlueOS and changed the batteries from black to white.
We are quite annoyed as we use ours daily to work in the open sea.
Is there some sort of flowchart for when it becomes unstable?
Hi @williangalvani
We changed the settings and it stabilized a bit, but did not keep level as before.
When I purchased a new navigator and used it as is, it kept the horizontal level and worked.
After that, when I upgraded the navigator to version 4.1.1Beta7, it also became unstable.
What is the most stable version of the Navigator firmware?
A 4.1.1 stable firmware is now out. please give it a try. 4.1.1 stable and the latest beta both fix the issue where the attitude targets drifted after yawing.
For example, this is your log with 4.1.0:
and this is a log with the latest beta:
DesRoll and DesPitch only change when you disarm or trim manually.
Let me know how the new firmware works for you.
I have compared the oldest and newest things in the log file I sent you.
Both are the same operation that will dive to 100m.
■old
■new
The newer control appears to have a higher load on the thruster.
How can I check the firmware version from the log file?
I doo see the issue in your latest log, 00000025.BIN.
but I can also see that the P and D gains are not the ones I recommended.
This is what I see in your log:
And they should be this:
I don’t have the logs for the BlueROV2 that changed the configuration values.
That BlueROV2 is in a remote location and has not returned yet.
Sorry.
I just heard that the shaking is a little better but more unstable than it was a few months ago.
We use BlueROV2 for work, so we don’t have time to test it over and over.
We are now dealing with returning to the stock pixhawk or purchasing a navigator.
We have had several units tested in various configurations and we don’t have control over the log files.
So I would like to check the most stable logs to see what version of navigator we have.