Copter-4.5.0 released!

xfacta · April 9, 2024, 12:13am

Hi Randy,
I dont think it’s really an issue with 4.5.0, probably that 4.5.0 boots up quicker to the CAN interrogation stage, or just luck that it worked ok in an earlier version.
Maybe we could more generally recommend BRD_BOOT_DELAY,3000 when CAN devices are involved.
There is no down-side to having it set.

tridge · April 9, 2024, 12:54am

this could be related to the different behaviour of Pixhawk6C and 6X vs CubeOrange with regards to when power is enabled to the various peripheral buses
this function:

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_HAL_ChibiOS/hwdef/common/stm32_util.c#L299


      
              (void)v;
              (void)n;
          }
          #endif // AP_FASTBOOT_ENABLED
          
          /*
            enable peripheral power if needed This is done late to prevent
            problems with CTS causing SiK radios to stay in the bootloader. A
            SiK radio will stay in the bootloader if CTS is held to GND on boot
          */
          void peripheral_power_enable(void)
          {
          #if defined(HAL_GPIO_PIN_nVDD_5V_PERIPH_EN) || defined(HAL_GPIO_PIN_VDD_5V_PERIPH_EN) || defined(HAL_GPIO_PIN_nVDD_5V_HIPOWER_EN) || defined(HAL_GPIO_PIN_VDD_3V3_SENSORS_EN)|| defined(HAL_GPIO_PIN_VDD_3V3_SENSORS2_EN) || defined(HAL_GPIO_PIN_VDD_3V3_SENSORS3_EN) || defined(HAL_GPIO_PIN_VDD_3V3_SENSORS4_EN) || defined(HAL_GPIO_PIN_nVDD_3V3_SD_CARD_EN) || defined(HAL_GPIO_PIN_VDD_3V3_SD_CARD_EN) || defined(HAL_GPIO_PIN_VDD_3V5_LTE_EN)
              // we don't know what state the bootloader had the CTS pin in, so
              // wait here with it pulled up from the PAL table for enough time
              // for the radio to be definately powered down
              uint8_t i;
              for (i=0; i<100; i++) {
                  // use a loop as this may be a 16 bit timer
                  chThdSleep(chTimeMS2I(1));
              }

we could change these:

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_HAL_ChibiOS/hwdef/Pixhawk6X/hwdef.dat#L233


      
          # power enable pins
          PC13 VDD_3V3_SD_CARD_EN OUTPUT HIGH
          PI11 VDD_3V3_SENSORS1_EN OUTPUT HIGH
          PF4  VDD_3V3_SENSORS2_EN OUTPUT HIGH
          PE7  VDD_3V3_SENSORS3_EN OUTPUT HIGH
          PG8  VDD_3V3_SENSORS4_EN OUTPUT HIGH
          
          # start peripheral power off, then enable after init
          # this prevents a problem with radios that use RTS for
          # bootloader hold
          PG10 nVDD_5V_HIPOWER_EN OUTPUT HIGH
          PG4  nVDD_5V_PERIPH_EN  OUTPUT HIGH
          
          # Control of Spektrum power pin
          PH2 SPEKTRUM_PWR OUTPUT HIGH GPIO(73)
          define HAL_GPIO_SPEKTRUM_PWR 73
          
          # Spektrum Power is Active High
          define HAL_SPEKTRUM_PWR_ENABLED 1
          
          # power sensing

timtuxworth · April 9, 2024, 1:13am

Could this be related? I am trying to set up MNT1_DFLT_MODE = Sysid Target (5), with 4.5.1 on a CubeRed with a SiYI A8 Mini. I’m sure I had it working before on one of the 4.5.0 beta versions, but now the gimbal won’t track the MNT1_SYSID_DFLT vehicle.

rmackay9 · April 9, 2024, 2:06am

Hi @timtuxworth,

There haven’t been many changes in the mount library during the beta period but if you’ve got a log I can have a look. The most common issue I’ve seen with tracking a position is that the EKF doesn’t have a good position estimate. Before there is a good position estimate, there’s no warning that the mount can’t track a point, it simply refuses to move. I have considered adding a warning when the user puts the mount into a mode requiring GPS so that it spits out a warning that it can’t move yet.

timtuxworth · April 9, 2024, 2:07am

I’ll try again and try to get logs on both vehicles. Thanks Randy.

rmackay9 · April 9, 2024, 3:50am

Hi @timtuxworth,

Thinking about this more, the issue you’re seeing where the gimbal is not tracking the sysid could be related to the Mount’s RC_TARGETING change because it could be seeing RC input changes at startup and changing the mount to RC_TARGETING mode essentially immediately overwriting the default mode setting.

I was going to suggest that you use MP’s Action tab to change the mount’s mode to SYSID directly and if it starts moving then you know it was not in SYSID mode but sadly MP’s drop-down doesn’t have SYSID. Maybe you could raise a mission planner issue to add this to the drop-down?

timtuxworth · April 9, 2024, 2:25pm

Thanks Randy sounds like something I can try on the bench. I’ll give it a go. Could you point me to where I can find this in the code? I can try putting some debug messages in there just to figure out what is happening.

rmackay9 · April 10, 2024, 12:12am

Hi @timtuxworth,

To debug this it might be good to stick messages in these functions:

I think we probably need to add an last_rc_input.initialised boolean to the class and then use it to set the last_rc_input.roll_in, etc the first time we get rc input.

I’m about 90% sure that you’ve found a bug. thanks for that!

EDIT: do you want me to raise a PR to add this boolean and init? I suspect you could do it yourself but no pressure either way.

timtuxworth · April 10, 2024, 12:14am

Hi Randy - you were onto something. RC was basically overriding the default as soon as it came up. So it was a bit random depending on whether the RC came up first or the camera came up first. Here’s my PR that fixes it. I didn’t think of a boolean, so did this before I saw your comment. I could change it if you prefer.

github.com/ArduPilot/ardupilot

AP_Mount: Do not override default mode when first connecting to RC

ArduPilot:master ← timtuxworth:pr-mount-sysid

opened 12:12AM - 10 Apr 24 UTC

timtuxworth

+17 -2

When the AP boots it sets the gimbal mount mode from MNTx_DEFLT_MODE, but if the…re are also RC channels for roll, pitch, yaw on the mount, when the RC connects it will immediately override the default because the RC values "changed" (from nothing to whatever is coming from RC). This fix ignores the initial change from "nothing" to initial RC values so it will only override the gimbal targeting mode if the pilot actually changes the relevant RC channels.

rmackay9 · April 10, 2024, 10:38am

@Prof_Leandro @xfacta,

Re the Hereflow startup issue and the need for the BRD_BOOT_DELAY=3000, we’ve reproduced the problem and we’ve got a fix here.

This needs to be peer reviewed but hopefully it will be included in the next beta (4.5.2-beta1). Thanks again for the report and special thanks to @xfacta for finding the work around which led to the fix.

Dimitris_Stefanakis · April 11, 2024, 10:55am

Dear @rmackay9
With 4.5.1 loaded and with a SIYI A8 Tested, all controlls seam to work with all the aux functions tested. But i cant find any messages in telemetry even with Mavlink inspector for CAMERA_FOV_STATUS

Only gimball information with angular velocities.

In previews itterations, we used your Script mount-poi.lua to extract the crossing coordinates that camera looks. But given that now is included in the mavlink stream, we can easily forward these messages.

Is the above statement true? Do we still need to upload the applet Lua?? Do we need to wait for GCS’s to be updated to consume these messages?

Thanks,
Dimitris

Aki_Kalantri · April 11, 2024, 8:37pm

Hello @rmackay9 i wanted to reach out to see if you had a chance to test the S1 rplidar sensor ? Support is appreciated with this ! Thank you

rmackay9 · April 12, 2024, 5:17am

Hi @Aki_Kalantri,

I have not tested the S1 but hopefully within a week or so after my main sponsor sends me their S1 testing unit. By the way, this Rover user has been using it successfully.

rmackay9 · April 12, 2024, 6:59am

@Andre_Freitas,

We found a slight issue in the RC_TARGETING change which is fixed by this PR that will be included in 4.5.2-beta1 in about a week. It’s not completely clear to me how it could be related but maybe.

alex78 · April 12, 2024, 12:08pm

Hi, thanks for this update. I have a strange behavior with it : As soon as I bank it for more than 90 degrees I have an internal error 0x100000 followed by this message : Internal errors 0x100000 l:57 flow_of_ctrl. Can reproduce it every time. AHRS orientation is Pitch90 and accels have been calibrated after AHRS orientation parameter set.
Video : https://youtu.be/xF8-1ZPsL3A

rmackay9 · April 12, 2024, 11:45pm

Hi @alex78,

Thanks for the report. I’ve added this to our 4.5.x issues list so it won’t be forgotten.

This is the line in our landing detector code that is causing the internal error. At the risk of appearing to minimise the problem, I don’t think that it is actually that dangerous. This is not an error in AP’s attitude estimator or control libraries. This is a case that we think should not happen (but clearly it does) when the vehicle is trying to determine if it is flying or not.

It is a bug though and appears scary so we will fix it of course.

alex78 · April 13, 2024, 7:00am

Thanks for your reply. Maybe it is not a bug because in this particular case I do not use Arducopter under “normal” conditions… Here my FC is mounted in a Rocket nose and do not have any ESC nor motors attached. I just want it to record logs and stabilize the rocket with controlled fins. As there is no Vectored Rocket Ardupilot Branch for the moment (why not in the futur ) I used Copter and it should explain why this particular situation (model tilted more than 90 degrees with no lift) may never happens in real life with “true” copters.

rmackay9 · April 15, 2024, 12:59am

@alex78,

Thanks for the feedback. It’s definitely a bug so we will fix it and it’s good to have a way to reproduce it.

Re supporting rockets, we’ve talked about it in the past but the “dual use” nature of rockets means it is not area that many devs are comfortable getting involved in.

it.igor.s · April 15, 2024, 3:07pm

Hello, do you have some solution?
Maybe I could help you with tests?
I have speedybee f405 v4 and vtx rush tank solo 2.5.

andyp1per · April 15, 2024, 3:29pm

I have the VTX now, just need time to test …