Controlling ROV to 90 degrees not working

By default the Pixhawk is assumed to be oriented with the Roll90 configuration. If you want that flipped you should be able to calibrate your sensors with a flipped orientation (e.g. Roll270), but you’ll need to make it so that the vehicle is correctly upside down during the calibration.

That said, that helps with the inverted orientation, but not operating at 90 degrees, which still has the caveats/requirements mentioned in the comment I linked to in my previous response.

1 Like

the brushes rotation suction controls the forward momentum. I watched a video introducing the heavy setting watching it go 90 degrees on the side of a pool. I don’t even need huge lengths of cleaning areas. Just 50 feet at a time.

I did finally get everything updated with qground and the most updated firmware. Now the issue the thrusters don’t seem to link to the controller again. I Can test them through qground.

I tried Mobula software last week. Good support it’s not all that easy to work with and seems to not be as streamlined.

I just watched our “Introducing the BlueROV2 Heavy Configuration” video (which I assume you are referring to), and it seems to go close to but not exactly on 90 degrees - perhaps that behaviour is sufficient for your application. If gimbal lock occurs it may be possible to recover (when you want to change orientation) by briefly going into manual mode (assuming your vehicle is self-righting by its buoyancy and mass distributions).

Can you go to QGroundControl’s Parameters page, save your current ones to a file, and upload them here? I believe this has come up before, so it’d be good to have an example of it.

Once you’ve saved your existing ones, the issue should hopefully be fixed by Tools/Reset all to firmware's defaults. Note that you may need to re-specify your other configuration details (e.g. lights pin, camera mount pin, power sense module, etc) as a result.

Fair enough. While QGroundControl could improve from a stability, features, and configurability standpoint, it is the control station software we’ve done the most work with ourselves (so far), so it’s not too surprising if it’s more well-integrated with the BlueROV2 system than other options.

Yes that did work. I just have to recalibrate everything.

1 Like

parameters 1017.params (24.7 KB)

1 Like

Unfortunately i am dead in the water with this project due to not being able to go past 90degrees. im going to have to completely rebuild as a crawler since this seems to be impossible. The lady that built the spiderman firmware left out some key stuff in her software. she agreed to help me but stop contacting me. There is nothing online anywhere to solve the gimble lock issues.

Hi @SaferHarbors ,

Ardusub should be able to maintain pretty much any arbitrary attitude if you have a heavy setup.
Have you tried the Attitude example in our pymavlink docs?

I’m easily able to flip my ROV upside down in stabilize or depth hold in my pool. So I’m not quite understand what your issue is…


I was led to think that I couldn’t hold a heading at a roll over 80 degrees. The gimbal would lock up and would be difficult to control. I finally have my parameters and updated firmware along with updated qground. The rov does weigh 70 pounds all together.

Will go test tomorrow. I hope you are right!!

Hi @williangalvani , quick question, i see the Attitude example you attach, but for my understanding, the position there will be fix, isnt it? once entering Depth-Hold mode we will keep that attitude? or that position is just the point of reference and we can manually manage and position it differently?

We want to achieve something similar to this, but orientation/attitude varies, thus, hardcoding it will not work so much for it.

If this is like the new point of reference, and orientation (and position) can be altered through the controller, then I think this will be it.

PD: We are more interest in attitude control (upside down control) than depth control.

Thanks in advance.

Hi, @reimonha. That should work relatively fine too. It’s been in my to-do list to improve the behavior for a while. Right now you can change attitude (the whole way) using the trim buttons (usually shift+directionals on the joystick). This changes the roll/pitch targets accordingly (in vehicle frame).

The main issue right now is that when there are yaw inputs, we revert to a “angular velocity” control instead of “angle control” which may cause the vehicle to loose the roll/pitch target it had before said yaw input.

Long term, I want to do all attitude angle control in closed loop. The main issue so far has been input lag, but that should be somewhat solvable using the feed-forward gains. If you are willing to do some work and tests, we could maybe work together to get that done =].

1 Like

Thanks, and will love to collaborate with this feature.

I can start by making a test of the “set attitude target example”, I may be bothering you a little bit just to get it working, and of course, outside this post I can share with you more information about the main scope of the project in which me and @SaferHarbors are right now.

First question, I see the pymavlink code can be run on the companion and the surface computer. I suppose that the “set target attitude script” must be on the companion computer.
Does Ardusub code must be compile again to the Pixhawk after inserting this script, can i just added to the companion computer and register the function (script) on bash/shell, which will be the way?

Thanks in advance.

It can work on either. as long as there is a mavlink connection.

Hi @williangalvani , quick question, for the ip assignment when making the mavlink connection, i have an issue with the “master.wait_hearbeat()” , the pixhawk is not responding. I already made sure it is connected, it is listed on “ls /dev/tty*”

For the connection ip and port i have my doubts, according to the documentation is must be set at “udpin:”, but still no hearbeat is detected. I directed myself to and i saw:

I also set it to “udpin:” and nothing. Try changing the ip to their corresponding and even (raspberry ip):

I am running it all from the surface computer.


@reimonha the issue you’re having is that there must be one side acting as a server, and one as a client - you can’t have udpin at both ends.

If you’re wanting to run Pymavlink at the same time as QGroundControl, try something like this:

Sorry but no, i see no answer from the pixhawk, “wait_hearbeat()” just stay in stand by waiting for the response.

I can ping to rasp, QGround is connected to ROV and I can arm it, so, Pixhawk is connected and working.

Is there a reason of why the Pixhawk is not responding?


Did you restart MAVProxy after adding the --out udpout: line to the configuration?

There are some more detailed steps here if that’s helpful (although they use port 14551 instead of 14660). That’s the comment I was originally intending to link to yesterday, but couldn’t find it at the time.

1 Like

Hi @williangalvani, @Elliott , we are opening this forum again.

We were able to make the code executable, and test it but we are having some issues at the moment.

I modified just a little the code, previously the code will spin in one direction (certain degrees per second), wait, and then come back to same position.
At the moment, the code just make the ROV spin 180 degrees and stay there, just that.

But we are seeing that the spin instead of being on the roll axis (or pitch axis), it is spining on the yaw axis, in other words, is never reaching the upside-down position.

We have calibrate and re-calibrate orientation, sensor, compass, etc.
QGround is showing the correct orientations and positions, thus we believe the issue is not on that side.

Something worth saying is that when running on Manual mode, some joystick signals are mixed, ex. Forwards is backwards, sometimes the throttle is yaw, forward is left, etc.

We have run several times joystick calibration, sensor calibrations, it corrects, but when disarmed and arm again, this MAY happen again. On joystick calibration sometimes we faced issues as the throttle not behaving as expecting, jiterring or stickin in place.

I think these two problems are related, but not so sure how to correct them.

We are thinking on changing the controller, but still, even if the controller is bad, shouldnt the code work as expected, as it relies on the sensors signals?

Any idea?

Thanks in advance.

Hi @reimonha

This sounds like misconfigured motor outputs. please check the thrusters one by one.

I checked each motor manually and they function as they should but when I do the automatic test I immediately get an error on motor one. @williangalvani

A post was merged into an existing topic: Automatic Motor Setup and frame