Solid green LEDs, won't connect to controller (following parameter update)

awp0 · May 29, 2018

So I made a booboo and updated a parameter using Tower with a bad value (serial4_protocol). Since updating that param and restarting the Solo, it will no longer startup successfully. The Solo beeps (as normal), but the LEDs stay green and it will not connect to the controller. So I screwed up pretty badly. I've tried factory reset, and as expected it did not work (I have read that factory reset does not change parameters). What can I do to reset parameters and get back to a default functional state?

Current situation:
Running Opensolo, with one of the beta versions just before 3.0.0.
All LEDs solid green after startup
Controller stuck on "waiting for Solo"
I can connect to the SoloLink wifi network but cannot ping 10.1.1.10 while connected to it.

I consider myself fairly technical and adventurous, so I'm willing to follow any reasonable instructions.Thanks for any help in advance!

Aaron

awp0 · May 29, 2018

Ok, after more fiddling it looks like I can connect via SSH (but not Tower). And it looks like the controller *is* connecting to the Solo, but as the Solo never finishes staring up therefor the controller just states "waiting for Solo" indefinitely.

Is there a way to reset parameters to default via SSH? Thanks.

just_bruce · May 29, 2018

Search SSWT. Should help.

awp0 · May 29, 2018

just_bruce said:
Search SSWT. Should help.

Thanks, it looks like this could do the trick. I guess there's no way to update a parameter via ssh? I was hoping to not undo my hacked-together aftermarket gimbal mount.

awp0 · May 29, 2018

Ok, I've removed the gimbal and gimbal bay cover, and I've tried starting up with the SSWT button pressed. In addition to the standard startup sound, I get the funky new sound (twice) and then it restarts. Unfortunately after a reboot I'm still in the same state. 4 green LEDs, and "waiting for solo" on the controller. I think I've really messed something up. The good news is that i can still connect via SSH/SFTP.

I also tried calling resetParameters from the pixhawk.py file using the following trick. It appears to reset the variables, but I have no way to verify:
3DR/pixhawk Parameters - reset on factory reset?

But unfortunately I keep coming back to the same result (4 solid green LEDs, indicating failure to startup).

Here's a few errors that i can see in the 3d-solo.log file on startup:
Nov 23 15:56:20 3dr_solo local1.err pix: not detected at any baud
Nov 23 15:56:20 3dr_solo local1.err pix: finding baud
Nov 23 15:56:20 3dr_solo local1.err pix: pixhawk status: no response

And this in the boot log:
Thu Nov 23 15:56:00 2017: Thu Nov 23 15:56:00 UTC 2017
Thu Nov 23 15:56:00 2017: initializing pixhawk interface...
Thu Nov 23 15:56:02 2017: pixhawk...
Thu Nov 23 15:56:20 2017: pixhawk: ERROR checking baud
Thu Nov 23 15:57:58 2017: pixhawk: ERROR checking version
Thu Nov 23 15:57:58 2017: Gimbal update startup script v1.1.8
Thu Nov 23 15:58:00 2017: No pixhawk found on USB. Exiting.

Any ideas??

Thanks!
Aaron

Edit: Since I seem to have created a communication problem with the pixhawk, I am guessing that my next option is to pry up the board and attempt to connect to it via USB with Mission Planner. Then look at the state of the parameters and either reset to default or look at the parameter I changed and attempt to revert it. Would appreciate any feedback on this plan!

XevetS · May 30, 2018

awp0 said:
I am guessing that my next option is to pry up the board and attempt to connect to it via USB with Mission Planner

Yes that would be the way to go, Look for SYSID_SW_MREV and set it to 0 save and reboot (that resets the parameters on the solo's Pixhawk to stock) Then save and reboot..

awp0 · May 30, 2018

XevetS said:
Yes that would be the way to go, Look for SYSID_SW_MREV and set it to 0 save and reboot (that resets the parameters on the solo's Pixhawk to stock) Then save and reboot..

Thanks!

Ok, back in business! Unfortunately I couldn't change parameters directly in MP, even when connected via USB. It appears the USB connection uses a virtual serial port and communicates over Mavlink, so I had the same problem as with the other attempts. However, I was able to flash ardupilot-solo onto the Pixhawk eventually. MP would not let me do it directly, I'm guessing because it needs Mavlink to flash a custom firmware. But it would let me flash one of it's pre-loaded firmwares for other vehicles (I used Rover). This allowed Mavlink to function again, and then I was able to flash ardupilot-solo. After a few (unexpected and slightly worrying) automatic reboots of the Solo, it seemed to take. I've re-added the parameters that I needed for this Storm32 gimbal, put it all back together, and it seems to be working pretty well. No flights yet, but I have no reason to believe it won't fly well.

Thanks guys. Even though I caused this whole thing with some carelessness, I still ended up learning a lot more about the Solo and it was a somewhat satisfying experience.

Aaron

Pedals2Paddles · May 31, 2018

The SSWT button is not a reset button. I don't know where that rumor got started. It is the pixhawk safety switch, which is disabled by parameter. There is no safety switch function that executes a parameter reset.

Flashing another vehicle type completely erases the pixhawk and erases all parameter settings. Flashing the same vehicle type does not erase it and does not overwrite set parameters. So when you've totally pissed it off, flashing plane or rover usually does the trick.

awp0 · May 31, 2018

Pedals2Paddles said:
The SSWT button is not a reset button. I don't know where that rumor got started. It is the pixhawk safety switch, which is disabled by parameter. There is no safety switch function that executes a parameter reset.

Flashing another vehicle type completely erases the pixhawk and erases all parameter settings. Flashing the same vehicle type does not erase it and does not overwrite set parameters. So when you've totally pissed it off, flashing plane or rover usually does the trick.

Thank P2P! That is exactly what I learned to do after some careful research (lift up board, connecting via USB, flashing rover, then flashing ardupilot-solo, then updating parameters to my needs). It worked well, and it made sense after I figured out how all of this works.

just_bruce · May 31, 2018

Pedals2Paddles said:
The SSWT button is not a reset button. I don't know where that rumor got started. It is the pixhawk safety switch, which is disabled by parameter. There is no safety switch function that executes a parameter reset.

Flashing another vehicle type completely erases the pixhawk and erases all parameter settings. Flashing the same vehicle type does not erase it and does not overwrite set parameters. So when you've totally pissed it off, flashing plane or rover usually does the trick.

I stand corrected.

So, what is Solo doing when you hold SSWT down while powering on that causes all the flashing and beeping?