Image and ArduPilot version: emlid-raspbian-20170323.img with ardupilot-navio2-copter-3.4.6-1.0 quad (15) running on a Raspberry Pi 3.
Detailed problem description. How does observed behavior differ from the expected one?
When I move the pitch stick forward or up the quad moves backwards when I would expect it to move forwards. When I move the pitch stick backward or down the quad moves forwards when I would expect it to move backwards.
Roll and yaw are working as expected.
Graphing the RC Channel Raw Input and the Servo Output from the telemetry log while the quad is sitting on my desk with props removed shows this quite clearly:
When pitching forward, outputs for the Front Right (output 1) and Front Left (3) go high making the quad move backwards.
When pitching back, outputs for the Rear Left (2) and Rear Right (4) go high making the quad move forwards.
The Pi/Navio2 is mounted in the standard orientation on top of the frame with the USB ports pointing forward, and the status LED and GPS connector pointing toward the sky.
AHRS_orientation is set to zero (0).
I’ve also calibrated the RC channel inputs, this appears to be confirmed by the fact that when I pitch forward, the pitch channel (2) goes up and when I pitch back it goes down.
Gyro/Accelerometers appear to be functioning as expected going by the flight display.
When flying in Stabalize and Loiter modes the quad is quite stable and flies as expected apart from the pitch being reversed. I did try setting up a flight plan but as soon as I switched to Auto mode the quad started heading straight up, I’m guessing that this was because Ardupilot was trying to pitch forward toward the first waypoint but because of the reversed pitch it actually starts moving backwards at but to try to correct this and keep the quad flat it speeds up the rear motors, nett effect being to go straight up!
I’ve double checked all my connections and they seem to be good. Any suggestions would be greatly appreciated.
Not sure how you extract gyro and accel values, but when playing with what is described at Getting IMU data - #8 by ffl I found that the coordinate system seems to be left handed, with the Y axis (pitch) being the other way round, if you see what I mean…
I check the config in my TX (Turnigy TGY 9x running OpenTX 2.1.9 + FrSky) and channel 2 wasn’t reversed. I’ve changed it so that it is reversed and re-calibrated the radio in APM Planner. Pushing the pitch stick forward now decreases RC channel 2 input into the Navio, and moving the stick back or down increases the input value.
I haven’t had a chance to check it in flight yet as the weather has been wet and windy.
I’m still a little concerned about the rapid ascent when I switched to auto mode. Each waypoint had a relative altitude of 5m so I wasn’t expecting significant altitude changes. I need to go back and analyse the log more closely to check GPS VDOP/HDOP and fix type etc. I’ve got a piece of foam mounted over the barometric sensor. Hopefully this weekend I’ll get some time to do some more thorough and controlled testing.
Some time soon I’m going to invest in a Reach unit, and pair it with my ublox Neo-M8T and Tallysman TW2710 base station to improve GPS accuracy.
Good news, the weather cooperated with a nice calm morning. Inverting the pitch stick in OpenTX certainly solved the pitch behaviour when flying and auto mode also worked as expected this time as well. I only had time for a very quick test flight so didn’t get a chance to have a good play around but I am very happy with how the Navio2 performed.
One curious thing is that when exporting the telemetry log to KMZ the segmented flightpath comes out about 1m larger than the flightpath. I.e. in auto mode I set up four waypoints in a roughly rectangular shape. When I flew this plan the segmented flightpath shows a rectangle approximately 1m larger on each side from the plain flightpath. This is most likely unrelated to the Navio2 and more likely to be something to do with Arducopter or APM Planner, but just wondered if anyone had seen similar.
