Controlling ROV to 90 degrees not working

[SaferHarbors (Stan)]

if i place the rov at a 90 degree angle will stabilize and depth hold keep the orientation. this is the issue im having. going to update again.

i have problems orientating the rov on a 90 degree pitch with all the thrusters but then i can go to the thruster test on qground and engage one thruster and get a full 360 degree rotation. i have to think this is a gain issue. Adjusted the gain and will go test again today with two batteries also.

[EliotBR (Eliot)]

Hi @SaferHarbors,

@SaferHarbors

if i place the rov at a 90 degree angle will stabilize and depth hold keep the orientation.

Stabilize and depth hold try to maintain a horizontal orientation unless the pitch and roll targets are altered (via joystick inputs or the roll/pitch trim button functions), so just placing it at a 90 degree angle will not work to maintain that. Note the ANGLE_MAX limitations discussed in that link - it may not be possible to control to 90 degrees.

This comment (and the surrounding discussion) are likely worth a read

[SaferHarbors (Stan)]

@SaferHarbors

thank you. I think we can alter her code more. The rov needs to operate 90 degrees and 180 degrees 100% of the time.

thank you. I think we can alter her code more. The rov needs to operate 90 degrees and 180 degrees 100% of the time.

[SaferHarbors (Stan)]

We couldn’t get her code to work. It’s missing some stuff. Looks like we are going to invert the pixhawk. To work inverted.

[EliotBR (Eliot)]

@SaferHarbors

Looks like we are going to invert the pixhawk. To work inverted.

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.

[SaferHarbors (Stan)]

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.

[EliotBR (Eliot)]

@SaferHarbors

I watched a video introducing the heavy setting watching it go 90 degrees on the side of a pool.

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).

@SaferHarbors

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.

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.

@SaferHarbors

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

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.

[SaferHarbors (Stan)]

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

[SaferHarbors (Stan)]

parameters 1017.params (24.7 KB)

[SaferHarbors (Stan)]

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.

[williangalvani]

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…

[SaferHarbors (Stan)]

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!!
@williangalvani

[reimonha]

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.

[williangalvani]

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 =].

[reimonha]

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.

[williangalvani]

@reimonha

I suppose that the “set target attitude script” must be on the companion computer.

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

[reimonha]

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:0.0.0.0:14550”, but still no hearbeat is detected. I directed myself to http://192.168.2.2:2770/mavproxy and i saw:

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

I am running it all from the surface computer.

Thanks.

[EliotBR (Eliot)]

@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:

@EliotBR

# --out udpout:192.168.2.1:14660 in http://192.168.2.2:2770/mavproxy list
master = mavutil.mavlink_connection('udpin:0.0.0.0:14660')
# ensure valid connection
master.wait_heartbeat()

[reimonha]

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?

Thanks.

[EliotBR (Eliot)]

Did you restart MAVProxy after adding the --out udpout:192.168.2.1:14660 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.