Rover-4.2.0-beta3 has been released for beta testing and can be installed using the ground station’s (MP’s, QGC’s) beta firmware link or it can be directly downloaded from firmware.ardupilot.org.
Changes vs -beta2 are in the release-notes and copied below.
Minor Enhancements
a) BATT_OPTIONS supports sending resting voltage (corrected for internal resistance) to the ground station
b) KakuteH7-bdshot support
c) MatekH743 uses a 32 bit timer to resolve occasional 68ms timing glitch
d) RC input protocol text message sent to GCS (helps pilot awareness during RC handover)
Bug fixes
a) Balance bot stands in acro mode even with no GPS
b) Battery remaining percentage fixed when using Sum battery
c) DShot reversal bug with IOMCU based boards (see SERVO_BLH_RVMASK)
d) DShot commands fixed (could cause random motor movements)
e) GPS blending fix that could have resulted in the wrong GPS being used for a short time
f) Param conversion bug (impacted airspeed enable)
g) RC handover between IOMCU RC input and a secondary RC input on a serial port fixed
h) QioTek Zealot H743 SLCAN port and relays fixed
Although we are only at -beta3, 4.2.0 is already looking quite stable and the next release will probably be a “release candidate”.
Hello,
with beta3 after a while I get an internal error 0x800.
It is a new rover using Matek H743-Mini and MatekH743-bdshot
I thought I try this beta3 to check, if BLHeli BDSHOT telemetry is working in the meantime… but no luck
Force arm. Altough tilting manually both in Manual and Acro, wheels turned correctly, it didn’t keep standing at all in both modes. Trying some parameters change (ATC_xx, BAL_xx) didn’t help.
Back to v4.00 stable. All was normal again.
Program v4.2 beta 3 again, just in case: no change.
I can’t remember exactly but I saw that message about pin 50 in the past, possibly with some version v4.1.x, but I didn’t try farther because of the problem in Acro.
Ok, so you’re saying that the balancebot doesn’t stand in any mode with 4.2.x?
If this is the case then I think there is some lower level issue perhaps with the brushed motor control because my balancebot definitely does work but it is using a PWM->brushed motor controller.
I confirm that the balance bot doesn’t stand in any mode with v4.2beta3 dated 20220330 (in adition message "Relay1 pin 50 invalid appears in MP hud and is heard), but the situation is different for previous v4.2betas.
I keep the .apj file for a v4.2beta dated 20220312. For it (test at home, no GPS lock (test on a different balance bot lower and with smaller wheels just in case (no change))):
in Acro wheels don’t obey to manual tilting, just as stables v4.1.x;
in Manual wheels movement obeys to hand manual tilting, but doesn’t stand at all, just as v4.2beta3;
message “Relay1 pin 50 invalid” appears in MP hud when arming and is heard.
In stable versions v4.1.x, Manual&Hold modes work, but in Acro wheels don’t obey to hand manual tilting, and left on ground it falls immediately.
Motors are DC with encoders. This is the controller (Pololu based on MAX14870, meant for Arduino (there is a similar one meant for Raspberry Pi)) and cabling (Pixhawk 6 AUXs, 2 MAINs):
Controller red/black thick (2): supply from 3S battery.
Controller yellow/green thick (2+2): to motors.
Controller white thin from AUXs (2, pins 50 and 51): M1DIR M2DIR.
Controller blue thin from MAIN’s (2): M1PWM M2PWM.
Pixhawk yellow/green on AUXs (4, pins 52 to 55): from encoders.
On all v4.1.x it worked on Manual and Hold, and on Acro wheels didn’t obey to hand manual tilting and it fell immediately when left on ground. No message “Relay1 pin 50 invalid”.
Perhaps the cause for message "Relay1 pin 50 invalid (appearing on v4.2betas, it seems to be coincident with apparently correct wheels movement with hand manual tilting in Manual or Acro, but falling immediately when left on ground) should be found and tested first. Parameters and configuration above have worked for years in v4.00 and previous.
Thanks for the report. I’ve added it to our 4.2 issues list and we do have a dshot fix coming in the next beta so if we are lucky this may resolve the issue.
That’s it! Like night and day; thanks a lot. Now v4.2beta3 works in Manual, Acro and Hold very well (I’ll try Auto shortly), with no more “Relay1 pin 50 invalid” messages.
BTW1, as far as I know FC common general purpose I/O pins can be:
Output:
PWM with servo timing (servos, conventional ESC’s…)
PWM duty cycle (DC motors)
On/off signals (direction control, relays…)
Input (encoders, rpm).
Bidirectional (bdshot)
but not every pin can be anything, IOMCU pins can have more restrictions, and signals may be grouped.
Somewhere describing how those pin functions relate to parameters would be convenient.
ACRO_TURN_RATE controls how the pilot’s input is converted to a desired turn rate in Acro mode. This parameter can be reduced to make turns in Acro mode more docile for the driver
ATC_STR_RAT_MAX is the maximum turn rate that the vehicle will ever attempt in any mode. This should normally be kept close to the vehicle’s performance limits so the vehicle remains agile
ACRO_TURN_RATE works in a balance bot in Acro, but in Manual I find steering always fast no matter how low I set ATC_STR_RAT_MAX. What can I try?
On a simple encoders test at home, I cannot see WENC messages at all on a .bin file.
Examining what happened in v4.00 this is obtained from a .bin file one day before (balance bot going back and forth in Auto):
It looks like we don’t have a -bdshot version for the MatekF765-wing (see here) and it is not listged as one of the boards that support it using the default firmware (see list here on the wiki)
@andyp1per should we add a -bdshot version for this board?
