Hi Tridge,
We found the problem and have Plane 4.2 Beta now working well with my Pixhawk Cube Orange. The problem was that the pwm max/min parameters were set to zero. Once we set them to 2000/1000 respectively, the motor signals began to work properly and the ESCs started working.
William
The v4.2 log shows it is working fine. You have FLAP_SLEWRATE=1, which means the flaps move extremely slowly. A value of 1 means maximum of 1% per second, so it takes 100 seconds for your flaps to move through the full range. Try using FLAP_SLEWRATE=50 for a more reasonable value.
Thank you very much for the quick response. It’s clear that the FLAP_SLEWRATE parameter is set to a ridiculous value. I guess as in v4.1.7 it was never satisfactory and the flaperons worked (fast but they worked) I forgot about it and when I used v4.2.0(BETA 2) FLAP_SLEWRATE did its job.
Now I don’t have the possibility to reinstall v4.2.0(BETA 2) but when I can I will try it and confirm to you that it works correctly.
Thanks again for your fantastic work.
I was able to install v4.2.0 (BETA 2) again on an F765-Wing and the flaps/flaperons work perfectly. The FLAP_SLEWRATE parameter also works by allowing for smooth unfolding and retracting.
By the way, I also tried the rpm issue (telemetry) and it also works perfectly.
Happy flying!
Pitch PID not working. Nav_Pitch signal tracks Pitch when motors off, But when motors turned on, Nav_Pitch signal rails to zero and does not track Pitch signal anymore. I am using the same PID values I used before using Arduplane 4.2 Beta. Here is a log file of the test:
Thanks, William
p.s. Here is a link to see the vehicle I am testing:
I’m the guy building the F-35B.
I am running a YouTube channel.
from 4.17
Q_FRAME_TYPE = 0, Q_FRAME_TYPE = 16
in both
There is no reaction of TailTilt Servo (Function 39).
I would really appreciate it if you could put a forced reaction option.
Is this only possible with a tricopter?
I don’t really understand what you mean. Looking at 2.bin I see:
Hi Tridge, I have been working with Mark Whitehorn to get his PR for forward tilt using the elevator stick, based on ArduPlane 4.2 Beta. We got it to work in the SITL Convergence model, and in my 1/6 scale model of my flying car with a Mini Pixfalcon. But we ate still have a problems getting it to work in my full scale vehicle with a Pixhawk Cube Orange. The 1st problem we solved was getting the ESCs to work. It turned out the PWM min and wax values was somehow reset to 0. The ESCs began working once the PWM min and max values were set to 1000 and 2000 respectively.
It seemed like everything was working ok. So we test hovered the vehicle indoors and the vehicle crashed due to a huge oscillation in pitch that developed as I pitched the vehicle to move forward. During this test Mark’s tilt forward using the elevator stick feature was disabled using a ch 6 switch, making the vehicle supposedly fly like it did before (elevator controled vehicle tilt to move forward). I have just finished repairing the vehicle and now I am trying to find out what caused the oscillation in Pitch. Here is a video of the crash:
https://drive.google.com/file/d/17bHAaIiqv-EL-SQx92T-C35bQvt7utzO/view?usp=drivesdk
Here is a log.of the crash:
https://drive.google.com/file/d/18VFo318dApYK0Rpyd0MWOfffBh8Y9vvF/view?usp=drivesdk
Here is my analysis of the crash:
So today I placed a beam under the vehicles CG enabling the vehicle tilt up and down, and fired up the motors a little to study the stabalization. The results looked strange to me. I monitored Pitch and Nav_Pitch signals and noticed that they track nicely if I physically tilt vehicle up and down. But when I fired up the motors the Nav_Pitch railed to zero! This surprised me because. But Mark thinks this is ok.
Here is a picture of the Nav_Pitch and Pitch signals. Note the signals track very well when the batteries to motors are not connected. But as soon as the batteries to the motors are connected and the throttle is applied, the Nav_Pitxh signal rails to zero:
Here is a link to see a video of the previous test flight before we changed to ArduPlane 4.2 Beta using Mark’s elevator stick controlled tilt forward PR:
https://drive.google.com/file/d/1csnLLtug1sz9msU4BM_flKp9pHXlquIa/view?usp=drivesdk
So we know the vehicle works and can fly stable.
more useful than video would be the log of it flying with the previous version but the same parameters, then a log of it not flying well with 4.2 with those same parameters.
Hi Tridge, Below is the log corresponding to the good flight video before the change in firmware. The firmware used in this flight was ArduPlane 4.0.9. The log file is called 189.bin. and the last flight corresponds to the good flight in the above video:
https://drive.google.com/file/d/13ZNRs12hImmTXA9Oiuq6vj8hkzbfCtTw/view?usp=drivesdk
And this was the flight video:
https://drive.google.com/file/d/1csnLLtug1sz9msU4BM_flKp9pHXlquIa/view?usp=drivesdk 2
Here is a log of the vehicle crash using ArduPlane 4.2 Beta. The same PID parameters were used:
https://drive.google.com/file/d/18VFo318dApYK0Rpyd0MWOfffBh8Y9vvF/view?usp=drivesdk
Here is a video of the crash:
https://drive.google.com/file/d/17bHAaIiqv-EL-SQx92T-C35bQvt7utzO/view?usp=drivesdk 1
Thanks, William
Hi Tridge,
I compared the flight log signals of the good flight and the crash flight. In the crashed flight log I am seeing a huge oscillation in the P of the Pitch PID controller. I think the Pitch P param needs to be lowered. Here is a link to see the 2 log files compared. The thing to notice is the scaling of the Pitch and Des_Pitch in the 2 graphs.
William
hi William,
The 4.0.9 log also shows very bad control. Here is the pitch axis for one of the flights in log 189.BIN:
If this fails to produce a good responsive pitch tune then you need to adjust filtering and acceleration limits. I notice your accel limits are still at defaults (Q_A_ACCEL_P_MAX is 110000). That is likely way too high for this vehicle. You also haven’t set Q_A_RATE_P_MAX, which likely should be 45 deg/s or so for this vehicle. Same for other axes.
I hope this helps!
Hi Tridge,
The large pitch oscillation was caused by the D parameter of the Pitch PID being too high. When I changed from D=0.01 to D=0.001 the large oscillation went away. I was also able to increase P to from P=1.0 to P= 1.8 before I saw heard the motors oscillate. So I reduced it to P= 1.4 for the test. I noted a little oscillation at D= 0.005, so I reduced it to D= 0.001 for the test.
I tested the vehicle by placing a narrow board under the vehicles side panels at the CG with the motor batteries mounted in the front of the side panels. The vehicle was about level when I tested it and it could pitch up and down about 5in as seen at the back end of the vehicle.
In the test, I am testing Mark’s new PR (4.2 Beta) with the elevator stick controlling the forward tilt of the front motors. But back elevator stick tilts the vehicle back. The motors tilt correctly and the pitch seems relatively stable (other than the usual small angle oscillation always present) during the tilt. Pulling back on the elevator pitched the vehicle up until it hit the ground, preventing the vehicle from responding to more pitch.
Blue - Elevator stick
Red - Pitch
Green - Desires Pitch
Yellow - Motor tilt
There seems to be something unexpected happening in this release for automatic landing. Up until now, RTL_AUTOLAND was optional. I could set up a mission with automatic takeoff and landing, but the RTL behaviour was “loiter at Rally point” (or breach point), but now when I try to arm with a mission loaded I get this message:
PreArm: DO_LAND_START set and RTL_AUTOLAND disable
This is the telemetry log. The problem happens about 85% in:
I checked the docs here, and I would say it’s pretty clear that RTL_AUTOLAND is supposed to be an option, not required. Was this intentional?
RTL_AUTOLAND is indeed optional, but in your log I see you have a DO_LAND_START mission item. The DO_LAND_START does not function at all without RTL_AUTOLAND enabled. We had an incident where a user setup a DO_LAND_START landing mission and didn’t set RTL_AUTOLAND. They were relying on the aircraft flying back via the DO_LAND_START sub-mission, and it didn’t. Due to the unusual flying location they lost the vehicle.
As it makes no sense to have a DO_LAND_START without having RTL_AUTOLAND set, I decided to add an arming check. If you have a DO_LAND_START in your mission (which you do in yours) then it will fail to arm with the message “DO_LAND_START set and RTL_AUTOLAND disabled”
To fix it either remove the DO_LAND_START, or if you really want it for some reason then disable mission checks in ARMING_CHECK.
Thanks @tridge. This then might be an issue. I didn’t explicitly add the DO_LAND_START, I just used the UI to drop on takeoff and landing waypoints as I have been doing recently during all my auto takeoff/landing experiments.
The QGC documentation states that when a Fixed Wing Landing is added this happens:
This pattern creates three mission items:
* `DO_LAND_START` - If you abort a landing it sends `DO_GO_AROUND` to the vehicle, which then causes the mission to return to this point and try to land again.
* `NAV_LOITER_TO_ALT` - Start point for landing
* `NAV_LAND` - End point for landing
So all landings created by QGC will have a DO_LAND_START, but would not necessarily want RTL_AUTOLAND. This also explains why you might want DO_LAND_START without RTL_AUTOLAND - so you can do a DO_GO_AROUND.
Perhaps its off topic - but how can I see the waypoints from the log? Ideally using MAVExplorer.