Hi there, two flights in FBWA/Auto with a fixed-wing after upgrading from 4.4 to 4.5b2 on a CubeOrange → all good, seamless.
… a bit off-topic, but maybe someone can guide me to a more suitable category/existing discussion: log download via USB using MP (either per “Dataflash Logs” or MAVftp) is unbelievable slowish and speed drops with the percentage achieved (even to below 10 kb/s at 75% of the file). When using QGC, I achieved around 300kbps - any recommendations (besides a TF extension)?
you should be getting at least 500 kbytes/s on a CubeOrange in a normal setup with the “dataflash logs” download. Post your param file and I can try to reproduce
Great to hear - here it is: Problems occurred with a filesz above 60MB, connected via BaseBoard USB connector (jst-gh 6p, “standard” cable).
CubeOrange3_20240227_1454_450b2.param (18.3 KB)
Conducted further flight testing on 4.5.0 Beta2, Quadplane, Cube Orange. Tested Auto Takeoff/Landing, Guided, FWBA, Cruise, Auto, RTL VTOL Approach. No problems to report.
This issue is already noted here (MAVFTP: Check CRC after file upload · Issue #3308 · ArduPilot/MissionPlanner · GitHub), however I wanted to follow up here too. I encounter this CRC issue on beta2, but not on beta1. Beta1 seems to work as intended, but my Lua scripts that work fine in beta1 get corrupted when initially loading into the board/upon board bootup in beta2. It takes ~1-11 reboots before the scripts start behaving normally. They throw a different “syntax error” or “unexpected symbol error” every time they initially startup. I have tried running this on two different Pixhawk 6Xs with the same results.
Changes from 4.5.0-beta2
Please test!
Thank you for your great efforts!!
Thank you Andrew will try on my Vtol over the weekend and thank you
Can we read more about this?
the easiest is to go to https://custom.ardupilot.org and select the board then you can see it will auto-fill in the default features for this board, so you can see exactly what you will get
Yes, thank you, I am well aware of that. I was more concerned with “enable all FPV features” and it is unclear to me what exactly is meant by that.
Three Flights with CubeOrange 450b3 (AutoTO, short mission, RTL, FBWA, Scripts running) after upgrading from 450b2, no issues, all good.
DataflashLogDownload Speed over USB “resolved” by using LOG_DISARMED = 2
AFS/IOMCU: The IOMCU seems not to trigger FTS (MagicNumber 42, Elev Up etc.) when separating the cube from the Baseboard physically (CubeBlack & CubeOrange). Is that intentional? Direct manual control on MAIN OUT over RC IN (SBUS) also does not work. No Servo Signals/Movements.
I am excited to try out the new Quadplane features on a tiltrotor.
The new documentation states “Continuous tilt-rotor QuadPlanes will tilt motors up to TRIM_THROTTLE times Q_TILT_MAX to maintain position.” So if TRIM_THROTTLE is set to 50%, and Q_TILT_MAX=45deg, the maximum commanded tilt for maneuvering in position controlled mode would be 67.5deg? (assuming the motors tilt through a 90deg range)
This seems like a beneficial feature. I’ve previously found that with using Q_VFWD_GAIN, the aircraft could get into a bad situation if the position controller pitches the nose down and then tilts the motors all the way to Q_TILT_MAX (as it might on a windy day).
the IOMCU is inside the cube, not the baseboard. Baseboard is really just power and connectors.
You can test failure of cube main MCU using the OVERRIDE_CHAN parameter. Please read the docs for OVERRIDE_CHAN
please read the docs for Q_FWD_THR_USE for the new feature and how to enable it. It is a lot of fun flying with it enabled.
Hi, can you share me your Babyshark VTOL config param files to me?
Today I tested the new Forward Throttle function on two small VTOLS (Tritilt and pusher X-Quad). Note the horizon when hovering against the wind. On both small quad and small tiltrotor, it’s just great to be able to “hover” against the wind without a large, power-guzzling pitch angle. This makes manoeuvring into the wind to the landing site much more efficient.
Unfortunately, I forgot to test whether new Forward Throttle function can be switched off with the old parameter Q_VFWD_ALT ? A kind of “forward throttle alt cutoff” is definitely required for VTOLs with large propellers that could otherwise hit the ground.
I don’t like at all that the minimum forward transition ( Q_TRANSITION_MS ) has now been hardcoded at two seconds. This is more of a safety risk for VTOLs with high acceleration: in 2 seconds the small tritilt has already doubled the transition speed and continues to fly forwards at high speed for at least 1.5 seconds without the pilot having full control authority of the wing flight.
Apart from that, flights of 3 conventional aeroplanes with the beta-3 on were unproblematic.
Rolf
The new image I’m using for releases is from @steph280 - thanks!
