Copter-4.1.0-beta3 has been release for beta testing

@XinChengGe,

Re Mission Planner evaporating, this is happening to me again although only in very specific situations. I must be running Copter-4.1.x on a Pixhawk1 connected to my main PC. If any of these things are changed it works OK. So for example I can connect fine from my laptop, or I can use 4.0.7 or I can use a CubeOrange and it’s fine.

I’m working with @meee1 to try and narrow down the issue but no luck so far.

Hope a GSoC project Is not wasted only for backward compatibility while there is a ton of new stuff to explore and implement.

HI,I have the latest beta mission planner and still cannot get the params to download,done every thing asked on this thread,hopefully there will be a fix soon
and thank you every one for your inputs

1 Like

@MartyMcFly, can you tell me which autopilot you’re using? The PC is Windows10?

1 Like

Im using the Cube Orange and a windows 10 and the latest firmware in the EFD mod and air unit,just to let you no the cube orange connects very fast by usb cable and thank you for your time

Had a fall from the sky when switched from STAB to AltHold.
For the first look the reason was the Desired Climb Rate got sharp negative value right after switch to AltHold.
But what caused DCrt to be negative?

Unfortunately this is BeastF7 board with small internal mem chip so have to disable some standard log parames.
I’m using GSF (GPS with no compass).

Here is the log 13 1-1-1970 2-00-01 AM.bin (924.1 KB)
And the onboard video https://www.youtube.com/watch?v=83pDvm_Qnkk

@rmackay9 could you please take a look?

Pretty sure part of the problem is your throttle is at 20% when you switch - for AltHold the throttle needs to be at 50% to hover and so the copter will try and descend. You get the opposite effect if you switch from AltHold to stab.

My throttle (RCIN C3) was exactly 50% at moment of switch to AltHold, it is on my screenshot.
What you noticed (on OSD) is throttle hover

Recently I had another strange experience where I am not sure if it was an issue with the EKF3 implementation in beta3 or a defective Cube Orange. You can find the detailed description here: EKF3 Position going mad - Bug in 4.1.0-beta3 or defective Cube Orange?

@rmackay9
Yes, you are right, I try to reproduce the situation. I switch to a new autopilot, and connect two telemetries and USB It’s not evaporating anymore… :cold_sweat:

Hi, first thanks all devs for a great work.
Is it only me or do we have an issue in beta3 or latest stable QGroundControl?
If I revert settings to default I won’t be able to fully communicate with the APM afterwards. Have a Matek405-CTR, tested Beta3, bdshot Beta3 and latest.
It seems that EKF3 never gets out of startup and I’m not allowed to change any parameters in this phase. Most options in “Vehicle Setup” is missing only Summary, Firmware and Parameters are visible. Parameters can be read but not written.

To get it operational I have to revert to 4.0.7 and then update from that. Might be me or my FC that have created the problem.

Yea im experiencing the same symptoms hopefully sorted soon the dev’s do A good job

@lebarsfa
well…I don’t think we are facing same situation, in my case, after click connect button and start getting parameters, I can see checking for Param MAVFTP, then the MP evaporating immediately, It happened every time, same situation.

I confirm I have the same behavior, but it does not happen all the time depending on the parameters set in the Pixhawk, and potentially other things…

1 Like

I am not sure if it is related,but when I was messing about on the bench my cube orange reset it self im certain I did nothing to make this happen ,the plot widens

@lebarsfa, @MartyMcFly, @XinChengGe,

Thanks for the reports. I’ve passed this onto @meee1. MichaelO is struggling to reproduce it which is slowing the ability to get it fixed.

2 Likes

@Patrik_Emilsson,

Thanks for the report. This definitely sounds like a QGC bug. I’ve added it to the list and perhaps we can reproduce it and report it to the QGC people it seems unlikely to be an autopilot issue. Important of course… but… seems like a ground station issue.

if anyone with the disappearing problem can run mission planner under the debugger that would help.

Hi @sergbokh,

Sorry for not seeing this post earlier. The log is difficult to analyse because there is so little information in it but still, the desired climb rate is suspicious.

The vehicle is falling at 2.7m/s at the moment it switches from Stabilize to AltHold and because PILOT_ACCEL_Z = 250 it will take it more than 1 second to recover back to a zero desired climb rate… it is slightly odd though that the desired climb falls to 3.2m/s.

I’ve added this to the 4.1 list of issues to be investigated and I’ll see if I can reproduce the issue in SITL.

Thanks Randy,
At time I did the flight I didn’t noticed the “EK3 Core 0 unhealthy” message. But as per log it fired before arm.
Could this bring some affect for the case?

Generally, how pilot should react on “EK3 Core 0 unhealthy” message if he not yet armed (suppose there are single EKF core)?