I am working on controlling the BlueROV using a Pixhawk autopilot. So far, the firmware has been loaded on the Pixhawk using QGroundControl, but when configuring the vehicle, I noticed that some of the parameters recommended on this guide (ardusub.com/initial-setup/) were missing, specifically ACT_RATE_YAW_FILT_HZ, any of the STB_ parameters, and the option for disabling the motors instantly spinning upon being armed.
I also tried using Mission Planner to see if it was an issue with QGroundControl. It could not find any other parameters missed by QGroundControl, and I also noticed that it considered the ROV a multirotor copter (the SYSID_SW_TYPE is specified as a copter with no option to change it to a sub).
Are any of the things stated above actual issues? If so, how would I go about resolving them?
Thanks for pointing this out. Some of the parameters have changed name since we first wrote the documentation. I’ve fixed it and your should be able to find all of those parameters now. Please let me know if you have any issues.
When first armed, the stability controllers will become active immediately, so it is normal to start at rest and then build up RPM on the motors a little. This will go away in the way when the vehicle is actually able to stabilize.
The SYSID_SW_TYPE flag doesn’t do anything right now so we haven’t changed it to Sub.
Thanks, I’ll download and set up the new firmware.
Another issue we ran encountered recently is that when we arm the motors, the two rear-facing motors (1 and 2 in your firmware, I believe) do not respond to joystick input or even the autostabilization. The right motor is almost always off, very rarely displaying movement of any kind, and the left is constantly in full reverse. We tried rotating the autopilot to check if for some reason it was trying to orient a certain way, but no change occurred besides the right motor PWM dropping down for a very brief moment occasionally. Is there something I have to set up to have these respond normally?
Also, we noticed that there is no option for moving forward using a joystick, only pitch, roll, throttle, and yaw. How would we set that up?
Never mind about the motor non-responsiveness issue, they are all working correctly now. I ended up resetting the parameters to default, then redoing everything and it worked. Now the only issue is that I still can’t figure out how to control forward motion.
Ok, I believe I know how to control forward motion (channel 5, if I am correct), but the problem is I do not have enough control axes our joystick. I would need to either implement the control scheme where holding shift changes what each joystick component does, or somehow create a new control scheme (maybe where two different buttons raise or lower the sub’s depth). I can’t figure out how to implement the first method, so is there a way to implement the latter without editing the firmware, or should I stick with the first?
Sounds like you’re working through the setup well.
Channel 5 is actually used for the “flight mode”. You might be referring Channel 6, which is listed in the MAVLink Inspector as Channel 5, since they start at 0 in some places and 1 in others.
Channel 6 is for forward and Channel 7 is for lateral. QGroundControl calls these roll and pitch but we are using them for forward and lateral.
You should not need to assign any joystick axes to roll or pitch. Those should be left at zero so that the vehicle always tries to stabilize to level. Are you using QGroundControl to send the control messages?
Currently, I’m using Mission Planner, as I am slightly more familiar with it, and a Logitech Extreme 3D Pro joystick (http://gaming.logitech.com/en-us/product/extreme-3d-pro-joystick). Up until now, the joystick y-axis controlled pitch, x-axis controlled roll, twist controlled yaw, and the throttle controlled depth. I have changed it so that the y-axis now controls forward motion and the x-axis controls yaw, while the throttle still controls depth.
In terms of communication, we are using the Fathom-S boards to communicate using a Cat-5e tether, and a Pixhawk autopilot to control the motors.
It may be worth noting that I had to change the motor numbers within the firmware, so that the left-front, downward-facing motor is motor 1, the right-front, downward-facing motor is motor 2, the left backward-facing motor is motor 3, and the right backward-facing motor is motor 4, with 5 and 6 remaining the same. Motor 2 and 4 are reversed.
Okay. Currently, ArduSub does not support using Mission Planner. That’s because Mission Planner sends a different type of message for the joystick commands. I would recommend using QGroundControl if possible.
Honestly, I do not know why the motor position was changed. I was not part of that decision, but I was able to adjust for it. It may have simply been that those assembling it weren’t aware of the normal positioning.
Mission Planner, as far as I can tell, works fine, although I did have some joystick issues before which were fixed with some configuration changes. The only thing it can’t do is install custom firmware files; for that, I had to use QGroundControl.
MissionPlanner will mostly work. It will connect and the joystick will cause things to happen, but the joystick channels are mapped to the wrong RC channels and it does not have the button-mapping functionality to enable all of the other features in ArduSub like gain control, light control, camera tilting, etc.
One more question. When the sub is armed and trying to stabilize itself, we noticed that it never seemed to be able to reach a fully stable position again; the motors continuously attempt to seek a perfect position. Is there a way to lower the sensitivity so that the sub has some tolerance in terms of attitude adjustment? I did search through the parameters and didn’t find anything, but I may have missed something.