Copter 4.2/4.3: cubesolo not functional with opensolo4

[khimaros]

Bug report

Current status

i'm able to pair and arm successfully with a patched Copter-4.3.0 which forces the MavLink protocol to v1 for SERIAL1 and SERIAL2 and fixing up two FENCE related parameters. a continuous "high, low, high, low" beep happens while armed.

CAUTION: in some cases, with this firmware the gimbal parameters become corrupted, sending the gimbal into bootloader mode and, in turn, soft-bricking the drone (preventing ssh and mavlink access).

the soft-brick can sometimes be resolved by waiting. in other cases, it's necessary to open the drone's gimbal bay and detach the gimbal's data cable while booting the drone. at this point, loadGimbal.py can be used to recover the gimbal firmware.

Issue details

forum discussion

the method i used to update is: scp Copter430dev-new-CubeSolo-noprivate-02Sep2022.apj root@10.1.1.10:/firmware/ardupilot.apj and then reboot the drone.

the firmware update dance completes, but after startup the controller sticks at waiting for solo

i've attached a parameter dump from the functional default OpenSolo4 4.0.1 firmware using QGroundControl.

Version

various including: 4.2.3-CubeSolo, 4.3.0-CubeSolo, and @rmackay9 custom versions from https://github.com/ArduPilot/ardupilot/issues/20923#issuecomment-1235067892

Platform

[ ] All
[ ] AntennaTracker
[x] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type

quadcoptor

Hardware type

3DR Solo with stock cube.

Logs

it looks like the 3dr_solo is not able to establish a serial connection to the pixhawk after upgrade:

root@3dr_solo:~# cat /log/3dr-solo.log
Oct 21 23:06:02 3dr_solo local1.info pix: pixhawk.py starting
Oct 21 23:06:02 3dr_solo local1.info pix: checking baud...
Oct 21 23:06:05 3dr_solo local1.info pix: not at 921600
Oct 21 23:06:08 3dr_solo local1.info pix: not at 921600
Oct 21 23:06:11 3dr_solo local1.info pix: not at 115200
Oct 21 23:06:14 3dr_solo local1.info pix: not at 57600
Oct 21 23:06:17 3dr_solo local1.info pix: not at 230400
Oct 21 23:06:20 3dr_solo local1.info pix: not at 460800
Oct 21 23:06:23 3dr_solo local1.info pix: not at 1500000
Oct 21 23:06:23 3dr_solo local1.err pix: not detected at any baud
Oct 21 23:06:23 3dr_solo local1.info pix: Error checking baud. No response
Oct 21 23:06:23 3dr_solo local1.info pix: Not on recovery partition
Oct 21 23:06:23 3dr_solo local1.info pix: No firmware file found
Oct 21 23:06:23 3dr_solo local1.info pix: pixhawk.py finished

vs. when running with the opensolo4 firmware:

root@3dr_solo:~# cat /log/3dr-solo.log
Oct 21 23:16:35 3dr_solo local1.info pix: pixhawk.py starting
Oct 21 23:16:35 3dr_solo local1.info pix: checking baud...
Oct 21 23:16:36 3dr_solo local1.info pix: found at 921600
Oct 21 23:16:38 3dr_solo local1.warn pix: no version hashes received
Oct 21 23:16:43 3dr_solo local1.warn pix: no build version received
Oct 21 23:16:43 3dr_solo local1.info pix: {}
Oct 21 23:16:43 3dr_solo local1.info pix: now running:
Oct 21 23:16:43 3dr_solo local1.info pix: build_version        unknown
Oct 21 23:16:43 3dr_solo local1.info pix: ardupilot_git_hash   unknown
Oct 21 23:16:43 3dr_solo local1.info pix: px4_git_hash         unknown
Oct 21 23:16:43 3dr_solo local1.info pix: nuttx_git_hash       unknown
Oct 21 23:16:43 3dr_solo local1.info pix: Not on recovery partition
Oct 21 23:16:44 3dr_solo local1.info pix: /dev/serial/by-id/usb-ArduPilot_CubeSolo_29001D000451353232333438-if00 created in 0.464 sec
Oct 21 23:16:45 3dr_solo local1.info pix: heartbeat received over USB in 0.370 sec
Oct 21 23:16:45 3dr_solo local1.info pix: ardupilot_git_hash   (missing)
Oct 21 23:16:45 3dr_solo local1.info pix: px4_git_hash         (missing)
Oct 21 23:16:45 3dr_solo local1.info pix: nuttx_git_hash       (missing)
Oct 21 23:16:45 3dr_solo local1.info pix: loading /firmware/ardupilot.apj
Oct 21 23:16:46 3dr_solo local1.info pix: /dev/serial/by-id/usb-ArduPilot_CubeSolo_29001D000451353232333438-if00 created in 0.511 sec
Oct 21 23:17:43 3dr_solo local1.info pix: firmware loaded in 57.094 sec
Oct 21 23:17:48 3dr_solo local1.info pix: pixhawk.py finished

please let me know if there's any other information i can provide to help troubleshoot.

[mtbsteve]

Please check if you are applying the correct binary for the cube in your Solo. If you are eg on Cube Green you need a different build.

I always upload the Arducopter firmware via USB from Mission Planner. All Arducopter versions including 4.3 are installing smoothly on my stock Cube Solo.

[khimaros]

@mtbsteve thank you for helping out. are you using OpenSolo4 for your drone? which IMX release? have you tried upgrading your cube using the pixhawk.py tool or by installing to /firmware? i'm able to successfully downgrade via this method.

i'm fairly confident that this is a stock cube. the working firmware is ArduCopter.4.0.1.CubeSolo.apj from the latest OpenSolo4 release. also from my logs above, you can see the device node is /dev/serial/by-id/usb-ArduPilot_CubeSolo_29001D000451353232333438-if00

[mtbsteve]

No I am not on Opensolo because I made a lot of modifications and enhancements to the IMX Python code over the past years in my various projects which are incompatible with OpenSolo.

As mentioned above, I am updating the Solo Cube by USB and Mission Planner. I found this the fastest and most reliable way to update any Ardupilot compatible flight controller. Therefore I added an external USB port to my Solo so that I do not need to disassemble the frame every time I install a new version.

[khimaros]

@mtbsteve are those IMX changes published anywhere? i wonder if this incompatibility i'm running into with newer versions of ardupilot is specific to the OpenSolo4 IMX.

i could try the USB route, but i'd prefer to avoid that if i can. my interpretation is that the firmware is being flashed successfully, but not running correctly after it's flashed.

[khimaros]

the failure seems to be related to telemDev not connecting:

from dmesg output on the drone IMX:

[    0.521480] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 59) is a IMX
[    0.521857] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 60) is a IMX
[    0.522274] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 61) is a IMX
[    1.062928] console [ttymxc3] enabled
[    1.065682] 21f4000.serial: ttymxc4 at MMIO 0x21f4000 (irq = 62) is a IMX

it looks like pixhawk.py is trying to read from /dev/ttymxc1 and not able to negotiate a baud rate.

maybe i can get some information by connecting to /dev/ttymxc3 which seems to have a console?

[khimaros]

trying to dive a bit deeper, it looks like the mavlink connection is not establishing.

it's possible that pymavlink on my IMX (version 1.1.56) is too out of date? is that likely? what version are others running?

do you have any recommendations for how to troubleshoot the mavlink connection?

[khimaros]

@rmackay9 has ardupilot > 4.0.1 stopped supporting mavlink v10 or introduced some other change that would make it incompatible with pymavlink 1.1.56?

[khimaros]

@stephendade on discord mentions:

The default MAVLink version for telemetry ports was recently changed to V2. You can change it back via the SERIALn_PROTOCOL parameter

which seems to have happened here: https://github.com/ArduPilot/ardupilot/commit/211c20da38c007a6eb74c24b1991eae07e3baa89

this seems like a promising angle. i'll test and report back.

[khimaros]

success! i'm able to establish mavlink after applying this patch and uploading custom CubeSolo firmware:

diff --git a/Tools/Frame_params/Solo_Copter-4.param b/Tools/Frame_params/Solo_Copter-4.param
index 0d9f096110..0ead6de5f9 100644
--- a/Tools/Frame_params/Solo_Copter-4.param
+++ b/Tools/Frame_params/Solo_Copter-4.param
@@ -146,6 +146,8 @@ RTL_ALT,4500
 RTL_CLIMB_MIN,1000
 RTL_SPEED,800
 SERIAL1_BAUD,921
+SERIAL1_PROTOCOL,1
+SERIAL2_PROTOCOL,1
 SERIAL4_BAUD,230
 SERIAL4_PROTOCOL,1
 SERVO1_FUNCTION,33

there are other issues and i'm not able to arm the system, but this is progress.

[khimaros]

this is the error i'm seeing in QGroundControl when i try to arm:

Hardware Safety Switch is Enabled

i'm attempting a build from the Copter-4.3 branch to see if that helps anything.

[mtbsteve]

Apparently your param settings got somehow corrupted. Please check all your your settings with: https://github.com/ArduPilot/ardupilot/blob/master/Tools/Frame_params/Solo_Copter-4.param Likely there are more parameters which would need a check before arming and takeoff. The Serial settings have to be:

SERIAL0_BAUD,115
SERIAL0_PROTOCOL,2
SERIAL1_BAUD,921
SERIAL1_OPTIONS,0
SERIAL1_PROTOCOL,1
SERIAL2_BAUD,57
SERIAL2_OPTIONS,0
SERIAL2_PROTOCOL,1
SERIAL3_BAUD,38
SERIAL3_OPTIONS,0
SERIAL3_PROTOCOL,5
SERIAL4_BAUD,230
SERIAL4_OPTIONS,0
SERIAL4_PROTOCOL,1

For the Hardware Safety switch, please check:

BRD_SAFETY_MASK,16368
BRD_SAFETYENABLE,0

[mtbsteve]

Please also note that from 4.2 onwards, EKF3 is being used. As a general recommendation, always download and save the parameters before you upload a new Arducopter version. After installation, run a Param compare in Mission Planner and double check all changes to your settings for plausibility.

[khimaros]

i was able to get it to arm on Copter-4.3.0 branch with my patch (shown above) after doing a parameter reset and then recalibrating compass/accelerometer.

however, when i arm, i'm hearing a continuous "high/low" beep pattern from the drone until i disarm. motors spin up correctly.

i also applied @mtbsteve fix for gimbal in https://github.com/ArduPilot/ardupilot/pull/21539, but i'm not seeing video feed and gimbal seems non-functional.

@mtbsteve could you share any more detail about the EKF3 change? what does that impact?

FWIW, i don't have access to a windows machine which i think Mission Planner requires.

[mtbsteve]

I suspect that there is something wrong with your configuration. The “beeping” is certainly not normal. I have not yet tested my gimbal fix with the 4.3 official release, but it worked fine with AC 4.1-4.3-dev. But independent from this, video should work since the video feed is not related to Arducopter and managed by the IMX companion computer.

What I would recommend is to roll back to 4.0.x/OpenSolo defaults, ensure that Solo flies well and is properly tuned. Save the parameters and then try to update to 4.3 again. A compass calibration should not be necessary.

For EKF3 see the Arducopter documentation for details.

You can do everything in QG, no need for Mission Planner. It’s just for convenience, I am using Linux for the Arducopter build environment and Python development, but Windows + Mission Planner for tuning and flight operation (and Solex of course).

[khimaros]

@mtbsteve has your solo ever been in a state where it won't associate with the WiFi access point on the controller?

i think it is failing to return to golden state, or perhaps even failing to factory reset.

i opened it up and manually flashed the known good ardupilot firmware onto the cube, but IMX still isn't booting correctly.

[khimaros]

[edit: the drone was still mostly disassembled at this point meaning the problematic gimbal was not attached. i think this is the reason i was finally able to boot the drone]

it finally (8th time factory resetting) worked.

i think the recovery procedure for the last reset was:

• flash the known good firmware over USB with QGroundControl
• reset the parameters to factory defaults with QGroundControl
• factory reset the drone (press hold pair button while powering on, hold until rapid flash)
• factory reset the controller (press and hold "Power + Fly" until "updating" screen appears)
• press "A" on controller when prompted, see "waiting for solo"
• press pair button again on drone
• controller rebooted itself again
• press "A" on controller after update again, see "found solo, press A & B to pair"
• press "A & B", wait...
• success!

[khimaros]

what a ride. after fully reassembling, it again refuses to associate to WiFi.

disconnecting the gimbal data line, it boots successfully. i wonder what the issue is there.

perhaps something in the IMX is trying to flash the gimbal firmware and then hanging?

[khimaros]

tl;dr, i was able to recover by unplugging the gimbal data cable, booting the drone, then manually reflashing the gimbal. the symptom of a bad state like this is the gimbal light flashing slowly yellow (indicating that it is in bootloader).

i booted with the gimbal detached, this allowed the drone's WiFi and ssh to start.

i then ssh'd to the drone, reattached the data cable, and uploaded the gimbal firmware:

root@3dr_solo:~# gimbal_setup --default /firmware/gimbal_firmware_1.3.6.ax 
Connecting via port 0.0.0.0:14550
Application firmware_file: /firmware/gimbal_firmware_1.3.6.ax
Checksum: 0x8C85
Target already in bootloader mode
Bootloader Ver 4.0
Uploading 64.32kB of 64.32kB - 100%
Timeout

i think the --default is what timed out as the gimbal was still in bootloader mode at this point. it's possible that --reboot would have been sufficient to get it working from here.

i tried gimbal_setup again, this time with --erase and --eraseapp. this time, the upload hung at 36% for about 10 minutes. i interrupted the upload and decided to try loadGimbal.py instead.

i unplugged the camera and ran loadGimbal.py. interestingly, it seemed to resume from 36%:

# loadGimbal.py /firmware/gimbal_firmware_1.3.6.ax 
Gimbal update startup script v1.1.8
Pixhawk found on USB
Connecting via port /dev/serial/by-id/usb-ArduPilot_CubeSolo_29001D000451353232333438-if00
Gimbal in bootloader, only firmware loading is available
Current gimbal software version unknown
Loading file /firmware/gimbal_firmware_1.3.6.ax
Connecting via port /dev/serial/by-id/usb-ArduPilot_CubeSolo_29001D000451353232333438-if00
Application firmware_file: /firmware/gimbal_firmware_1.3.6.ax
Checksum: 0x8C85
Target already in bootloader mode
Bootloader Ver 4.0
Uploading 64.32kB of 64.32kB - 100%
Upload successful
GMB_CUST_GAINS is already set to 0.0
Succesfully updated the gimbal

now the gimbal shows a blue light and the drone boots up cleanly when the gimbal is attached.

i suspect the gimbal has been stuck in bootloader mode which in turn caused pairing to hang/fail. my theory is that the gimbal firmware flashed partially during factory reset and has been stuck there ever since.

[mtbsteve]

@khimaros Good that you got it working again 👍 FYI I just applied AC 4.3.0 to my Solo. All went well as expected. But I observed a new glitch with the Solo gimbal. Currently, I can tilt the gimbal only by approximately 45 degrees. It’s no longer possible to turn the gimbal fully pointing downwards. It was working fine with the former 4.3-dev versions. Could you pls do me a favor and check if your gimbal operates over the full 90 degrees tilt with Copter 4.3.0?

[khimaros]

@mtbsteve have you upgraded your IMX to work with MavLink v2? i think that is required now to run any of the unpatched arducopter builds since the change to v2 by default. on that topic, have you published your IMX somewhere?

[mtbsteve]

@khimaros no I did not apply the pull request from Peter. All Artoo and Imx code is stock (plus my mods). I took Solo for a spin today, it flies perfectly well and all functions I was able to test work fine with AC 4.3.0. Except for the gimbal which can tilt only by 45 degrees. Therefore it would be great if you can check with yours if you get the full 90 degrees with 4.3.

[khimaros]

@mtbsteve do your mods include an updated pymavlink to use the v2 protocol? i can't try off the shelf 4.3 on my OpenSolo4 IMX because the version of pymavlink installed does not support v2.

[mtbsteve]

No. All my mods are in shotmanager. All my pymavlink is still stock Solo. And I use the official 4.3.0 stable release with the addition of my PR re: the private channel (Gopro controls) issue. I guess you can put 4.3 on OpenSolo - just w/o my PR the Gopro controls won’t work.

[davidbuzz]

If i supplied some i-think-ready-to-go .apj file/s for upgrading your OpenSolo from 4.0.4 [stock ] to arducopter 4.1.x , 4.2.x and 4.3.x would u be interested in trying any of them out ? I've tested all of them lightly, and have my solo/gimbal seeming to work in all of them [ ie release+fixes+updatedparams+recompiled into new ready-to-use solo-friendly apjs for a bunch of releases. ] ...?

https://github.com/OpenSolo/ardupilot-solo/tree/solo-build-ardu4.3.2 https://github.com/OpenSolo/ardupilot-solo/tree/solo-build-ardu4.2.3 https://github.com/OpenSolo/ardupilot-solo/tree/solo-build-ardu4.1.5 https://github.com/OpenSolo/ardupilot-solo/tree/solo-build-ardu4.1.0 https://github.com/OpenSolo/ardupilot-solo/tree/solo-build-ardu4.0.7

[davidbuzz]

Stock Solo: [tested] arducopter-solo-build-ardu4.1.0.apj.zip arducopter-solo-build-ardu4.1.5.apj.zip arducopter-solo-build-ardu4.2.3.apj.zip arducopter-solo-build-ardu4.3.2.apj.zip

Green Solo:[untested] arducopter-greencube-solo-build-ardu4.1.0.apj.zip arducopter-greencube-solo-build-ardu4.1.5.apj.zip arducopter-greencube-solo-build-ardu4.2.3.apj.zip arducopter-greencube-solo-build-ardu4.3.2.apj.zip

[comment updated to include green-cube binaries as well]

[mtbsteve]

@davidbuzz thanks! I bench-tested version 4.3.2 and everything looks ok. Weather currently doesent permit flying, so I will try sometime next week. Questions:

• is the apj file compiled for Cube Green or for the Stock-Solo cube? (I tested on stock-Solo)
• in you param file, you changed BRD_HEAT_LOWMGN to 15 degrees. Is that really necessary? I had it set to "0" (disabled, since I am on the stock cube).
• You have added a new parameter BRD_SAFETY_DEFLT,0 to the param file in one of your latest commits. This parameter does not show up in my parameter list after upgrade. Is this a valid parameter for AC 4.3?

[davidbuzz]

@davidbuzz thanks! I bench-tested version 4.3.2 and everything looks ok. Weather currently doesent permit flying, so I will try sometime next week. Questions:

* is the apj file compiled for Cube Green or for the Stock-Solo cube? (I tested on stock-Solo)

[ compiled for stock solo cube, but if u have a different cube, ive given the sources , and its easy to compile for a different target ] ./waf configure --board=CubeSolo ./waf copter

* in you param file, you changed BRD_HEAT_LOWMGN to 15 degrees. Is that really necessary? I had it set to "0" (disabled, since I am on the stock cube).

no, not really necessary, i just found that the cube took ages to 'warm up', preventing flight for longer than i thought necessary, and so i lowered it's 'acceptance window' by 10 degrees. disabling the heater would probably be fine for most users as well.

* You have added a new parameter BRD_SAFETY_DEFLT,0 to the param file in one of your latest commits. This parameter does not show up in my parameter list after upgrade. Is this a valid parameter for AC 4.3?

correct, its a version-dependant param, which exists in newer one/s, but it s ok to put it in the 'defaults' file, as its just ignored if not needed.

[davidbuzz]

I'm expecting that once these get a little bit more testing by bleeding-edge users seeing this, they'll probably make their way out into solex for more testing.

[mtbsteve]

@davidbuzz thanks. Will the changes be merged into Ardupilot Master or will it be a separate codestream?

[davidbuzz]

...Will the changes be merged into Ardupilot Master or will it be a separate codestream?

... unfortunately i dont see an easy path to getting this into ardupilot 'master', thus the separate branches. there's two problems... first is that the introduction of 'private' mavlink streams in 4.1.0 prevents the gimbal packets from being forwarded to the tx and ground, which is needed, and second, in 4.3.x , the 'mount' subsystem was heavily re-worked by randy to support multiple gimbals, and this changed the names of a bunch of params , etc... so the branch i made winds-back that gimbal code to before randy changed it. Solo had its own ardu-fork for the early-days , so going back to a "fork" isnt the end of the world if it keeps solos flying more recent code.

[davidbuzz]

@kellyschrock tells me 'it should be available for download in solex now'

[mtbsteve]

@davidbuzz

... unfortunately i dont see an easy path to getting this into ardupilot 'master', thus the separate branches. there's two problems... first is that the introduction of 'private' mavlink streams in 4.1.0 prevents the gimbal packets from being forwarded to the tx and ground, which is needed, and second, in 4.3.x , the 'mount' subsystem was heavily re-worked by randy to support multiple gimbals, and this changed the names of a bunch of params , etc... so the branch i made winds-back that gimbal code to before randy changed it. Solo had its own ardu-fork for the early-days , so going back to a "fork" isnt the end of the world if it keeps solos flying more recent code.

ok, understood, but a separate codestream is not optimal. So far I tested, the recent gimbal code changes in 4.3 Master were working well with the Solo gimbal. Wouldn’t it be possible to bypass the private channel if a Solo gimbal is connected? Like by using the already existing

if HAL_SOLO_GIMBAL_ENABLED

flag?

[davidbuzz]

@mtbsteve ok, understood, but a separate codestream is not optimal. So far I tested, the recent gimbal code changes in 4.3 Master were working well with the Solo gimbal. Wouldn’t it be possible to bypass the private channel if a Solo gimbal is connected? Like by using the already existing #if HAL_SOLO_GIMBAL_ENABLED flag?

anything is possible if u want it enough. I've achieved what i was trying to do, which is giving Solo's an easy upgrade path to something much more recent that 4.0.4 . I've spent dozens of hours getting this far, and i've decided a small fork, that is 99.9% the same as ardu 'release' was the easiest path forward, for me, at this time.

If you want to do something better, you're welcome to open a PR .

[JBB2068]

@mtbsteve ok, understood, but a separate codestream is not optimal. So far I tested, the recent gimbal code changes in 4.3 Master were working well with the Solo gimbal. Wouldn’t it be possible to bypass the private channel if a Solo gimbal is connected? Like by using the already existing #if HAL_SOLO_GIMBAL_ENABLED flag?

anything is possible if u want it enough. I've achieved what i was trying to do, which is giving Solo's an easy upgrade path to something much more recent that 4.0.4 . I've spent dozens of hours getting this far, and i've decided a small fork, that is 99.9% the same as ardu 'release' was the easiest path forward, for me, at this time.

If you want to do something better, you're welcome to open a PR .

Thank you for putting your time into this!

[mtbsteve]

If you want to do something better, you're welcome to open a PR .

@davidbuzz thanks, appreciated! Have a look at my attempt to solve it in Master. It works fine as far as I could test it and hopefully shouldn't break anything else :-) https://github.com/ArduPilot/ardupilot/pull/22692

[JBB2068]

@kellyschrock tells me 'it should be available for download in solex now'

I have run into a problem with the installation of 4.3.2 on Stock Cube and Green Cube where the imx6 won't connect to the Cube. To solve it I connect via USB and change SERIAL1_PROTOCOL to 1 (default is 2) and that fixes the problem. Can you make that change to the APJ?

[AndKe]

following this thread...

[acbrazzl]

@khimaros, did you ever find a path forward on the imx6 to update it to Mavlink2 serial protocol? say...in pymavlink? I haven't ssh'd in while reading this thread to see if I could just ... read the code, update the library locally, and move on with a IMX6 that speaks mavlink .... I just want the open solo build to be natively compatible without hacky steps. :D

I am catching up on this issue wanting to integrate a SIYI gimbal with support in 4.3.0 without opening my solos back up to set the serial protocol to Mavlink....I'd much rather just get the IMX6 to communicate in Mavlink2.

@davidbuzz, am I missing something in my reading the above thread and do your previously posted solo-4.3.2 builds support Mavlink2? Or is this just one of those things where anyone in the know is attaching a USB and altering the Cube's serial to Mavlink2 and I'm just the only one wishing it were set in the most recent build of Open Solo?

[JBB2068]

@khimaros, did you ever find a path forward on the imx6 to update it to Mavlink2 serial protocol? say...in pymavlink? I haven't ssh'd in while reading this thread to see if I could just ... read the code, update the library locally, and move on with a IMX6 that speaks mavlink .... I just want the open solo build to be natively compatible without hacky steps. :D

I am catching up on this issue wanting to integrate a SIYI gimbal with support in 4.3.0 without opening my solos back up to set the serial protocol to Mavlink....I'd much rather just get the IMX6 to communicate in Mavlink2.

@davidbuzz, am I missing something in my reading the above thread and do your previously posted solo-4.3.2 builds support Mavlink2? Or is this just one of those things where anyone in the know is attaching a USB and altering the Cube's serial to Mavlink2 and I'm just the only one wishing it were set in the most recent build of Open Solo?

I use Serial4 for the SIYI A8 Mini on a Solo if that helps.

[acbrazzl]

Thanks for the quick reply @JBB2068, but I'm mainly trying to have the cube talk to the IMX6 after updating to 4.3.0 (which is when the SIYI was added in as a selectable gimbal). Yes we can connect a USB to our solo's (and set the cube to speak Mavlink v1) but the dozens of solo owners that follow in our footsteps maybe won't want to do that? Wondering if there is a IMX6-side change and/or open-solo change to be made here. IRL it should be baked into the next open-solo release to maintain arducopter release compatibility. Until this, open-solo is broken and needs an update.

[JBB2068]

Yes I just change Serial1 to mavlink1 and it talks to the IMX6 fine. I posted the 4.4.3 APJ to use with Solex that already has serial1 on mavlink1.

I agree it would be nice for Open Solo to be using mavlink2. It seems like David Buzz is already working on that.

On Sat, Dec 23, 2023, 8:02 PM Brazz @.***> wrote:

Thanks for the quick reply @JBB2068 https://github.com/JBB2068, but I'm mainly trying to have the cube talk to the IMX6 after updating to 4.3.0 (which is when the SIYI was added in as a selectable gimbal). Yes we can connect a USB to our solo's (and set the cube to speak Mavlink v1) but the dozens of solo owners that follow in our footsteps maybe won't want to do that? Wondering if there is a IMX6-side change and/or open-solo change to be made here. IRL it should be baked into the next open-solo release to maintain arducopter release compatibility. Until this, open-solo is broken and needs an update.

— Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/22155#issuecomment-1868420594, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHQW2ZXG3KZC3ZYARZOFIALYK6LMHAVCNFSM6AAAAAARZ3EC72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGQZDANJZGQ . You are receiving this because you were mentioned.Message ID: @.***>

[acbrazzl]

ooo I'll try that 4.4.3 APJ in the AM and put a TODO on setting up a dev environment to build this stuff locally :)

[davidbuzz]

Given that solo' gimbal is now open-source , its now theoretically uqite possible to updt ethe entire solo to Mavlink 2. ... but its not sonething thats gonna be easy, as there's so-many moving parts in a solo that use mavlink https://github.com/OpenSolo/OpenSolo-extras/

[khimaros]

@davidbuzz thank you for your work on these images. i'm hoping to take these or a later release for a spin in the coming days.

would you mind sharing a bit about how you built these? did you apply any patches beyond the SERIAL1_PROTOCOL param change?

i am considering applying that change to 4.5.4 branch, since it seems that the private channel fixes were merged in https://github.com/ArduPilot/ardupilot/pull/23861

[JBB2068]

If it helps, the 4.5.3 versions available in Solex and SidePilot for CubeSolo and CubeGreen have the following additional changes to the default params found in the Ardupilot download APJ for CubeSolo.

COMPASS_AUTO_ROT 0 COMPASS_ORIENT 38 SERIAL1_PROTOCOL 1 SERIAL4_PROTOCOL 1 SERIAL4_BAUD 230 MNT1_TYPE 2 MNT1_PITCH_MAX 0 MNT1_PITCH_MIN -90 MNT1_YAW_MAX 45 MNT1_YAW_MIN -45 CAM1_TYPE 3 RC6_OPTION 213 RC7_OPTION 166 RC8_OPTION 167 FENCE_MARGIN 0 ARMING_CHECK 5630 BRD_HEAT_LOWMGN 0 BRD_SAFETY_DEFLT 0 DID_ENABLE 0 DID_MAVPORT 2

[khimaros]

@JBB2068 thank you, that is extremely helpful!

do you happen to know if the APJ files that Solex uses are available publicly? are they the same versions from https://firmware.ardupilot.org with just the modified params?

[JBB2068]

@JBB2068 thank you, that is extremely helpful!

do you happen to know if the APJ files that Solex uses are available publicly? are they the same versions from https://firmware.ardupilot.org with just the modified params?

I used the Custom Build Server to build the current Copter (4.5.3) adding the APJ space. Then used the APJ tool to add the parameters to the existing default parameters. Resulting in the following two files.

This is the CubeSolo file https://drive.google.com/file/d/1NUVD6Bd99fZ0ZQi2oOizkMzzEL9VatlE/view?usp=sharing

This is the CubeGreen file https://drive.google.com/file/d/1dD6RgCSzYkYFr31JuU37lCfhiU1i33ey/view?usp=sharing

[khimaros]

@JBB2068 thank you! are you also the owner of https://jonbrotherton.fws.store? if so, i'm curious if you have an updated link for https://bit.ly/3tMZrwf (the DIY battery mod instructions)

[JBB2068]

@JBB2068 thank you! are you also the owner of https://jonbrotherton.fws.store? if so, i'm curious if you have an updated link for https://bit.ly/3tMZrwf (the DIY battery mod instructions)

Yes, the battery mod document is here https://drive.google.com/file/d/1kwUlTDKVDHVkY6UCDoXdGuPJXFgDAxoO/view?usp=drivesdk

[khimaros]

here is the full set of default params pulled with ./Tools/scripts/apj_tool.py --show ../solex/ArduCopter4.5.3CubeSolo.apj. maybe some of these make sense to merge upstream.