Copter-4.4.0 released!

You are not supposed to update old 4.1.5 parameters into an newer firmware like 4.4.0

Updating the firmware automatically updates the parameters from the old firmware and changes them if necessary to preserve old behaviour. Just like you want and need.

Overriding that automation, by manually uploading old parameters, does not preserve old behaviour. This is somewhat counter intuitive, but it is the way it works.

It makes it easier to update firmware. You only need to upload 4.1.5 parameter file if you downgrade to 4.1.5 firmware.

Again, when updating there is no need to manually load any parameters, no need for any parameter upload.

When downgrading firmware version you must manually load a parameter backup file created with that specific version that you are downgrading to.

3 Likes

One other thing, use loiter instead of poshold. It it better in every aspect.

2 Likes

Amilcarlucas,I never new that loiter was better than POS hold,will start using Loiter from now,and thank you for this little bit of excellent knowledge,your a star

yes I agree, but I assume there are times when using a param file is required

  1. a new drone build on a new FW should be able to use 90% of the old param file
  2. if you reflash back to arduplane then back to copter, you would need to load a param file

for clarity here I had to manually adjust things that changed like this

“GPIO pins configured by setting SERVOx_FUNCTION to -1 (also see SERVO_GPIO_MASK. BRD_PWM_COUNT removed)”

I have tried both, pos hold is better for my use case.

Looking at the release notes

Copter 4.1.0-beta1 14-Apr-2021
Changes from 4.0.7
h) SCurves for waypoint navigation

Scurve introduced in 4.0.7 and I was on 4.1.5 so I was flying with Scurve and I was happy with it…

I wonder why then when I went from 4.1.5 to most currnet 4.4.0 does it now stop at each waypoint and not use Scurve?

Does it have anything to do with using survey grid mode? I wonder if it would use Scurve on a standard waypoint mission.

Seems like we know why the drone is sluggish in RTL but the curves between WP behavior is still a mystery.

@amilcarlucas I have done the following for testing today

  1. downgraded the FW to 4.1.5
  2. loaded on my known working param set. for that FW version
  3. upgraded the FW to 4.4.0
  4. I did not load my old params from 4.1.5
  5. adjusted required settings such as
    a)MOT_PWM min and max set to 1000 and 2000
    b) Servo 13-15 function set to -1

Nav_acc is still set to 100 (I have never changed this value on a copter) I will try 250 today as well.

I can’t imagine this changing anything but it’s worth a shot.

After this I will go back to 4.1.5 and see if it still stops at the waypoints in survey. If it does not then I have to move forward in versions one at a time until the compass UAVCAN issues are resolved but does not to the stop and go at waypoints…

UPDATE
I rolled back to 4.1.5 and it flies as it should through the corners and RTL behaves properly now as expected.

My compass issues I had with that drone seem to have gone away magically…

The reason I updated was because every few times this drone was flown if you clicked “setup” then “manditory hardware / compass” it would say the compass changed and then it would toilet bowl, I assume it was using the internal compass. I tried delaying the boot so that the compass could be found etc but it did not help.

Now after many power offs and on (waiting 15 min between) it seems to have stopped losing it’s compass.

So in light of the new RTL sluggishness and not being able to get scurve working on 4.4.0 I will be sticking with 4.1.5 (unless the compass issue rears its head tomorrow)

Hi @rmackay9

Will there be a chapter dedicated to FC with ESP32 in the official wiki? It would be interesting to have “easy” documentation to do some experiments.

Thank you

1 Like

@Alberto_Ds,

I’ve never used the ESP32 myself so I don’t think I could come up with the but I’ve created a wiki to-do item and perhaps someone who is more familiar with the setup will fill out this page.

FYI @DavidBuzz

1 Like

OK my stopping at waypoint problem solved… sort of…

I had the issue that updating from 4.1.5 to 4.4.0 the drone was stopping at the waypoints during the mission.

I set WPNAV_ACCEL to 250 and yes now it does not “stop”… however it would still not fly in an arc. Rather it would hit the waypoint and crank the yaw then head to the next WP.

This was not the behavior I was used to being that the drone used to fly a nice curve between the waypoints, also at 250 for the ACCEL it is VERY agressive. As in it would really pitch forward to get up to speed. This is NOT good for survey missions. To maintain good survey GPS you don’t want crazy jerking movements.

Still I had no curve in my path. So I noticed a param that was not in existance before and that was WPNAV_ACCEL_C this is listed as max acceleration in corners and that if set to zero it will use your max bank angle. Well my max bank angle is set relatively low to keep the above mentioned smooth flight as well as keep users from doing crazy maneuvers.

My WPNAV_ACC_C was set to zero. I set it to 500 (slowly increasing in trials) and the drone now flies in and arc between the waypoints like it used to. Kinda. It is still very agressive and would randomly pitch in hard jerking motions (never did this before)

So I dialed back the WPNAV_ACCEL to 100 and this is now where I want it… However it makes the drone impossible to move when in RTL move… dangerously so. I landed on 200 as a “happy” but not really happy medium.

I also reduced the JERK_XY (sorry not sure the correct param name) from 5 down to 3 and this helped with the sudden movements in the air in AUTO mode.

Long story short. Can we PLEASE have the ability to change the “behaviour introduced in 4.3 and the top speed is 0.5 x WPNAV_ACCEL” to 1.0 or whatever it was before?

Hope this helps others that may have found these issues.

1 Like

Update on this issue. I rolled everything back, flashed arduplane to clear the FW completely.

FYI I always get the firmware by downloading it from the web onto my hard drive. Then I select that file when I upload.

It seems if you select update firmware then select load custom firmware it complains as I describe above.

If you select legacy firmware then load from there it did not complain at all!

It did not even make me change my MOT_PWM min and max values? they are still set to zero and the the drone is not complaining… so are all the servo outputs… set to 0 and not -1 like I had to before.

Obviously I should use the legacy FW tab but my brain was thinking “why use the legacy one when I just downloaded the latest FW to my hard drive.” So obviously I am missing something here.

At any rate it’s all good now.

Thanks for your response.

2 Likes

this is my issue
Got COMMAND_ACK: VIDEO_START_CAPTURE: FAILED
Got COMMAND_ACK: VIDEO_STOP_CAPTURE: FAILED could you please give me solution

@rmackay9 already gyve you a solution on github.com. Did you tested it?

Hi! Since upgrading to 4.4.0 stable I am getting “PreArm: Rangefinder 1: No Data” error in two independent but equal quads which did not have this issue when running 4.3.7. The rangefinder shows good measurement values and I cannot see any problem in mission planner rangefinder data , however in the OSD I can see that for a split second the values of the rangefinder go blank and then return which sometimes does not allow me to arm. This happens frequently along the flight.

Log: 48.41 MB file on MEGA

@Andre_Freitas,

Txs for the report and log. I had a peek and indeed the rangefinder is going into the “No Data” state a lot which means that, for whatever reason, the vehicle code is not receiving distances updates for over 0.2 seconds.

This is a Benewake TFMiniPlus I2C rangefinder and the autopilot is a KakuteH7.

I ran the log through our new HardwareReport tool and the CPU load and memory looks OK to me.

I wonder if you also have a log from older firmware for comparison? Having an older log should make it quite obvious if this is a new or old problem.

You haven’t connected any other new devices on the I2C port?

We have not changed this driver at between 4.3 and 4.4 so if there is a difference in behaviour it’s not directly from the driver. One guess is that it could be because we reduced the DMA usage for I2C on this board (see PR here).

FYI @andyp1per

Hi @rmackay9
Thanks for your attention. I have a log of a flight with 4.3.7 stable

Log: 32.05 MB file on MEGA

I did not make any changes to the quad other than updating the firmware and new PID tune. Both my quads that are the same presented this problem. At first I thought it might be a bad wire connection but when it happened on the second quad I started to think it should be something in the firmware but I cannot find the reason. Hope you can!

@Andre_Freitas,

OK, so this one shows the rangefinder is always “good” or “out-of-range-high” which are more expected values. I’ll bring this up with the other devs.

1 Like

@rmackay9

Ok! Meanwhile, if you need more info let me know. Thanks for your attention.

Good day all, I updated from an older FW (4.1.5) where the cornering in a survey mission was much better than the cornering in 4.4.0

What used to happen is the drone would slow down and take a nice arc around the corner.

Now what happens is if I have WPNAV_ACCEL_C set to 250 (or 0 to use max bank angle) the drone does not go through a nice arc, It almost comes to a complete stop and then yaws.

The only way I can get the drone to have a nice transition with an arc is to put WPNAV_ACCEL_C up to 400 in which case it flies way to fast through the corner but makes a nice arc.

On FW 4.1.5 it would combine yaw with a bank and go around the corner nicely.

This fast cornering causes blurred photos, and bad GPS survey data.

It was perfect before… How to get attain the same flight behavior as version 4.1.5?

1 Like

Try increasing WPNAV_RADIUS.

that is set to the maximum and makes no difference, thank you though.