Home        Store        Docs        Blog

Downunder ROV build


(Jacob) #41

Did you have the joystick connected while testing arming with qgc? All of the motors will drop to minimum values if there is no input at all when armed, an issue that needs to be addressed, but that is for another conversation. That means that motors 3 and 4 should be around 1100 if you don’t have a joystick connected.
I should also mention that with the firmware I sent you, the motor pwm values are limited to a maximum of 1800 to save battery while testing. There is also a parameter THR_MIN which I increased to 30 percent for the same reason, this limits the minimum throttle (only affects motors 1,2 and 5).


(Andrew) #42

You’re right, I didn’t have the joystick driver installed the Windows machine, which would explain the drop to 1100. I’ll try a fresh qgc install anyway.

I’m now wondering if there might be an issue with the Pixhawk hardware itself. I assume I’ll be able to check this by looking at the raw sensor outputs.


(Andrew) #43

Woo hoo - no more turning!

When I loaded the new qgc I noticed that it now turned left and the turn was less pronounced than last time. So I double checked the RC3_TRIM & RC4_TRIM parameters. Both had settings not near 1,500 which were being added when I calibrated the gamepad. I set the trim back to 1500 and added RC3 & RC4 Deadzone values of 50. Turning problems now fixed.

Thanks for your help Jacob & Rusty, much appreciated!


(Rusty) #44

Andrew,

Great! I added a note to the documentation about this to help others.

http://ardusub.bluerobotics.com/troubleshooting/#troubleshooting

-Rusty


(Andrew) #45

Finally had a bit more time to spend to fine tuning the build over the weekend. Overall very happy withe how it’s running.

Some underwater footage here: ROV underwater - You Tube

I’m using the ArduSub depth control branch which has excellent depth control and stability. (The video clip from about 2:20 demonstrates this best - the ROV is sitting in a reasonable strong cross current from the pool pump outlet)

The weekend enhancements were:

  • Slightly shortening the lower WTC to allow easier battery access
  • Moving the vent on the upper WTC to the front to allow the spare cable penetrator hole to be used for lighting. Currently have: 1-6 ESC's, 7 Depth, 8 Power from lower WTC, 9 network cable, 10 (now free for lighting)
  • Adjusted the ArduSub motor config file to improve strafe. My bottom thruster is a little forward of centre to allow for placement of the lower WTC, so needed to provide a little counter rotation to prevent twisting - now works reasonable well with 0.4 and -0.4 strafe applied to the respective forward thrusters.
  • Adjusted the button mapping in ArduSub to work with the Logitech 310 controller I'm using (now aligns with the buttons described in the ArduSub documentation).
  • Fitted a GoPro mount.
  • Fixed the direct Ethernet connection between my laptop and the RPi2 as sometimes it worked first time, other times it needed multiple restarts of the RPi2 and the laptop to connect. Solved by changing auto eth0 to allow-hotplug eth0 in the interfaces config file of both.
Still to do before sea trials
  • Install the LED lighting.
  • Fix slight port list (5 degrees) when in stabilise . This is very curious. I've calibrated a few times and checked the Pixhawk levels but I don't think that's the issue as the artificial horizon in qgc correctly shows the 5 deg list it settles on. I've checked the trim parameters but may have still missed something.
  • Add some flotation to the tether cable to get it neutrally buoyant.

(Andrew) #46

Clip time in previous post should be 1:56


(Jacob) #47

Give these a try, these params improve the stability of attitude and depth control over what I put up previously.
-Jacob


(Jacob) #48

https://drive.google.com/file/d/0B3qigmLtnoGKSGVrcG1waWlxZWc/view?usp=sharing


(Andrew) #49

Thanks,

I’ll give them a try tomorrow.


(Andrew) #50

Hi Jacob,

Are you running these param’s on the depth control or master branch firmware? I loaded them up and all worked fine except I couldn’t adjust the depth in alt hold mode.


(Andrew) #51

Also noticed that your RC mappings for roll & pitch are swapped from the default mapping setup, so assume your running a slightly different joystick setup?

Parameter Value
RCMAP_PITCH 1
RCMAP_ROLL 2
RCMAP_THROTTLE 3
RCMAP_YAW 4
RCMAP_FORWARD* 6
RCMAP_STRAFE* 7


(Jacob) #52

Hi Andrew, there is a bug in the current master for the surface detection which won’t let you dive while at the surface. Try pushing it below the surface while holding down the dive input. Please let me know if you are observing something different, or if you are using the depth-control branch.

Yes, I don’t use the qgc joystick setup, I go through ROS with a different configuration, similar to helicopter controls. I would like to get you the firmware file I am using and address the issues on github, but wont have access to that machine to compile it for you for a while as I am busy with work.

-Jacob


(Andrew) #53

Thanks

I currently have the master branch loaded. I tried pushing below the surface but still couldn’t alter the depth in depth control mode.

I’ve just compiled the depth-control branch so will give that a try over the weekend to see if that fixes things


(Jacob) #54

You could also try enabling fence, and setting the maximum altitude to -0.20. (20 cm depth)

Make sure fence type is altitude only, and fence action is report only. There is also a parameter in the default group called fence_min_alt or max_depth that will limit the maximum depth in meters. I think I had it set to -1.5 (1.5 meters depth).


(Andrew) #55

fence_alt_max is set at -0.1 and fence_depth_max at -0.4 in the parameter file posted above which might explain the behaviour, though fence_enabled = 0


(Jacob) #56

I think that setting alt_max to -0.30 or something lower will override the behavior you are seeing. Just make sure that depth_max is set lower than alt_max. Right now with fence_enabled = 0, it has no effect. I am aware of what is causing the issue.

If you want to fix the bug, https://github.com/bluerobotics/ardusub/blob/master/ArduSub/control_althold.cpp#L130

change to

pos_control.<span class=“pl-c1”>set_alt_target</span>(g.<span class=“pl-smi”>surface_depth*100.0</span>);


(Andrew) #57

Thanks

I’ll apply the fix and give it a try


(Andrew) #58

Hi Jacob,

I made the change in the post above to the master branch and applied the parameters from the downloaded file. Still have some odd behaviour on depth hold - now going straight to the bottom and trying to push through the bottom of the pool in depth hold mode. Everything else is working great.

Too dark now to try new options but will play with the parameters etc tomorrow.


(Jacob) #59

This is what I’m flying.
https://drive.google.com/open?id=0B3qigmLtnoGKckRnTDQ4SFdPbTQ

I’ve made several changes including addressing the bug in master branch, but I haven’t had time to go through those changes and break them into separate commits and get them into the github repository. I probably forgot something I did in my advise to you in the previous post.

Find the parameter called “surface_depth” and set it to -10.0 for 10cm depth or -20cm for 20cm depth etc. If you set it too close to whatever the sensor reads in air, then the pressure wont change significantly enough for it to know that it needs to stop trying to climb out of the water.
Good luck, Jacob


(Andrew) #60

Brilliant - Thanks Jacob

That downloaded firmware works great - only slight problem is that I lose the customisations made for the slightly forward position of my bottom thruster and some button mapping changes, but great to have some working code again.

Look forward to applying the customisations and getting a solid code base for the first sea trials once you’ve had the chance to get the changes into github.