Vibration of the BlueRov2

[mateov]

Hi all,

I didn’t manage to find a topic similar to this one, which caught me by a little surprise.

So, we have a problem with vibrations on our BR2. We’ve had our BR2 in heavy configuration for over a year now. It is most often equipped with additional Ping1D and Ping360, elevated with payload skid, and 3 equally separated additional cameras set up on a carbon pole mounted to the front of ROV.

Vibrations that we’ve tracked now seem to be happening for over a year now, in bigger or smaller measure, right about when we upgraded to heavy configuration. We weren’t detecting them before as a problem since camera stabilization (we mainly use GoPros) compensated them, and since vibrations are big enough to be seen on camera during bigger vertical movements, and that is the part of the video that we usually discard/do not use.

So, vibrations are stronger while moving vertically (up/down), and really weak (not noticeable) while moving or rotating in other directions. Also important, vibrations occur during stabilize mode, which we use during our underwater inspections (vibrations do not occur during operating in manual mode). With that said, the cause of vibrations are most likely four of the vertical thrusters.

Also, vibrations got much more visible when we upgraded our underwater GoPro housings to aluminium ones, which are really heavier, so them sticking out on a carbon pole really intensified the vibrations.

Short example of video for GoPro while there are vibrations is here as an example, taken from the left camera:

BR2 - vibration 1

Our BR2 in this setup looks like this:

To counter the argument that vibrations are caused by cameras on relatively long lever, vibrations are also happening while ROV is without cameras, in water, in stabilize mode (not currently able to video this because ROV is in a different setup now, while testing). With that said, I consider vibration of the camera in this stage as the issue, but not the cause.

The main thing we saw during this whole testing period (which is longer that supposed because of some leaks we’ve been having) is that the “upper” part of ROV (4" tube with 2 aluminium cradle screwed to the ROV side panel via HDPE center panels) does move differently in regards to lower part (3" tube on HDPE bottom panel).
Specificaly, if you apply force to the side of ROV, try to shake it, on our ROV there is a distinct difference in regards of movement that 3" and 4" tube are doing. Since 3" tube is on a solid piece of HDPE, it is shaking considerably less than 4" tube that is on a less sturdy mounting system (2 brackets and 4 HDPE center panels).

I am wondering, did anyone notice this? How did you solve or at least mitigate it?

We are currently experimenting with removing the skid and stiffening upper part of ROV frame with 3D printed pieces and threaded rods, which do seem to help, but still with some work on it.

Thanks all,

Mateo
Vectrino team

[maphstra (Mads)]

What version of Ardusub are you using?

[mateov]

ArduSub: 4.0.1
Companion: 0.0.21

You think it has to do something with specific versions? Pixhawk issue?

Also, multiple updates have been made (both Ardusub and companion) within this period of using heavy, and from the top of my head I think this issue was there with all of them.

[maphstra (Mads)]

We have had similar issues with Ardusub 4.01 which were completely resolved by downgrading to 3.5.4. So that would be my first step to check.

It might be that this also is fixed in Ardusub 4.02, I dunno.

[Boko (Bo Koppel)]

Two things I would check:
-Is something lose or why do it seem that, that you are already checking.

-Next is to check inside thrusters for dirt or rust on collector/magnets if you have not done that already

[williangalvani]

I believe your gains may be too high.

Do you mind setting LOG_BITSMASK flag for PID next dive and share the dataflash log here?

This way we can see if the vibrations are being caused by the PID controller. We may need new, lower defaults for Sub 4.0.

If you want to check this out yourself, there will be a message called PIDR in the dataflash log. This contains all the invidual components of the PID controller (proportional, integral, derivative, feed forward and some more) for analysis.

[wholm (Walt Holm)]

Interesting and timely thread.

I’ve got a vehicle right now that’s doing something similar- there appears to be some lateral shimmy when climbing/diving. The vehicle is running Ardusub 4.0.1, but I’m not sure that’s relevant- I seem to recall that the problem is visible when in manual mode as well as the stabilized modes.

Since the last dive, I’ve tightened up all the screws in the frame, and did a bathtub test of the vehicle with the vertical thrusters mechanically disconnected from the frame. I could then run these thrusters while holding them in my hand, to check for an out-of-balance condition in the motors. Both seemed to be fine.

I’m headed out this weekend to do more testing. I’m going to see whether tightening the frame screws changed anything, and will verify if the problem exists in manual mode.

A couple of questions for @williangalvani:

1.) Would incorrect PID values have any effect on flying in manual mode? Can you think of any changes in Ardusub 4.0 that would have changed the behavior in manual mode?

2.) If the problem still exists, I might revert Ardusub to 3.5.4 to try to bisect the issue. Can that be done in the browser interface on the companion computer, or can you point me to a procedure for this? Thanks.

Walt Holm

[williangalvani]

@wholm

1.) Would incorrect PID values have any effect on flying in manual mode? Can you think of any changes in Ardusub 4.0 that would have changed the behavior in manual mode?

No, there is no PID involved in Manual mode.

@wholm

2.) If the problem still exists, I might revert Ardusub to 3.5.4 to try to bisect the issue. Can that be done in the browser interface on the companion computer, or can you point me to a procedure for this? Thanks.

You can find all versions in the firmware.ardupilot.org repo.
Ardusub 3.5.4 is available here (use the -v2 file).

[mateov]

@maphstra - thanks for the input, will keep that in mind.

@Boko - nothing is loose, multiple checks during this forementioned period, also, everything is always secured with loctite

• honestly haven’t checked all thrusters like that (some are replaced and some dismantled throughout this period), but I do not hear nor feel anything suspicious that would point me in that direction, also not having the said problems in manual mode doesn’t point in that direction. With all that in mind, I may still check it out, thanks for the input

@williangalvani - we use ROV almost always on 25% gain, if that is important.
I can check the parameters and try that tommorow in our small pool and share the log. Will have bigger log during next week if weather allows it.
I’ll sure post everything I can regarding this issue.

Also, ROV is now in configuration without payload skid and with upper part strengthened with threaded rods, but still, you will be able to see the specified values…

Question to you, have this values been changed from 3.5.4 to 4.0 versions? I repeat, this issue was found on both versions of ArduSub, only in stabilize while moving verticaly.

@wholm - as stated, in our case, problem is not visible in manual mode. I also tried to hold motors while ROV was in our pool, while forcing the vibrations, but I couldn’t specify that any particular motor was problematic. Also, you are not running heavy lift config? Interesting…

[mateov]

One additional remark, I have a specific situation which can be tied to this discussion.

When I try to test a single thruster, I do it in QGC by going to the Motors section. There, I have a relatively big lag/response time from the thruster. When I slide the slider up/down, the thruster reacts to it with a delay of approx. 3-10 seconds.

Also on one occasion, it wouldn’t stop for more than 10 seconds so I had to pull out the battery.
Could this be related?

I was attributing this just to QGC and some issue it has while controlling single thruster, but maybe…

[williangalvani]

@mateov

Question to you, have this values been changed from 3.5.4 to 4.0 versions?

They should be equivalent. But there were so many changes from 3.5.4 to 4.0 (NuttX to ChibiOS changes, structural changes to the controllers…) that they will likely work not the same.

@mateov

I repeat, this issue was found on both versions of ArduSub, only in stabilize while moving verticaly.

If you only experienced it in stabilize mode, that is very likely related to the PID gains.

@mateov

When I try to test a single thruster, I do it in QGC by going to the Motors section. There, I have a relatively big lag/response time from the thruster. When I slide the slider up/down, the thruster reacts to it with a delay of approx. 3-10 seconds.

Also on one occasion, it wouldn’t stop for more than 10 seconds so I had to pull out the battery.
Could this be related?

What is the streamrate you see in the /mavproxy page of companion? Make sure it is not higher than 10. This is very likely due to high cpu usage of mavproxy.

[mateov]

Thank you for information about Ardusub.

I couldn’t get the log file today, I’ve had lots of small hickups and I will upload you file with PID data as soon as possible.

Will check the streamrate value and test and also get that information.

[BoatSD (Joe)]

I developed this same problem after running in eel grass. Cleaned the thrusters and everything is fine. One of my verticals was wrapped up pretty good but hard tell from running dry and not visible from just looking at it.

[mateov]

@williangalvani

First of all, I’ve managed to get the .bin files directly from pixhawk memory card, I am attaching you the last one, together with PIDR data log in .csv format (extracted from the same log):

00000196.BIN (4.7 MB) log196_pidr_only.csv (769.3 KB)

In MAVExplorer, graph looks like this:

So, the attached log files are from the test in our pool - height about 0.8 m and diameter of 1.30 m, and vibrations were present during the test. BlueROV was in setup with 360 ping on top, 1D ping near 3" tube and no bottom skid.

Also noticed was that ROV somehow couldn’t “settle”… It was always compensating the rolling and behaved in a sort of rocking movement, never really balanced out and standing more or less still/balanced. This could be due to the relatively small pool that it was submerged in, but still wanted to mention that to you.

Does this info tell you anything? Do I need to provide you more info?

Thank you very much for your help.

Also, I should mention that there is some yet unidentified problem to why pixhawk doesn’t write the time correctly (date unknown is shown in QGC) so the time start is set to 01-01-1970. That should not be an issue in this particular case, but if you have any info about that, please be so kind to let me know.
Last log that has time and date is from Jun 2020, and some time after that update of companion to v0.0.21 was released. Could that be the cause? I installed it manually (no option to update via web interface, problem many users had).

@BoatSD I assume that problem would be visible in manual mode also, so thank you for your input, I will have that as an option to look, but for now I’m placing my bets on something software related (or some design issue in frame design, which we are currently trying to stiffen up).

EDIT:

I am adding pictures of my PID parameters, because I can not find default values to compare with mine. You can compare to their values, and maybe we can find out if this really is PID related and how to solve it.

Also I want to add two extra informations that may be of use:

• vibrations do not come up immidiately, but after few seconds of vertical movement
• ROV sometimes responds really wierd when switched from manual to stabilize, like it overcompensates roll with one side trying to balance itself, and then it stabilizes after few bounces

[williangalvani]

Hi @mateov,

From your logs, I believe the issue is caused by the ATC_RAT_RLL_D term. Try zeroing that and check how the ROV behaves. You can also experiment (before zeroing the D term) decreasing the ATC_RAT_RLL_FLTD frequency. This last parameter is a low-pass filter on the D term that could help reduced this oscillations.

@mateov

Also, I should mention that there is some yet unidentified problem to why pixhawk doesn’t write the time correctly (date unknown is shown in QGC) so the time start is set to 01-01-1970. That should not be an issue in this particular case, but if you have any info about that, please be so kind to let me know.
Last log that has time and date is from Jun 2020, and some time after that update of companion to v0.0.21 was released.

That is an issue in ArduSub 4.0.

@mateov

I am adding pictures of my PID parameters, because I can not find default values to compare with mine. You can compare to their values, and maybe we can find out if this really is PID related and how to solve it.

It also looks like you don’t have the proper defaults parameters for the Heavy frame. you can check them here. Particularly, your ATC_ANG_RLL_P is 0 instead of 6.

[wholm (Walt Holm)]

So this past weekend I got a chance to dive the 6-thruster BROV2 I have that’s running Ardusub 4.0.2 (upgraded from 4.0.1 before this dive). As I posted earlier, it seems to be displaying a lateral shimmy that isn’t present in the BROV2 I have that’s still running Ardusub 3.5.

I 3-D printed a small bracket that mounts in the holes for the gripper arm, and holds a piece of M5 threaded rod in front of the dome. As this is mounted to the lower deck, any lateral shimmy between the upper and lower portions of the ROV could be seen as motion in the threaded rod.

Similar to what @mateov has been seeing, it turns out that the shimmy is only present in the stabilized modes- my memory had been incorrect when I thought the effect was there in manual mode as well.

I took some GoPro footage of the event with narration as to what was going on in the test.

Vibration of BlueROV2

Unfortunately I was busy running some other tests, so I didn’t have time to play with the PID values in the controller, or to revert the firmware to Ardusub 3.5. But it is interesting to me that I see the same effect that @mateov refers to, but on a 6-thruster ROV, and without any camera booms attached.

[Linus_OD (Linus Andersson)]

Hello Mateo,

I’ve had problems with vibrations like that when I have extra equipment on but for me, I’ve sorted it each time by working with the bouyancy and ballast weights. Especially when I add a lot of things outside the frame like flashes. I end up having it slightly more boyant with every addition I do to it.

This setup below had a lot of vibrations before I got the bouyancy right.

Hope it helps!

/Linus

[mateov]

Thank you all for the inputs you gave me,

We haven’t had time last week to test things out, we had to work with the ROV (with stiffened up upper part of ROV for now, to counter the vibrations).
We will try to do testing (first of all PID regulation) this week and I’ll get back to all of you.

Btw @Linus_OD, nice setup you got there, I belive it was pretty hard to balance out and eliminate the vibrations caused by additional lights
You have no vibrations with setup like this? Did you try placing buoyancy foam closer to lights (maybe easier to balance)?
You use your ROV for photogrammetry I assume?

[mateov]

Update to the situation:

as @williangalvani said, there were some PID parameters at unusal values. I changed the ATC_RAT_RLL_D to 0 and ATC_ANG_RLL_P to 6 and in our pool test I can confirm that the vibrations are gone! We haven’t had any bigger dives (40+ m), and as soon as we confirm behaviour in few dives I will tick the checbox for solution on @williangalvani 's post
I had to change both parameters to stop the vibrations, but now it seems to be working good.

Thanks everyone for the help

[mateov]

Just to keep you all up to date, yesterday we had a longer dive and BlueROV behaved great, no vibrations what so ever!
We basically stress tested it since we had a lot of vertical movement, without problems for few hours…

Quick picture of BR waiting to go into the sea

Thanks again @williangalvani for the solution.

Best regards to everyone.