Plane 4.0 release

I’d just tryed all flight modes: fbwb, loiter, cruise, guided, auto and tkoff (dev firmware)
Everything works nice and smooth.
Until my wing was crashed
There’s a sequence of crash…
Had a tip stall in fbwa mode because a slow turn.
Fortunately it was recovered in rtl mode.
Just after recovery I’d switched to auto mode and had a stall again because auto mode made a tight turn but at that moment the speed was pretty low just after recovery. Nothing serious but shit happens :slight_smile:

Was STALL_PREVENTION turned on?

There’s no airspeed sensor on the wing

I have a Pixracer R15 from mRobotics
In order to flash arduplane 4.0.3 do I need to do something special or is it Ok if I I do it from mission planner ?

Alcala

Ps : i posted same request in another post but I believe it is more appropriate to do it here

You can flash directly from MissionPlanner

I finally had the chance to test-fly 4.0.3 stable yesterday, and I had a very successful flight. Upon analysis of the logs, I’m not sure I undertand what is driving a roll demand oscillation in the middle of an automatic mission. See the screenshot (red line indication) and attached log below.


https://1drv.ms/u/s!AunBK4rE1ZDCgedfzY8urJ0vpdPvXA?e=v0yTeF

it is navigation indecision. The plane was flying south and the next waypoint was to north. It flipped between turning right and left a couple of times. We do have code to prevent this type of indecision but it isn’t perfect, and sometimes we get temporary indecision depending on the yaw rate of the aircraft at the time.

Just tryed fully autonomous flight (no rc control) and it was fully successful!
Much better when I’d try to do a smooth manual landing last time.

1 Like


I’ve just released plane 4.0.4beta1. This release includes a significant number of changes from 4.0.3. Key changes are:

  • re-sync the 4.0 release with Copter-4.0, bringing them in line so as to maximise cross-vehicle testing
  • fixed a timing issue in IOMCU that could lead to loss of RC input frames and increased latency of output to ESCs on the IOMCU
  • fixed a bug in restoring gains in QAUTOTUNE that could cause the aircraft to be unstable on leaving QAUTOTUNE mode

The Copter-4.0 re-sync brings in quite a few structural changes. The main user visible changes are:

  • UAVCAN DNA server no longer needs a microSD card to operate
  • added logging of UAVCAN servos and ESC feedback messages
  • reduced QTUN logging rate to 25Hz
  • reduced memory usage in EKF with multiple lanes
  • Minor OSD improvements
  • added a lot more scripting bindings
  • fixed UAVCAN GPS status when not connected
  • added EK3_MAG_EF_LIM limit for earth frame mag errors
  • added MAVLink FTP support
  • added support for WS2812 LEDs

Due to the significant number of changes with the re-sync I would particularly appreciate as much flight testing as we can get on this release.

Happy flying!

2 Likes

I am trying to have camera triggering happen on the ground before flying, and now I’m having no luck. It was working a few days ago, and I don’t recall having issues with previous firmwares but now something is different. I believe the logs indicate that the trigger message is not getting through as I can’t find any TRIG events. RC6_Option = 9, and that has worked in the past. Trigger camera now from mission planner is also not working. Log at the following link. https://1drv.ms/u/s!AunBK4rE1ZDCged5m_r3Z2tkNfI0GQ?e=JlXe8S

just a reminder that I’d love to see logs from the 4.0.4beta release. I can’t do the release till I have sufficient logs to be confident everything is OK

Do you need logs from any particular flight controller?

any flight controller is fine

1 Like

Would love to do some test flights but there ist very strong wind in Europe since Sunday, impossible to fly anything :smiley:

Everything ok, log file: https://www.magentacloud.de/share/a.sfxqu9vh

Rolf

1 Like

fantastic, thanks Rolf!

If the log of the same aircraft is still of interest in a short flight in windy conditions:
2020-02-15 10-48-33.bin Folder: https://www.magentacloud.de/share/a.sfxqu9vh

1 Like


I’ve just released plane 4.0.4 stable. This release includes a significant number of changes from 4.0.3. Key changes are:

  • re-sync the 4.0 release with Copter-4.0, bringing them in line so
    as to maximise cross-vehicle testing
  • fixed a timing issue in IOMCU that could lead to loss of RC input
    frames and increased latency of output to ESCs on the IOMCU
  • fixed a bug in restoring gains in QAUTOTUNE that could cause the aircraft to be unstable on leaving QAUTOTUNE mode
  • fixed stack size of ftp thread

The Copter-4.0 re-sync brings in quite a few structural changes. The main user visible changes are:

  • UAVCAN DNA server no longer needs a microSD card to operate
  • added logging of UAVCAN servos and ESC feedback messages
  • reduced QTUN logging rate to 25Hz
  • reduced memory usage in EKF with multiple lanes
  • Minor OSD improvements
  • added a lot more scripting bindings
  • fixed UAVCAN GPS status when not connected
  • added EK3_MAG_EF_LIM limit for earth frame mag errors
  • added MAVLink FTP support
  • added support for WS2812 LEDs

Many thanks to those who tested the beta release, much appreciated.

Happy flying!

1 Like

Many thanks Tridge

I flew around 15 flights with Arduplane 4.03 (taranis X9D, R-XSR, pixracer, C&T passthrough telemetry).

I had severals “No RC receiver” (see my post) without any impact on the flights but quite stressfull

Do you think it could be link to the IOMCU ,

I will use this week 4.0.4 asap

Cheers

We had the same experience while we only had the R-XSR in really, so not even connected to the AP. Ergo Firmware could easily be eliminated.

After tracking down the issue to R-XSR. We replaced them with good old X8R and the problem went away. This was in multiple builds, not just one. So quite confident that the RX is the culprit.

Also we were using X10 (Horus) RC, not X9D as you were.

So it FrSky (R-XSR) internal issue. Maybe can be fixed with firmware, maybe not). The issue only happens if the s-port is enable with any telemetry pass-though. I guess that is why it has laid dormant for so long. Not many people used that s-port. They have been dropping the ball a lot since early last year. Hope they don’t end up like Nokia soon.

EDIT: Sorry, was not clear, we had the issue even before 4.0.4beta was out, so I don’t think it is related to the Firmware IOMCU.
Test your system with X8R or X4R-SB and see if you get the same issue.