very nice feature added. Personalization should be increased in the on board OSD.
support for additional RC input on any UART
How does that work wrt parameters for? AFAICS both RCs will share the parameters configuration, right?
Also, is the idea that this second RC will be off most of the time to not interfere with the main one?
Is the implementation of precision landing for quadplanes planned for this version?
I talked with the HiTech guys at Intergeo yesterday and they showed me their range of UAVCAN servos. Do you have any experience with them? They claim to have Ardupilot compatibility, but I do not even see how the different actuator functions (servo mapping) should be handled. I would be glad to test, and give feedback.
@vbnhu I have been working with them for a while now. The servos are fully functional with current ArduPilot releases, though I will say development seems to still be active.
The servo mapping is simply taking the effective PWM output channel, shifting by -1 (UAVCAN Actuator ID 0 corresponds to Servo Channel 1) and sending a scaled unitless command packed in a UAVCAN actuator array command. This means that the actuator function (servo mapping) is handled through the normal channels. UAVCAN servos are currently just layered on top of the PWM channel outputs. There is a bitmask to enable UAVCAN outputs within the array command corresponding to particular PWM channels.
There is a programmer (DPC-CAN) from Hitec necessary for configuring their servos, setting up Actuator IDs and CAN IDs, limits, and telemetry settings. The servos do not fully implement some of UAVCAN’s amenities, like editing parameters via UAVCAN GUI or automatic node allocation. The programmer is necessary to overcome this limitation.
A current oddity is that all servos must have a CAN ID matching that of the autopilot (Node ID 10) as they only listen to commands from an identical ID.
Servo telemetry is implemented, mainly providing a 0-100% load indicator. This part in particular is still maturing. ArduPilot does not currently support servo telemetry, so the lack of a matured telemetry system does not have a very great effect yet.
2 Likes
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.
1 Like
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.
Cheers, Tridge
Yes. And also the min and max for each channel. One has to be careful when mixing TXs
Understood. Thanks.
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.
1 Like
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
Happy flying!
4 Likes
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?
Hi.
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.
Miguel.
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.
Tridge,
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…