Controlling ROV to 90 degrees not working

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

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.

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

Thanks.

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.

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

Hi @EliotBR , @williangalvani , i will like to continue with this thread.

Now we are making test on a simulator, this to speed up the try/test process. We follow instructions from : Setting up a simulation environment

Everything is working fine, so on that part, all good.

I was testing the code you shared, @williangalvani . Pymavlink · GitBook

And i have an observation:

  • Target depth is hold as expected, if i input 5 meters, 2 meters, the ROV follows the instruction as it should. No problem on that.
  • The issue arise on the set_target_attitude function. i try with something simple, like test the yaw movement, i see that what it actually does is go to that yaw angle, and then comes back to the original position. This behavior is follow on roll and pitch.

Is there a way to modify this function so it can actually hold the angle asked?, like the 90 degrees or 180 degrees for roll

Thanks in advance.

Cc: @SaferHarbors
.

1 Like

@williangalvani @EliotBR please help with this issue. It’s something we have been stuck on for a very long time.

1 Like

Hi, I’m very sorry for the delay.

ArduSub requires periodic messages in order to keep pointing to an attitude target. That is why it is sent every one second in our example.

1 Like

I tried the take a spin code through SITL and it dives a bit and then the rov just goes out of control in every aspect.

1 Like

I’ve noticed some issues with SITL here, I’ll do some investigation.

2 Likes

It didn’t the same thing with on the rov as well.

Do you have any updates for us? I also ran into that problem a while ago and made a forum post, but i found no proper solution.

I never got a solution.

Any luck?

Sadly not. I moved on.