Here’s a text log of the yaw, pitch & roll.
The yaw is showing very odd behavior (this log has no stick input) - when I rotate the ROV the yaw jumps from ~+3 to ~ -3 then back again? The attached chart plot shows better what I mean.
https://dl.dropboxusercontent.com/u/9311624/log3.log
rov-log-chart (51.7 KB)
If you can, connect to the vehicle while it is in the water, arm it for ~20 seconds, then disarm it, disconnect and save the log, so I have a smaller one to look at. Don’t use any pilot input while doing this. It will be much easier to analyze/seek to different positions if the log file is less than 60s.
-Jacob
Something interesting I notice in the log file is that all of the rc inputs periodically drop out to zero. This might be an artifact of the log playback, but I don’t think that’s what it is. Also, channel 5 is at 0 when the other channels are at 1500. It should be either 1000 or 2000. What are you using to get your controller input into the pixhawk? I do see that as soon as you arm it the motor outputs amount to yaw, while rc input channel 4 remains at 1500 (no yaw). Something is definitely up here, and I bet it is something simple. You should keep compass use disabled just to rule that out while we hunt down the issue. If you want, I can put up a link to my firmware and parameter file.
-Jacob
Hi
Thanks, try this one - no user input - near the end it hits the pool edge so last few readings will be off.
https://www.dropbox.com/s/s89z34eyf71ichb/Logshort.mavlink?dl=0
Thank you, that is a much more useful log for debugging. I will link to a firmware file and parameter file tomorrow, and we can see if you still have problems with that. I am using the BlueROV frame config and have never had this behavior. I would really like to figure out what it is. If you use the firmware and parameters that I am using and still have the same behavior then that will help narrow it down.
It is still intriguing to me that channel 5 is at zero instead of 1000 for stabilize mode. What are you using to input the pilot commands?
One thing to try in the meantime, in the default parameter group set and save GND_BASE_RESET to 1, then reboot the board, all while in the air.
You should also recalibrate your accelerometer and compass. Make sure that when you calibrate compass, the flight controller is in the enclosure with all other electronics, in the same environment as when it is flying. ie, put the whole rov together and spin it all around during calibration. Setting compass_use to disabled should mean the compass calibration doesn’t make a difference, but I am just trying to cover all bases. Your calibration seems to be ok because the heading and attitude is solid when it isn’t moving, but it doesn’t hurt to recalibrate.
-Jacob
@Jacob, if using QGC, channel 5 will stay at zero until one of the mode buttons (Y or B) is pressed. We can fix this by initializing the mode value in radio.cpp.
@Andrew, for diagnostic purposes you can turn down the yaw PID terms, RATE_YAW_P, RATE_YAW_I, and STB_YAW_P. If you turn them all to zero we can see if the yaw controller is causing the issue.
-Rusty
Thanks for your help.
I’m running qgroundcontrol on a laptop (Ubuntu) where a logitech 310 game controller is connected. The laptop is then connected via ethernet to the onboard Rpi running Mavproxy. The RPi is connected to the Pixhawk via serial. Video is fed via video stream directly into the qgroundcontrol HUD.
Sounds like you’re providing the pilot commands via ROS? I’m a bit suspicious of the mavproxy link, so will try your firmware & parameters and use ROS for the commands. Are you using the HUD in qgroundcontrol?
Thanks Rusty, will try with the yaw PID zeroed out.
I usually use the HUD in QGC and it’s been very reliable. Haven’t used mavproxy much.
By the way, feel free to join our Gitter discussion on ArduSub development if you’d like:
Thanks Rusty,
ROV runs dead straight with YAW PID’s zeroed out.
Andrew, okay. When the vehicle is sitting still, does the compass spin?
Compass is steady and seems to point where it should
Try this,
https://drive.google.com/folderview?id=0B3qigmLtnoGKc2YzQUNSdEVDVHc&usp=sharing
Use the python script to upload the firmware:
python3 px_uploader.py --port /dev/ttyACM* /<path to firmware>/ArduSub-v2.px4
This is not the master branch, but it is what I was running today. The difference is that alt hold is limited so it won’t try to dig into the ground or fly out of the water. Fence can be enabled to set a maximum (and minimum) depth in alt hold mode. Also began playing with some of the pids for alt hold.
Let me know what you think of those changes as well.
-Jacob
Hi
Thanks for the updated firmware - The limit on the alt hold is great, especially when the ROV reaches the surface. Yesterday when surfacing in alt hold mode I’d get a mass of frothing water on the surface, today nice and subdued.
Still have the right turn issue unfortunately.
I loaded your firmware and uploaded the parameters.
I also recalibrated the Mag and Gyro, but still it spins right.
This one’s got me stumped.
As a further test I tried physically holding the ROV and turning the frame left. When I tried this, the thrusters would increase power to rotate right and fiercely resist turning left.
Do you have an rc receiver attached? The log indicated that this might be the case. If it is not, I have no idea why that would show up.
-Jacob
Hi
There’s no rc receiver attached, I suspect it’s the MavProxy emulating RC signals to the Pixhawk. To eliminate MavProxy as the cause of the issue I’ll reinstall ROS on the RPi tomorrow and try sending commands using ROS.
Unless there’s another tested method of sending commands from qgroundcontrol on the laptop to the pixhawk via an Ethernet link?
Try plugging your pixhawk directly to your computer with usb cable, without power to the motors, you don’t have to unplug the motors signal wires. Then in qgc connect to the pixhawk via serial, pick the port and use 115200 baud. In widgets, go to mavlink inspector and look at servo out raw and rc channels raw. Get the pixhawk as close to level as you can. Arm the flight controller and see if motors 3 and 4 jump to 1400 and 1600 (what I was seeing in the log) or something not close to 1500. This will be the easiest way to bypass mavproxy and rule it out as an issue before going through the trouble of installing ros. If you have an rc receiver and transmitter, you could try connecting that and arming as well to see if qgc is the issue, if you do that make sure you do not have joystick enabled in qgc, or unplug the joystick from the computer.
-Jacob
OK.
Tried that and got 1700 on 3 and 1200 on 4, so mavproxy is not the problem.
Will try with an rc controller
Now highly suspicious that qgc is the problem as Jacob has referred to above. Tried the same test on a fresh qgc Windows install and got near 1200 on both 3 & 4 - but at least it’s even.
Will try a completely fresh qgc install and calibration tomorrow, then wet test this latest hypothosis.