Correction: while Ardupilot requires ESC index shifting for UAVCAN ESCs due to 0 indexing on the UAVCAN side, the actuators (servos) do not require it. I mixed up the two when writing, my apologies.
I assume you mean RCMAP and the ordering between TX modules? That certainly is an issue, and the user needs to be careful to use receivers with the same channel ordering.
The decoder locks onto one of them and only goes looking for the other receiver if the first one stops giving data.
The feature certainly could be better. I actually added it as the PH4-mini needs both serial and pulse input on separate pins to match the plug labels, but I thought I should enable it for all boards as there are some good use cases.
Yes. And also the min and max for each channel. One has to be careful when mixing TXs
Today I updated a motorglider ASW-28 to 4.0.0beta1 (F405-Wing,M8N-GPS,external Compass,Frsky-Telemetry,WiFi-Telemtry). All works fine (Manual, FBWA, Cruise). Thanks to Tridge and everyone else involved in the development.
Thanks for the details, and of course for the tip to order the DPC-CAN programmer.
I hope it is in the ArduPlane roadmap to implement servo telemetry and maybe also the actuator ID assignment?
I’ve now released plane 4.0.0beta2.
A small set of improvements over beta1:
- Added autoranging to current and voltage in OSD
- fixed issue with motors spinning up in quadplane landing when below min lidar range
- fixed empty pre-arm warning string in EKF
- added code to cope with SCHED_LOOP_RATE being above max achievable rate
- fixed delay on oneshot125 channels which was limiting loop rate
- fixed use of uninitialised variable in mag fusion in EKF3
Today flying with 4.0.0beta1 and full automission with candy drop was working nice
Is it possible to test crow mixing? What are right settings for that?
I’ve been reading throught present topic about some config parameters have been renamed.
Can we asume that importing configuration params from a 3.9.10 setup could be a bad idea ?
Thanks in advance.
The best approach is to upgrade the firmware in-place, so that the automatic parameter conversion takes place. So load 3.9.11, load your old parameters, then load 4.0.0beta2 and during boot it will automatically convert your parameters.
We had 6 successful flights yesterday on beta2, and we would appreciate a quick glance at a log. I’m finding an error message of “invalid channel option (2)” on the logs. BlHeli ESC RPM is still reporting positive when reverse thrust is enabled. Stall prevention works well. I also think that Batt2 (supposed to be BLHeli by configuration) is not actually using the sum of the ESC currents because it matches Batt1. Cube Blue with mini carrier board, Here2 CAN, BlHeli ESC’s. https://we.tl/t-tUUN1tO1MU
The log shows you have RC1_OPTION=2. It is lucky that this is an invalid option, as option 2 is “flip” (for copters). Having that on channel 1 would make for some interesting flying!
I suspect your parameters became corrupt somehow. I suggest you check through them.
For example, you have RC8_OPTION=68. Is that deliberate?
uneventfull flights on plane4 beta, no difference to be expected compared to master though. that’s great!
@tridge while tinkering i ran into an issue with BLH_AUTO set to 1, using non-mulitrotor motors and BLH telemetry set active. it puts my board into an infinite watchdog reboot loop until i disconnect the telemetry wire or set motor mask manually.
as far as i understand the code, motor mask gets multirotor motors only, not throttle (left/right) on traditional fixed wing setups. i’m not sure this is intentional. if so, imho it should be documented or fixed to include SERVO_FUNCTION 70 , 73 and 74 too.
can you send me tlog or onboard log showing this?
BLH_AUTO_WDG_REBOOTS.zip (357.2 KB)
hope there’s something useful in there as the board won’t boot to runtime with repective settings active.
plus i stand corrected: BLH_AUTO param description refers to multirotor motors only indeed. intuitively i‘d suggest to have motor mask check for k_throttle(left/right) on plane / qplane builds too, but it‘s beyond my scope to tell if that causes problems in other places motor mask is used. however, setting BLH_AUTO to 1 without having multirotor motors specified shouldn‘t trigger wdg to kick in imho. on a sidenote, this only happens with the esc tlmtry wire connected and the esc powered, that‘s why i assumed it‘s rather related to esc tlmtry handling than a genuine motor mask issue.
thanks for looking into this!
did some more testing with debug enabled and it seems there‘s two issues:
1.: BLH_AUTO motor mask handling seems to not only check for multirotor motors defined in SERVOn_FUNCTION, but also if they‘re actually connected, powered and initialized. num_motors and motor_mask returns 0 otherwise.
2.: serial manager is unhappy with BLH_AUTO enabled && BLH telemetry active but motor_mask returning 0, this is what triggers resets. this likely happens whenever a trad fixed wing motor is used with BLH ESC but not pointed at using additional BLH_MASK bitmap while BLH_AUTO = 1.
i tried adding a check in serial manager for num_motors != 0 and it successfully prevents triggering wdg resets. not sure if it‘s a good approach worth PRing though…
Where is altitude parametr for support landing gear control based on altitude?
They are LGR_DEPLOY_ALT and LGR_RETRACT_ALT
which flight controller are you using? Landing gear support isn’t in some boards with a small flash size
I notice they are not available on a Kakute F7 board. So 1Mb of flash must not do it?