Unfortunately, I lost my plane today, I uploaded a mission to the pixhawk using droidplanner2, used an auto-takeoff, it launched just fine, climbed to the target altitude, but instead of turning for the first waypoint located to the southeast, it turned due north and continued straight and level, then I realized I had a serious problem and immediately changed to RTL mode which the tlog confirmed, but it didn't turn at all and continued on a due north heading, then I lost RSSI and telemetry shortly after, but because RTL failed to work, the failsafes didn't do any good after both comms were lost.
Another thing I don't understand is after reviewing the tlog, the direct-to bearing for the home waypoint was correct the whole time, but it simply refused to turn for home.
I've attached the tlog, if anyone can give any insight as to the cause I would greatly appreciate it.
I'm running the most up-to-date arduplane software, a pixhawk+ublox GPS, a pair of 3DR telemetry radios, Taranis handset, Mission Planner for creating missions, and droidplanner 2 for ground station and transferring missions to pixhawk.
Thanks,
Jeff
Replies
Jeff, I think I found the cause of your flyway. The curious thing about your log file is that the autopilot never commanded a roll change, even though the navigation controller was apparently tracking the correct waypoints (and, as you noted, engaged RTL). I wondered what would cause the commanded roll to stay near zero, and suspected it might be a tuning issue. When I reviewed these parameters, I noticed that you have LIM_ROLL_CD set to 45. This parameter is actually measured in centidegrees, so the Pixhawk refused to command a roll more than 0.45 degrees--effectively zero. That parameter should have been set to 4500.
I'm sorry for the loss of your plane. I had a flyaway of my own once, so I know the experience.
Mark, I posted this issue on the ArduPlane forum also, and one of the developers(Tridge) reviewed the log and stated it was indeed a units issue that caused this. I was thinking of increasing the roll limit, but then decided to change it back and keyed-in "45" instead of "4500" because I didn't realize the units were centidegrees, and yes that's what prevented it from turning even when in RTL mode. Tridge stated that they will add valid min max limits or a failsafe check to prevent this from happening to others, and needless to say, I'm going to be extra careful with units when making any adjustments in the future!
- Jeff
Oops, I missed that other thread, but I'm glad you got your answer.
I'm glad Tridge is adding parameter checking on this. I've always felt like this was an accident waiting to happen, especially since this parameter is expressed in degrees on one page of Mission Planner and in centidegrees on a different page.
Hi Mark,
I'm just going to learn from reading such logs. Can you explain why at the beginning of AUTO a much larger roll was possible?
thanks
Wolfgang R.
Wolfgang, sure, no problem! When you're reviewing a log, be sure to to look at both:
1. What the plane is actually doing (roll and pitch, for example)
2. What the autopilot is commanding the plane to do (nav_roll and nav_pitch, for example)
In this case, #1 shows that the plane has a slight wing rock on takeoff (around 13 degrees max). However, #2 shows that the autopilot was commanding a zero-degree bank angle at the time. If you look at the attached plot of both 'roll' and 'nav_roll', you will see that nav_roll only changes from zero a little later, and then it only commands the maximum roll of 0.45 degrees.
I hope that helps!
Mark
flyaway_roll.PNG
sorry, did not get it that LIM_ROLL_CD works on nav
thanks for the explanation
Wolfgang R.