Solo Gimbal no longer enabled on AC 4.2

[mtbsteve]

Bug report

With AC 4.2 and AC 4.1.5, the Solo Gimbal is not available anymore on CubeSolo. None of the mavlink command controls are working.
Everything was still fine with AC 4.0.5.

Scanning through the change log, it appears that the following commit may have been broken something :
f7f5880

Also, with the following commit the support for the Solo Gimbal was then limited to CubeGreen:
f3bf6e5

I understand the need to save memory, but at least the Solo Gimbal should be enabled on the original CubeSolo (which typically comes with a Solo equipped with the gimbal!) as well as it was the case until AC 4.0.5.

Version
AC 4.2, AC4.1.5

Platform
[ ] All
[ ] AntennaTracker
[X] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
What type of airframe (flying wing, glider, hex, Y6, octa etc)
Solo
Hardware type
What autopilot hardware was used? (Pixhawk, Cube, Pixracer, Navio2, etc)
Cube

Logs
Please provide a link to any relevant logs that show the issue

[rmackay9]

Hi @mtbsteve,

I've asked some other devs but I think worst case the custom build server can be used to generate a firmware that includes the gimbal.

Our wiki says that users should upgrade to the CubeGreen. We have a CubeSolo and CubeGreen-solo firmware that can be manually downloaded (download the .apj file) and installed using MP's Install Firmware screens, "custom firmware" link

[peterbarker]

@mtbsteve

These are the boards in master that are supposed to have support for Solo gimbal:

libraries/AP_HAL_ChibiOS/hwdef/CubeGreen-solo/hwdef.dat:define HAL_SOLO_GIMBAL_ENABLED HAL_MOUNT_ENABLED
libraries/AP_HAL_ChibiOS/hwdef/CubeOrange/hwdef.inc:define HAL_SOLO_GIMBAL_ENABLED HAL_MOUNT_ENABLED
libraries/AP_HAL_ChibiOS/hwdef/CubeSolo/hwdef.dat:define HAL_SOLO_GIMBAL_ENABLED HAL_MOUNT_ENABLED
libraries/AP_HAL_ChibiOS/hwdef/fmuv3/hwdef.dat:define HAL_SOLO_GIMBAL_ENABLED (HAL_MOUNT_ENABLED && BOARD_FLASH_SIZE > 1024)

The PR referenced above didn't have its description updated before it was merged - but it added it to all of these...

[mtbsteve]

Thanks for getting back. Fact is that the Solo gimbal and GoPro controls works fine with AC 4.0.x but not with AC 4.1.x nor AC 4.2 on the original CubeSolo. Unfortunately I dont have other cubes available to test. All other functions of AC 4.1/4.2 including the OREO LEDs work fine as far as I could test on the SoloCube and Solo flies perfectly well.

So something must have broken in between 4.0 and 4.1, and the only changes I was able to spot in regard to the Solo gimbal and GoPro control are around the PR f7f5880
Any further insights are appreciated.

[rmackay9]

@mtbsteve,

Which firmware do you have on the Solo cube? There are two ways to check:

1. check MP's message tab soon after startup (copy-paste it here, it should say which firmware is being used)
2. post an onboard log and we can check

[mtbsteve]

@rmackay9 I am currently running Arducopter 4.2.0

07.06.2022 10:51:14 : Frame: QUAD/X
07.06.2022 10:51:14 : IMU0: fast sampling enabled 8.0kHz/1.0kHz
07.06.2022 10:51:14 : RCOut: PWM:1-14
07.06.2022 10:51:14 : CubeSolo 00460025 33345108 32383433
07.06.2022 10:51:14 : ChibiOS: 93e6e03d
07.06.2022 10:51:14 : ArduCopter V4.2.0 (6789216)

[rmackay9]

@mtbsteve,

ok, that's the right firmware so it should work. If we're luck it may be resolved by this bug fix that went into master yesterday and broke all mavlink gimbals if SERIALx_OPTIONS = 1024. I'd need to see your parameter file (or better yet an onboard log) to know for sure though.

[mtbsteve]

@rmackay9 here is my parameter file:
https://1drv.ms/u/s!AnKeW8KMoCcygYZBZGhjmIlSd8EfVw?e=qiaCkK
and the most current logfile:
https://1drv.ms/u/s!AnKeW8KMoCcygYZq2N_KOTuvOM7xNg?e=fwMGKX)

[mtbsteve]

@rmackay9 I just compiled CubeSolo from 4.3 dev master including the GCS_Mavlink PR you mentioned - unfortunately the problem still persists.

[rmackay9]

An update on this is that @peterbarker (who has a Solo with a gimbal) tested and found the gimbal worked but he also saw the message "Waiting for Solo" (on the handset I guess). So maybe we have more than one problem with our Solo support.

[mtbsteve]

@rmackay9 thanks for following up.
That might be a different problem. My Solo controller pairs immediately with the Solo and flies well with AC4.2. The gimbal is initialized and levels out. But I am getting the message “Solo Gimbal not found” on the controller display and none of the camera controls are available. So it looks like the entire Mavlink communication with the gimbal is broken.

[mtbsteve]

@rmackay9 I think this Issue relates to my problem:
#20076
If you have any ideas on how to fix it I would be happy to test on my Solo.

[rmackay9]

@mtbsteve,

Sorry for the delay. It is a bit of a long shot but I wonder if perhaps this line is the problem.

    // block heartbeat from transmitting to the GCS
    GCS_MAVLINK::disable_channel_routing(chan);

If you have time could you try loading this binary onto your CubeSolo? This is Copter-4.3.0-DEV with that single line commented out so the gimbal's heartbeats should reach the GCS.

[mtbsteve]

thanks @rmackay9
I just installed the linked binary above but there is no change I am afraid. Still the same problem.
Are there any parameter settings I need to be aware of with 4.3 in regard to the Solo gimbal?

[rmackay9]

@mtbsteve,

OK, thanks for testing in any case.

Do you think it would be possible to connect using MP or QGC and then use their MAVLink inspector and then send me a screen shot of what messages the gimbal is sending with Copter-4.0.x vs 4.3.0-DEV? Just to provide an example of what I'm hoping to see, below is what my Gremsy gimbal is providing.

[rmackay9]

@mtbsteve,

Also I wonder if you could help me confirm that the issue is a Solex<->Gimbal communication problem and not an ArduPilot/autopilot<->Gimbal communication problem by connecting with MP and then right-mouse-button-click on the map and select "Point camera here" and input a large-ish negative altitude to make it try and point downwards?

[mtbsteve]

@rmackay9 ok here you go:
AC 4.0.7: everything works fine and I can see the Gimbal Mavlink communication:

With AC 4.3dev (the binary you sent me) as well as with AC4.1 onwards, there are no longer any Gimbal-related mavlink messages anymore.:

[mtbsteve]

Also I wonder if you could help me confirm that the issue is a Solex<->Gimbal communication problem and not an ArduPilot/autopilot<->Gimbal communication problem by connecting with MP and then right-mouse-button-click on the map and select "Point camera here" and input a large-ish negative altitude to make it try and point downwards?

Point Camera Here doesen't do anything, neither with AC4.0 nor with AC 4.3dev.
But to reconfirm, I can tilt the Solo Gimbal with the Solo controller on both Arducopter versions. So the problem seems to be with the no longer existing Gopro Mavlink commands from AC 4.1 onwards in my understanding.

[davidbuzz]

the issue seems to show GOPRO_GET_RESPONSE, GOPRO_HEARTBEAT and GOPRO_SET_RESPONSE coming to mission planner in 4.0.7 and not in 4.3x so... i suggest doing a 'git bisect' with a bunch of firmware/s in-between to figure out which specific commit/s causes the packets to not get to the gcs?

[davidbuzz]

i can confirm that on mine, CubeSolo-4.0.7 looks good, and CubeSolo-4.1.0 does not, that narrows it down a bit. i tried to find a binary for CubeSolo-4.0.8, which is the only release between these two, but it appears the build server didn't build it.. 4.0.8 was a small release , so i'm guessing its somewhere in the 4.1.0 release.

[rmackay9]

@mtbsteve,

I was wondering if you could do me a favour and test this CubeSolo binary built from this PR?

This binary shouldn't work any better or worse compared to Copter-4.3.0-DEV (aka "latest") but it will allow me to keep moving forward on AP's gimbal drivers while ensuring that I at least don't break the Solo gimbal any more than it already is. So I think with this binary you should still be able to control the gimbal but those GOPRO_ messages still won't appear and so I guess Solex will still not work completely correctly.

BTW, I did spend some time today trying to figure out why the GOPRO_ messages aren't arriving but I haven't figured it out yet. I'll probably need to provide you with yet another binary that includes some debug output.

[mtbsteve]

@rmackay9 thanks - I just installed the binary you provided.
Yes I still can control the Solo Gimbal with the Solo controller.
I now also get the GIMBAL_DEVICE_ATTITUDE_STATUS message in Mavlink inspector similar to your Gemsy example. The coordinate in parameter "q" keeps changing when I tilt the gimbal.
The GOPRO messages still not show up as you already assumed.

[rmackay9]

@mtbsteve,

EDIT: I originally posted a new binary to test but we've found there's an issue with MP that will mean once installed, you won't be able to connect (with MP). We're going to look into this further.

[davidbuzz]

[edit: this commend superceeded, ignore].. actually @mtbsteve , pleas dont use randys build of my PR, yet, its not ready yet... i labeled it 'draft' and 'wip' as it really shouldnt b used yet.

[rmackay9]

@mtbsteve,

Here's another attempt at a CubeSolo binary with the private channel feature disabled and forced to always use MAVLink1. If you could give this a try on your solo that's be greatly appreciated. Completely reboot the Solo and transmitter after uploading this firmware.

This binary was built from this PR.

[mtbsteve]

@davidbuzz @rmackay9 thanks!
I just briefly tested, and yes, all Gopro controls are working now. Also the error message on the Solo controller disappeared.
Looks very good to me!

[davidbuzz]

@mtbsteve - thanks for testing, it worked for me here too. the reason we can't just merge this change as-is into 'master', is that [quite some time back] ardupilot introduced the concept of a 'private mavlink channel' to reduce the amount of spurious mavlink sent OUT on the cube-to-gimbal link, as a result of some opensolo user/s seeing "nodding" of the gimbal at approx 1hz when it recieved too-many mavlink packetss on that link. I'm not seeing this 'nodding' on my gimbal here, but I'd appreciate if you could have a really close look at your go-pro, and see its got any small 1 hz osscillation/s or not with this firmware..?

[mtbsteve]

@davidbuzz I can confirm that there is no oscillation or whatever. The gimbal on my Solo is rock stable and behaves well as before with your fix.

[rmackay9]

@mtbsteve,

I was wondering if you could help us test another enhancement to the Mount library to be sure that it doesn't break the Solo gimbal? If you're available I've linked two binaries for the CubeSolo below. The "-master-" is today's master with your PR applied. The "-new-" is this new PR from me but also with your PR applied.

• Copter-430dev-master-CubeSolo-noprivate-02Sep2022
• Copter-430dev-new-CubeSolo-noprivate-02Sep2022

The "new" one includes mostly non-functional changes to the parameter names and scaling. For example MNT_ parameters now start with MNT1_. The angular limits are in degrees instead of centi-degrees. Also the MTN_RC_IN_TILT parameter is gone and instead the RC channel to control the tilt/pitch is specified by setting RCx_OPTION parameter = 213 (Mount Pitch).

No pressure of course though..

[mtbsteve]

@rmackay9 Thanks! I installed both versions, and both work fine with the Solo gimbal and the GoPro controls from the controller as well as with Solex. Looks good!

[khimaros]

edit: i've filed a separate issue to track this since it may be unrelated: #22155

@rmackay9 i tried updating to your -new firmware on my opensolo4 and am stuck with the controller waiting for solo

the method i used to update is: scp Copter430dev-new-CubeSolo-noprivate-02Sep2022.apj [email protected]:/firmware/ardupilot.apj and then reboot the drone.

this is the same problem i've seen with any version other than the 4.0.1 release included with opensolo4.

is there anything i could do to help troubleshoot? it may be a separate issue from the one discussed here.

there is some more discussion on this topic in the forum