Flashed ArduCopter 3.7-dev First Time Install.zip on OpenSolo

VCD

Joined
Nov 7, 2016
Messages
165
Reaction score
47
Age
44
Unable to boot/connect the Solo after, because the cube now says:

Code:
[MAV 001:1] ArduCopter V3.7.0-dev (fb1c2cef)
[MAV 001:1] ChibiOS: d443078c
[MAV 001:1] CubeBlack-sol 0041002D 33345119 3238343
[MAV 001:1] Frame: QUAD
[MAV 001:1] Initialising APM
[MAV 001:1] Check BRD_TYPE: Failed to init CubeBlack - sensor
[MAV 001:1] Initialising APM
[MAV 001:1] Check BRD_TYPE: Failed to init CubeBlack - sensor
[MAV 001:1] Check BRD_TYPE: Failed to init CubeBlack - sensor
[MAV 001:1] Initialising APM
[MAV 001:1] Check BRD_TYPE: Failed to init CubeBlack - sensor
[MAV 001:1] Check BRD_TYPE: Failed to init CubeBlack - sensor
[MAV 001:1] Initialising APM

This is a stock cube, modified for 5v PWM output.
And it is stuck in a initializing loop..

Of course, in this state factory reset of OpenSolo3.0 also fail.

same with the firmware inside "ArduCopter 3.7-dev FW Only 2019-04-27"
both fail to run on stock cube..
Can you please point me to current firmware that will run on the stock cube (with 5V PWM output, so it is safe)
 
Last edited:
There's an updated package in solex as of about 6hrs ago that fixes this. Both dated April 28. Hitting cleanup and refresh in Solex will refresh from the server. The issue is explained in the beta test group that I again strongly suggest you join. That's the 'official' support group for this.

Since Solex won't connect in that state, you'll probably need to download the latest CubeSolo from ArduPilot and drop it in /firmware to load it.
 
Thank you, works as expected.
As for FB, my previous career was in internet security, and FB is a place I rarely log on to.
 
Short version: ArduPilot just added some checks that verify if the board is defined as a Hex Cube Black, than all the Cube Black's specific sensors are actually detected. If sensors are missing or different, it does what you're seeing. The stock cube from years ago has different sensors and was manufactured by 3DR, not Hex. So when loading firmware defined for a Cube Black onto the old cube, it saw different sensors and got pissed. Until about a week ago, these checks didn't exist so it didn't matter.

I redefined the CubeBlack-solo build target (now renamed to CubeSolo) and made it a child of the FMUv3 build target instead of the CubeBlack build target. As such, it will not be seen as a screwed up Hex Cube Black, and has all the same functionality. It's actually what it probably should have been to begin with since Hex didn't make this cube.

For the same reasons as above, you cannot put a CubeGreen build on the stock solo cube even if it has the 5v mod. The same thing will happen. You will have to use the CubeSolo build and manually load the green cube parameters (the only real difference anyway). However, you can go the other way, putting CubeSolo on a green cube, and it will work fine. Hence why anything I do ships with CubeSolo now, since it it is compatible with basically anything.
 
  • Like
Reactions: Wetstone
yes, I guessed that was the new checks, but did not expect it to boot-loop like that, but it is most likely the best thing to do if it needs to recover a ArduPlane after the watchdog feature is used for midair reboots now.
Thank you.
 
Ah good, you're already familiar with all of that. This is the change that went in for the Solo's cube to get it working again.
HAL CHIBIOS: Make Solo's older cube a child of fmuv3 instead of CubeBlack by Pedals2Paddles · Pull Request #11213 · ArduPilot/ardupilot (Build target)
Change auto build script from CubeBlack-solo to CubeSolo. by Pedals2Paddles · Pull Request #11215 · ArduPilot/ardupilot (Auto build script)

Were you able to load the new FW through the /firmware folder still? Or did you have to plug in with USB to do it?
 
I pulled out the Cube and installed it on a carrier board, flashed using the Tools/scripts/upload script.
 
Last edited:
The truth is that the controller said "waiting for solo" , so I never checked whatever I could SSH to it.
I removed the 7 screws in the battery bay, one on the PCB and four holding the cube, tilted PCB it up ,and removed cube thru gimbal hole. (empty, for a different payload.)

So it was not very efficient in hindsight, but trivial once I did it so many times before.
 
I have plugged in my Solo via USB and can connect to mission planner via the com port but how do i browse the files on the SD card to copy the firmware across?
 
I have plugged in my Solo via USB and can connect to mission planner via the com port but how do i browse the files on the SD card to copy the firmware across?
You don't do that by USB. That USB connection is only for the cube and to use tools such as Mission Planner to load firmware or change parameters.

Browsing the directories on the IMX SD card is done over WiFi with an SFTP app or ssh.
 
Currently i am playing with a solo main board and black cube out of a damaged solo and don't have it paired with a remote to get on to it via Wifi. Can i remove the SD card and use a card reader to copy the files?
 
Currently i am playing with a solo main board and black cube out of a damaged solo and don't have it paired with a remote to get on to it via Wifi. Can i remove the SD card and use a card reader to copy the files?
No that generally will not work. The SD card contains multiple partitions forming a linux file system. If you put that into a windows PC, you won't likely see or have access to anything useful. What are you trying to copy onto it?
 
The board only has the 3DR firmware on it and I want to put at least open solo or 3.7 dev. I am currently testing the arduino interface with the solo returning data in place of the smart battery. I have it working with the voltage but need to test it with the newer version which reads individually cell voltages etc. Currently all my controllers are running Open Solo so I can't pair it.

Is there a 3.7 dev SD card image I can transfer to my card if there isn't another way?
 
You can pair your existing open solo controllers. They will pair like normal. The controller will give you a version mismatch error. But it will still be paired and accessible over wifi. And Solex will still connect and allow you do the firmware installs. There isn't an SD image of anything supporting 3.7-dev yet.
 
Great I'll give that a go. Does the USB connected to the cube power the wifi on the solo board or will it need a battery connected? Failing that I will update one of my other Solo's to 3.7 dev with Solex and can then image that card.
 
No, it will only power up the cube.

If you want to try something more complete and without burning SD cards, you can give this a shot. This is where I'm currently at with Open Solo 4, which includes 3.7-dev from Sunday as well. You an install using the new SSH/SFTP instructions on there.
 
Awesome. I will try and get power to the solo board and get it paired to a controller and give the above a shot. Thanks for your help Pedals2Paddles.
 
I could connect to both the Solo and controller but I had an issue with Putty with command not found -sh $ when using
$ sololink_config --update-prepare sololink
I then used Solex to upgrade to Open Solo on both the controller and board, this worked fine. I then used Solex to install 3.7 dev on both the solo and controller. This appeared to work, the controller connects to the solo and after a while comes up with compass calibration error which is true. I can connect to the Solo via mission planner and Putty but now Solex can't find the solo. Mission planner has the Solo as ArduCopter solo-0.1.0-pvt-3 (58b3301f) is this correct for 3.7 Dev?
 

Members online

No members online now.

Forum statistics

Threads
13,093
Messages
147,741
Members
16,048
Latest member
ihatethatihavetomakeanacc