My CubePilot Board with Orange Cube Fried?

[vyoufinder]

I was simply going to calibrate my radio but my CubePilot Board with Orange Cube stopped working. The only thing I changed was my RC16 .param. I had it inverted on my CubePilot Board but not on my radio and was changing it from inverted to not inverted, and afterward went into QGroundControl to calibrate the radio. I was also investigating why I can’t seem to get my sBuso to work, even though I am pretty sure it was configured correctly. I suspect it is related (see: sBuso Doesn't Seem to Work - Copter 4.0 - ArduPilot Discourse for details on how I have it setup.) Just before this happened, I had connected and disconnected several times like I normally do without any problems. I wasn’t getting any error messages in Mission Planner, so I didn’t think to check the light on the CubePilot Board and I only get the error message when using QGroundControl, which I prefer for calibrating my radio, so this could’ve been going on for longer than I know, but definitely within the last few days I’ve been configuring intensely.

In QGroundControl, I get an error message:

“Your Vehicle is not responding. If this continues, shutdown QGroundControl, restart your Vehicle letting it boot completely, then start QGroundControl.”

The orange light on my CubePilot Board turns on when I first plug it in, but then turns off after about 10-20 seconds. This happens if I connect it to my computer via USB, or if I connect the battery; it makes no difference.

In QGroundControl, I can still see all the GPS’s, receivers are lit, working, and connected, voltage monitor still working, flight modes are still there and correct and all the rest of the settings. In Mission Planner, I can still read and write .params, see the gps results, everything else. but no light on the CubePilot Board, and still getting the message when using QGroundControl. I can repeatedly flash the firmware in QGroundControl. I can also flash the ChiBios in QGC, which I have done now more than once. My GPS units, 3DR telemetry radio, landing gear still retracts and deploys, everything still seems to work, but the board.

I’ve been configuring for months and the only thing I did different from what I normally do was to unplug the battery (red wire first) while it was still connected to the computer via the USB port on one of the times I connected. Could this cause my board to fry? Is my board fried?

[Mallikarjun_SE]

The PSM on carrier board shifts the power to USB as soon as you plug in and stays in USB power until next cycle. I don’t think you can burn anything by shuffling the power.

[vyoufinder]

The only other thing I can imagine is…

The other day I was connecting a gimbal and connected all three servo wires to the USBo port, the other end to my gimbal, which has its own battery and its own power. I was unable to get the SBUSo working. I posted about it: https://discuss.ardupilot.org/t/sbuso-doesnt-seem-to-work/55399

Could it be that power from the sBus out on gimbal was transferred to sBus out on the CubePilot Board and fried the board? I don’t know what would cause this hardware change. to stop responding, even though much of it is responding. and the error message all of a sudden. It seems like it just fried.

The other symptom of the board is that my channels 15& 16 are suddenly not being shown as working using either Mission Planner or QGC, but in QGC I can see the channels, they just appear not to be working, and they were working before. … and I made no .params changes with servos or otherwise there to make them stop working either. All the other channels still work fine, which is strange.

[Mallikarjun_SE]

@vyoufinder

The other day I was connecting a gimbal and connected all three servo wires to the USBo port, the other end to my gimbal, which has its own battery and its own power. I was unable to get the SBUSo working

Didn’t get you. Can you share a picture of connection?

[MadRC (Ian)]

I would try as following first.

Re seat the Cube on the carrier board, remove and carefully re fit.

Flash with Rover, then flash back to copter and start again with prams and see.

[philip]

There should not be any lights if all is working.

Lights means fault

[vyoufinder]

Here are pictures of the connections. Like I say, the sbus ports on both ends are tabbed, and I am using tabbed connectors. I did try using a different cable and reversing the connection, but it did not help. As shown, I have used the sbus cable with or without connecting the center power wire. It works fine when I connect it directly to the receiver.

I’ve double checke that my settings are:

BRD_SBUS_OUT to “1”
SERVO9_FUNCTION to “1”
SERVO10_FUNCTION to “1”
SERVO11_FUNCTION to “1”
SERVO12_FUNCTION to “1”
my SERVO_SBUS_RATE is set to “50”

I’m still getting the message in QGroundControl:

@vyoufinder

“Your Vehicle is not responding. If this continues, shutdown QGroundControl, restart your Vehicle letting it boot completely, then start QGroundControl.”

So I enabled logging while unarmed and created a log file:
00000006.BIN (1.1 MB)

@MadRC

Flash with Rover, then flash back to copter and start again with prams and see.

I did this part, but works the same.

[vyoufinder]

I got the board back from Spektreworks. Dan, who tested it, said that he was able to connect to Mission Planner, tested my sBuso, and sent my board back to me. I was able to connect too. Even install firmware a few times too. I flashed to rover, then back to copter. Then I decided I wanted to see how my battery monitor settings would come in as the default copter, so flashed to plane, then back to copter. After flashing to plane, then rebooting the board, the orange light stayed on for over 20 minutes before I unpugged it and restarted. Then it booted fine. Then I flashed to copter again, and rebooted, and the same thing happened - orange light, can’t connect, board acts frozen. So then I flashed to rover again (to see if it was a plane issue only) and the same thing happened. So then I tried without unplugging the board, and I was able to flash once, then the second time my com port wasn’t found when scanning. Rebooted it, and it flashed fine. Then I tried to boot and it got hung up at:

Then rebooted, and worked fine. It seems like the board is intermittently losing the usb com port connection. When I use my 3DR telemetry radios for a connection, I don’t get any of these problems in Mission planner and no warning that my board has stopped responding in QGroundControl.

Now, most of the time I connect via USB, when I try to boot, the orange light comes on… and that’s about it. Nothing else happens. I can’t connect. It isn’t booted. Windows 10 doesn’t attach anything. an hour ago I was flashing firmware back and forth, configuring. After flashing to copter the last time and giving plenty of time before reboot, now my board doesn’t even boot up until about the 5th or 6th try.

The progress bar at the top of Mission Planner doesn’t finish sometimes:

When I load parameters from a file, then write to the board, it works, but then I’ll compare params to that same file, and some parameters will not be updated. In particular, the battery settings, SR2 settings, etc. But this is only sometimes. Other times I can load from file, write parameters, and all parameters match. When I try it a second time, all the normal parameters (not stats) load in and write fine. The inconsistency is bothersome.

Sometimes when I am flashing firmware, I get:
About half the time, I am able to flash, but about half the time the board won’t fully boot up and I get stuck in an endless cycle of orange light staying on and won’t boot I have ot try like 10 or 20 times sometimes, and the board finally boots. It doesn’t matter which computer I use. Then something gets triggered, the board boots, and I can go back to the other computer and boot fine. When I try to flash firmware on the other machine, it won’t find the com port, which is something it never had trouble with. So something has definitely changed on my board/cube, and not in a good way.

In QGroundControl, I now get an additional error message in addition to the

message, now I also get:

Dan suggested that " the newest firmware is presenting an SLCAN interface as a serial COM port in addition to the regular serial COM port." Do I need to make some settings change? It just doesn’t make sense to me that all of a sudden, without any changes, my new board starts acting much differently than when I first started setting it up. All of this can’t be normal. I was mostly all configured and ready for test flying just waiting for the weather to warm up. I had been connecting and disconnecting all the time. Loading firmwares, parameters, an any program, all without trouble.

[Mallikarjun_SE]

Hey! Has the bootloader on Orange cube updated?
Regarding the parameters not saving, it has been solved with updated bootloader. You can flash latest Master and update bootloader and come back to stable firmware. Try this, if the problem is persistent, then it’s some other issue. Please share a video of the process you are following instead of write a long post. Videos are simpler to analyse.

[vyoufinder]

I’ve already updated the bootloader about 10 times now. As Rover, as Copter, as Plane. It doesn’t matter which bootloader nor which firmware, it all reacts (or doesn’t) the same.

I can make a video as I proceed, but I promise you the written version is shorter than the video I would’ve made over the past month as I tried to figure this out. I’ll make one now…

At the moment, it acts like it’s working fine in Mission Planner. But when I go to install firmware, it can’t find the com port. In a few minutes, I will try it and be able to install firmware, then it won’t boot.

Here is what happens in QGroundControl:

(you can pretty much skip till the end to see the error. Length of video gives amount of time before I get error.

And here is what happens when I install new firmware:

I managed to install the latest version of arducopter, update the bootloader, then revert firmware back to 4.0.3 (current stable.) IT took about 5 or 6 tries for each to not get hung up on “scanning for com ports” but finally worked. After I did, it was the same as in the video. Board won’t complete booting. Then on 2nd try to close Mission Planner, then re-open it, froze at:

again. I am not sure why every once in a while it freezes at this same point of loading paramaters.

[MadRC (Ian)]

Can you plug it into the usb and post a pic of what’s being shown in device manager for the ports.

Can you also confirm your using Windows 10 pro again ?

If not pro what version ?

[vyoufinder]

yep, Windowx 10 Pro 64 bit

I think I’ve already re-installed the drivers, I think I used to get some CubePilot or STMicro (too many for different vehicles to keep track of sometimes) These don’t look right to me, but I just reinstalled the drivers again and that’s how it comes in.

[MadRC (Ian)]

You definitely have driver issues.

You need to remove the drivers and everything and start again.

Also be very careful upgrading the boatloader as it can brick the FC if that goes wrong. I would not do it again now.

If you look at the info on the wiki this shows you what you should have at the bottom specifically with the two com posts being Mavlink and CAN.

https://docs.cubepilot.org/user-guides/autopilot/the-cube-series-firmware-and-connection-troubleshooting

[Mallikarjun_SE]

Yes. Looks like driver issue. Delete the com port related to Cube in this and plug it back in. And wait for sometime. It should install new drivers. Before this try to uninstall mission planner and install again with latest beta. The ports should show Cube orange.

[vyoufinder]

I did a fresh install of Windows then installed the Mission Planner drivers. I also bought another Cube Orange for comparing to. The new cube must be a newer revision of the Cube Orange because the box came in a sealed bag and without a beta sticker on it this time. I like that. It makes me feel safer although the beta sticker is cool for feeling like an innovator. Upon install I get the “Cube Orange Mavlink” and “Cube Orane SLCan” to show up as my Com port drivers now.

With the completely fresh setup of; Windows, Mission Planner & drivers, and QGroundControl combined with a fresh out of the box Cube Orange and without any jiggery pokery in between, I still get the error in QGroundControl.

With my other (not brand new) cube orange, I get the same drivers showing in Device Manager. The same error, of course.

There’s definitely nothing wrong with my Cube Orange. I can fly with it and trust it. This is an issue with either my hardware and software setup on my freshly re-installed Windows 10 Pro machine, or a problem with QGroundControl. I’d like to figure it out, but it would seem it’s not critical to my flying safely.

Video description of problem:

- YouTube

[MadRC (Ian)]

This is most likely a QGC issue or a comma issue on the PC.

Does it do the same in Mission Planner ?

The Orange and Yellow have a totally different com port setup and it’s possible it’s dropping the connection.

When the connection drops what does the LED in the cube do ?

[vyoufinder]

@MadRC

This is most likely a QGC issue or a comma issue on the PC.

For sure, agree.

@MadRC

Does it do the same in Mission Planner ?

No. Everything works as normal as far as I can tell. The only issue is the error message making me feel unsafe to fly and it only happens when connected via USB. It happens on all 3 computers; 2 Windows 7 Pro, one Windows 10 Pro I have. Never happens when connecting via sik radio and Android phone nor when I use the sik radio on my PC, then I don’t get any error message.

@MadRC

When the connection drops what does the LED in the cube do ?

As far as I can tell, the connection doesn’t actually “drop.” It thinks it did, but then everything’s working as normal. No lights at all, except when booting up. I can configure, write firmware, bring in params, etc. without problems.

Dan at SpektreWorks suggested that maybe QGroundControl was grabbing onto the SLCan com port. I am thinking he was thinking in the right direction. Do my drivers look as they should?