Copter 4.2/4.3: cubesolo not functional with opensolo4 #22155
Comments
rmackay9
changed the title
|
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. |
|
@mtbsteve thank you for helping out. are you using OpenSolo4 for your drone? which IMX release? have you tried upgrading your cube using the i'm fairly confident that this is a stock cube. the working firmware is |
|
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. |
|
@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. |
|
the failure seems to be related to from dmesg output on the drone IMX: it looks like maybe i can get some information by connecting to |
|
trying to dive a bit deeper, it looks like the mavlink connection is not establishing. it's possible that do you have any recommendations for how to troubleshoot the mavlink connection? |
|
@rmackay9 has ardupilot |
|
@stephendade on discord mentions:
which seems to have happened here: 211c20d this seems like a promising angle. i'll test and report back. |
|
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,33there are other issues and i'm not able to arm the system, but this is progress. |
|
this is the error i'm seeing in QGroundControl when i try to arm:
i'm attempting a build from the Copter-4.3 branch to see if that helps anything. |
|
Apparently your param settings got somehow corrupted. For the Hardware Safety switch, please check: |
|
Please also note that from 4.2 onwards, EKF3 is being used. |
|
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 #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. |
|
I suspect that there is something wrong with your configuration. The “beeping” is certainly not normal. 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. |
|
@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. |
|
[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] i think the recovery procedure for the last reset was:
|
|
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? |
|
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%
Timeouti 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 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 gimbalnow 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. |
|
@khimaros Good that you got it working again 👍 |
|
@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? |
|
@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. |
|
@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. |
|
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. |
|
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 |
|
Stock Solo: [tested] Green Solo:[untested] [comment updated to include green-cube binaries as well] |
|
@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:
|
[ 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 ]
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.
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. |
|
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. |
... 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. |
|
@kellyschrock tells me 'it should be available for download in solex now' |
ok, understood, but a separate codestream is not optimal. |
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! |
@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 :-) #22692 |
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? |
|
following this thread... |
|
@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. |
|
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. |
|
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
<#22155 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHQW2ZXG3KZC3ZYARZOFIALYK6LMHAVCNFSM6AAAAAARZ3EC72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGQZDANJZGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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 :) |
|
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 |
|
@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 i am considering applying that change to 4.5.4 branch, since it seems that the private channel fixes were merged in #23861 |
|
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 |
|
@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 This is the CubeGreen file |
|
@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 |
|
here is the full set of default params pulled with |
|
confirming basic benchtest functionality (motor spin up, bladeless altitude hold launch, param download, mission upload, and camera feed/control) with @JBB2068 CubeSolo 4.5.3 image linked above and QGroundControl 4.4.0. |
1 - get my customised ardupilot-on-OpenSolo the code from one of the branches mentioned above, in the normal git manner: 2 - compile it for CubeSolo, in the normal manner on a machine that has all the dev tools installed: 3- rename the resulting binaries so they have version info in the file/s, and zip them, and upload them here. 4 - if you want to see precisely what's changed in each of the branches, github will trivially show you eg for the newest branch i made, and my comments above also describe what i did and why. https://github.com/OpenSolo/ardupilot-solo/commits/solo-build-ardu4.3.2/ @JBB2068 / "JB" appears to have made a newer code release for 4.5.3 made using a different method that @kellyschrock has also made available in Solex, but I had nothing to do with building or testing that release and so I dont know how well it works with gimbal/s and/or mavlink forwarding, but presumably they've tested it as best they can. :-) Closing ticket now as its been open way too long ant really shouldn't have become a support ticket. |
|
@davidbuzz I used the Custom Build Server and the Copter 4.5.3 release to add in the APJ area so I could change the default SERIAL1_PROTOCOL to 1 so people won't think their Solo is "bricked" when they load it. Not sure why the Solo APJ files available in Ardupilot downloads still have SERIAL1_PROTOCOL=2 but it confuses some Solo owners. I have verified that the APJ files posted in Solex have no problems with the Gimbal or anything else and flies well. I have it in use on several copters. Thank you for your help David! |
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
v1forSERIAL1andSERIAL2and fixing up twoFENCErelated 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.pycan 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 [email protected]:/firmware/ardupilot.apjand then reboot the drone.the firmware update dance completes, but after startup the controller sticks at
waiting for soloi've attached a parameter dump from the functional default OpenSolo4
4.0.1firmware using QGroundControl.Version
various including:
4.2.3-CubeSolo,4.3.0-CubeSolo, and @rmackay9 custom versions from #20923 (comment)Platform
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:
vs. when running with the opensolo4 firmware:
please let me know if there's any other information i can provide to help troubleshoot.
The text was updated successfully, but these errors were encountered: