Plane 4.1.0 beta

ArduPlane Plane 4.1
83

Really great job!
After autotune (arduplane 4.1.0 beta5) on my 6kg quatplane tiltrotor 2+2 plane fly well.

Only one strange thing happen - with q_options = 1 (level transition) plane started transition on the ground.

video: https://drive.google.com/file/d/1zwTgAVmcoTuouvZ8ArGksXf7apDma-aE/view?usp=sharing

logs: https://drive.google.com/drive/folders/1PWJmnf4hnUIQ2nufOcb_ikoua2BGUGfB?usp=sharing

84

Just flew and did a couple of autotunes with beta5.

Logs (Chronological):
Flight 0 (old, 4.0.9, pitch instabilty during transition)
Flight 1 (Autotune level 7 in 4.1.0Beta5)
Static Test 1 (4.1.0Beta5, wandering of AETR.SS on the ground)
Flight 2 (Autotune Level 0 and yaw tuning in 4.1.0Beta5)
Flight 3 (Yaw instability on transition to forward flight, some transmitter tuning.)
Flight 4 (Yaw instability during transition to forward flight, flight cut short by rain)

A couple notes:

  • The RLL_RATE_FF from autotune seems to depend on RLL2SRV_RMAX. Autotune in Flight 1 with RMAX = 90 resulted in ~0.38 for RLL_RATE_FF (and autotune level 7), Autotune in Flight 2 with RMAX = 120 (and Autotune level 0) resulted in 0.44. It’s my understanding that the intent of RLL_RATE_FF is to be a constant that multiplies the desired roll rate, and so its value should not depend on the desired roll rate.
  • I suspect there’s something wrong with how speed scaling for control surfaces is done, especially at low speeds. This results in too much gain at low speeds.
    • Static Test 1 shows large fluctuation in AETR.SS and corresponding aggressive elevator movements.
    • Flight 0 shows pitch oscillation during transition to forward flight, but once at speed, the aircraft flies well.
    • In Flight 2, I go through the manual yaw tuning procedure and stop short of reaching the point of oscillation due to battery constraints. I intend to resume tuning in the next flight. In Flight 3, the transition to forward flight included significant yaw oscillations induced by full scale oscillations of the rudder and partially counteracted by the quad motors. Once flying at speed, yaw was fine, but I reduced YAW2SRV_DAMP substantially anyway for safety and it was significantly better, but no perfect for the transition to forward flight in Flight 4.
    • In all flights, when in Q modes (and at very low/zero airspeed), the control surfaces are commanded to make impulse-like movements. This seems to correlate with sudden changes in AETR.SS. In particular, see the ailerons during the landing of Flight 4.
    • PIDP.DMOD is active (value other than one) during takeoff and landing transition of (at least) Flight 3 and Flight 4, but is inactive once flying at speed.
85

Speed scalar can be a little odd at low speeds. I ended up graphing it to help understand what what happening. For this plot ARSPD_FBW_MAX is 50 m/s and ARSPD_FBW_MIN is 20 m/s.

image
image1202×902 81.7 KB

The code for the speed scalar is here if you want to take a look at the math.

86

Hi i just come across on orange cube with here2 on the UAVCAN on beta 4.1.0/5
as soon as it powers you led flashes green even if its radio failsafe and no satellite lock
as before it was flashing yellow till get went off failsafe and satellite lock
and before when it went into RTL and landed it always was flashing yellow now its green ?

87

@tridge
@Allister

Hoping you can answer some easy questions:

  1. Why is it that when THROTTLE_NUDGE = 0 and no airspeed sensor is used, throttle still moves around, as if it is trying to maintain a specific air or ground speed? Is the only possibility that it is trying to stay above ARSPD_FBW_MIN?

  2. When ardupilot firmware first boots up, does the plane have to be level? Is there some kind of IMU leveling that happens on boot?

  3. Several of the digital OSD (e.g. DJI Air unit) indicators don’t work/show up. Bearing and airspeed are some examples. I’m not using a compass or airspeed sensor, but (1.) I think ardupilot is estimating airspeed, so that should be shown, even if no airspeed sensor is present, (2.) even if no compass is present, GPS units still output a bearing, so that should be shown. Azimuth indicators don’t work as well, if I remember correctly. Are there plans to fix any of this?

88

you haven’t said what flight mode the Q is about. If this is AUTO then the throttle moves to maintain height.

no, but it does need to be not moving. It doesn’t matter what the orientation is as long as it is still until gyro cal is finished

you’re better off asking here:

but make sure you include your parameters, as without those we’re just guessing. Best to provide a log as that has parameters and firmware version.

3 Likes
89

@tridge
I was referring to automatic throttle modes, in particular Cruise mode. I’m assuming the reason is the same though, it’s increasing throttle to maintain height.

90

Yes, that’s correct. It’s using throttle along with elevator to maintain height as you turn.

91

@tridge @Allister

Question about terrain following:

The database is populated automatically by the autopilot requesting terrain data from the ground station over a MAVLink telemetry link. This can happen either during flight planning when the autopilot is connected over USB, or during flight when connected over a radio link.

I don’t want to rely on my MAVLink telemetry link to hopefully download terrain data in time, while flying. When planning a mission, using waypoints with altitudes relative to the ground at that point, I would like mission planner to automatically (or have a button that allows me to) upload any necessary terrain data to the FC SD card during the mission planning process. Can you provide more detail on how I can make sure that the FC has necessary terrain data, before starting the mission?

92

If you plan a mission and upload it via USB to the plane it should upload the terrain data. The other thing I’ve done is used the web utility at https://terrain.ardupilot.org/ to create a file with the data that I can directly load to my SD card. You can upload as much or little as you need and once it’s on the SD card you don’t need to worry about it.

https://ardupilot.org/plane/docs/common-terrain-following.html#sources-of-terrain-data

93

@Allister what happens if you’ve created a mission where all the waypoints are set to frame:terrain, but the terrain_follow parameter is set to 0? Seems like an odd contradiction. I set terrain_follow to 1, just to be safe, but was curious as to what happens when it’s set to zero.

94

To be honest I fly my fixed wing in a pretty flat part of the world so I haven’t tested this to the limit. But as I have seen it so far, when you plan a mission using the terrain reference mission planner will alter each waypoint to maintain the desired altitude above ground. So in that case each waypoint will rise and fall with the ground. You need to be careful with that if there is a high point between two waypoints as the mission won’t catch that. (That’s when Terrain Follow would kick in) In mission planner you can check the altitude of your flight path against the ground elevation data by using the map tools. I’m on the wrong computer to give you a screen shot but if you right click on the planning screen and look for map tools, you’ll see a choice for elevation check. (I can’t remember the exact name, but you’ll find it)

1 Like
95

@Allister @tridge If terrain_follow was set to 1, and I just finished planning and uploading a mission, how would I know if the flight controller actually has the necessary terrain data for the areas between each waypoint? (I don’t want to assume or hope that it will load it while flying.)

96

If you have a GCS connected or you use Yaapu telemetry you will get a very persistent warning that says “bad or no terrain data”.

97

@Allister That would happen while flying though, correct? There should be an easy way to validate that the FC has the necessary terrain data loaded that will cover the paths between each waypoint, before flying the mission, right?

98

That warning will start as soon as there is a GPS position lock. You’ll get it on the ground before you arm.

99

@Allister Thanks for the help. I flew two, 5+ mile missions today using terrain following. It results in much more interesting video vs higher altitude flights.

How do I get access to the calculated airspeed (when not using an airspeed sensor) when graphing data in https://plot.ardupilot.org/# ? ARSP.Airspeed is just flat (because I don’t have an airspeed sensor) but ardupilot is calculating airspeed, so how do I get access to it?

1 Like
100

the airspeed that ArduPilot uses in flight is in CTUN.As

2 Likes
101

Quick update on my own post:
Turned out that my airspeed sensor was not used. Even more impressing what AP is capable of.
Now Airspeed sensor is used.
Here is a new video: https://youtu.be/z8lU2ljBbPo
Logs: https://www.dropbox.com/s/oxoznoh4wmuky2x/21-08-25_19-11-18.bin?dl=0
Only challenge remains is the horizontal offset. Plane should hit the runway in the middle, offset is appr. 1.5m.
Any suggenstion?

Greetings
Guido

102

@tridge @Allister

I have a pretty spectacular crash I would love some help analyzing. I was doing the ~4th terrain following mission. I don’t think terrain following is to blame though. I have the log in the link below. I’m still working on editing and uploading the video of it. It contains clipped trees, undesirable barrel rolls, and a smoking motor.

Besides finding the primary cause of the crash, I was also wondering why didn’t crash detection work? AUTO mode just continued to try to fly forward until the motor caught fire…

For now, I just have the log. Key points:
10m 31s: A wild loss of control followed by last second recovery.
14m 20s: A wild loss of control followed by last second recovery.
17m 23s: A wild loss of control followed by a crash.
https://s3.amazonaws.com/realsentrygun.com/uploads/2021-08-27+15-46-36.bin

edit: video