Autopilot Firmware Upgrade from 1.3.1 to 1.5.3

[Spawn32]

Hi carpy,
Yes i know, since i was involved in asking 3DR nicely if they could release the current kernel to the public, witch Mr Vu Tran did (really hope more will be released in the future) , the one that was public was very old, btw, if you compile the latest master it's newer than 4176d57
Before i talked to Mr Tran we only had commit 3f15a11

All details are in Compiling additional drivers for Solo USB port

But, i was not talking about the IMX6 / Artoo lower board here, i was talking about the ARM / stm32 board / upper board (dont think it's got another public name) that controls your lcd screen / buttons / sticks.

a copy of the binary for the ARM / stm32 board actually is located in the linux part, and there i also a command for upgrading the arm board from telnet in linux.

 

[carpy]

Hi carpy,
Yes i know, since i was involved in asking 3DR nicely if they could release the current kernel to the public, witch Mr Vu Tran did (really hope more will be released in the future) , the one that was public was very old, btw, if you compile the latest master it's newer than 4176d57
Before i talked to Mr Tran we only had commit 3f15a11

All details are in Compiling additional drivers for Solo USB port

But, i was not talking about the IMX6 / Artoo lower board here, i was talking about the ARM / stm32 board / upper board (dont think it's got another public name) that controls your lcd screen / buttons / sticks.

a copy of the binary for the ARM / stm32 board actually is located in the linux part, and there i also a command for upgrading the arm board from telnet in linux.

Hmm...I understand now. The guy that writes to the 3dr-stm32 log file...Hmm.

 

[Xor]

I see a lots of speculations and miss understanding about this topic, so i have to ask Is this is a confirmed info ? can You give some source ?


One more thing, i think about it, and we do not know why exactly developers change this MOT_THST_MAX parameter, maybe higher value is needed for some other functionality works correctly, and You can't see it in straight way and can't assume that if will affect only ESC and nothing more. So lowering this parameter can cause more problems than props. it's just my thoughts.

OK, what kind of source do you want? We know for a fact that sitescan solo uses different ESC, confirmed by sitescan owner in FB post.
There been a lot of hints that there is an issue. Yes, 3dr never admitted it directly, but that commit comment clearly shows that there is ESC saturation, everyone who knows for sure did hint us more than once. Allowing more pwm range means ESC will ramp motors to higher RPM (more current, faster channels switching), if there is hardware issue it can fry. Now, about that particular commit as I said it might be that they tested on out solo ESC or sitescan.

 

[Jubalr]

If you are worried about it, just lower the PWM range to existing FW level.

 

[pious_greek]

How does PWM signal saturation fry an ESC?

 

[RichWest]

We know for a fact that sitescan solo uses different ESC, confirmed by sitescan owner in FB post

I only read that he was "told" the ESC had been changed, yet no pictures to confirm. Has this been updated?

 

[Xor]

How does PWM signal saturation fry an ESC?

Well, might be not fry but brownout and nasty crash cause of that. Pwm is just control signal that at the end controls what current and switching ESC do, too much current that motor can handle usually results in heat, too much that ESC can handle results in fry or brownout

 

[Xor]

I only read that he was "told" the ESC had been changed, yet no pictures to confirm. Has this been updated?

I do not think he would open his 12k under warranty bird to confirm that for us. That was only public confirmation as far as I know.
On the other hand consider 3 things, 1. We know that solo ESC (or maybe even sitescan ESC) has saturation, so it is not working up to 100% 2. We know that sitescan is heavier than our solo with go pro that puts higher load on ESC. Logically there are only 2 ways, keep as is and sitescan will have poor performance or update ESC.
3. It was said more than once that ardupilot master doesn't have solo ESC workaround patches and will brownout or fry them, it is only case with flight controller that I know requires fixes for ESC.
For me number of hints + that sitescan user was told that ESC is updated are enough to come to conclusion that our solo ESC has a problem.

Now as I said, that particular parameter might be tested on consumer solo and completely safe, it is up to you to keep it at 1.3.1 or 1.5.x level.
It is a shame how 3dr handles such things, I would expect them to come up and either disprove or confirm this issue.

 

[pyrate]

I would be really surprised if they made a true hardware change

 

[Bilge]

So Xor,

With all of your research & commentary regarding this subject, what are you set at .....1.3.1 or 1.5.x.....???

just curious !!

 

[pious_greek]

There is so much illogical, unfounded and unsubstantiated speculation about a parameter and programmer's note that @cynfab already identified a week or a two ago with a saturation point that's been known for a while.

Every ESC has it's own throttle calibration and programming. The simonk ESC's have a default range set with stop at 1060us and full throttle at 1860us.
My testing as well as @RolandS888 testing of the 3dr solo ESC's seems to confirm that the default range is used on the solo as well.

If the signal gets saturated, I imagine the motor stops spinning, perhaps a FET gets blown but I have not tested this and I imagine this is a problem with any ESC. Maybe there are others who have programmed and calibrated ESCS and know better?

Obviously, the solution is to confine the range of the signal generated by the solo or any other flight controller. This does not seem to be a conspiracy or failing that needs to be hidden by NDAs.

If you're concerned about the increased value, return it to the old value as @Jubalr stated.

You are not voiding your warranty removing a motorpod to take pictures, and if you are flying with a part 107, as you probably are with the sitescan model, you probably ought to remove your motorpods and inspect them regularly and log that.

 

[Xor]

1.5.3 at the moment, but only got few short flights due to rain.

 

[Xor]

This does not seem to be a conspiracy or failing that needs to be hidden by NDAs.

You are not voiding your warranty removing a motorpod to take pictures, and if you are flying with a part 107, as you probably are with the sitescan model, you probably ought to remove your motorpods and inspect them regularly and log that.

I agree with max pwm in general, in our case there were written in plain that due to ESC problem ardupilot master would put stock solo in immediate danger. I would think that code designed to run all this different hobby ESCs would have no problems if it was only max pwm.
Nda is pure speculation as everyone involved was declining to comment on specifics

 

[David Boulanger]

I just flew 1.5.2 for the first time today. Although I haven't compared 1.3.1 parameters to 1.5.2 it is much smoother. Whether its PID's or Filter rates I don't know. Super smooth and stable. No wobbles or slight oscillations like I used to get.

 

[Bilge]

I have flown several flights now with 1.5.2.....seems smooth to me as well.....manual disarming at the end takes a few more seconds thou.....

Carpy's Smart Shot Sphere Pano mod worked great as well.....

 

[kush61]

A few of us have upgraded and tested the latest release of the Autopilot firmware. Follow these steps to manually upgrade your firmware on the Solo from a computer running Windows with WiFi:

1. Download the firmware, ArduCopter-v2.px4. Use firmware tagged 'Latest release'.
2. Download and install FileZilla or WinSCP.
3. Turn on Solo and Controller.
4. Connect to Solo's WiFi network from your computer (similar to how you would connect your phone to it via the app).
5. Launch FileZilla or WinSCP and connect to Solo using it's IP address '10.1.1.10' for the Host and 'root' for the Username and 'TjSDBkAu' for the Password. Use port 22.
6. Copy/transfer the firmware to /firmware on Solo.
7. Reboot Solo.
8. After reboot the LED's on Solo should change colors (party mode).
9. Accomplish a Level Calibration.

Enjoy!

Can someone help me here?
I cannot connect my cellphones wifi to my Solo after updating to firmware 1.5.2 .
In step #6 (above) , where is the correct place to upload the unzipped firmware files using FileZilla?
I unzipped the files into a folder named "Solo Firmware" and uploaded that folder into the "firmware" folder of Solo.

 

[carpy]

Can someone help me here?
I cannot connect my cellphones wifi to my Solo after updating to firmware 1.5.2 .
In step #6 (above) , where is the correct place to upload the unzipped firmware files using FileZilla?
I unzipped the files into a folder named "Solo Firmware" and uploaded that folder into the "firmware" folder of Solo.

You should put the firmware file only on Solo in /firmware--not a folder.

 

[kush61]

Hello and Thank-you...

Is it a single file I need? What is that files extension?
When I unzipped the download there were about 200 files extracted. Most of them with an .h extension.

 

[dml931]

Small issue I discovered. Bare with me for a min while I try to explain everything.

My Solo is running 1.5.2 (just havent updates to .3 yet.) and Im driving thru the Rockies in CO. I pulled off to fly the solo at a nearby RC airfield and upon everything connected, and ready to fly, the motors wouldn't arm. The controller had a 0.7 HDOP and was "ready to fly". Neither Fly or Manual Fly would work. I was using an Nvidia Shield K1 tablet with the Solo APP. Each attempt to arm the motors resulted in the solo arm fail tone. I then tried Tower which connected fine. Upon an Arm motor attempt with tower, the solo arm fail tone continued but the error Tower produced was "Altitude launch ceiling exceeded". I was just over 9k' elevation near a lake.

I searched only for the parameter that controls this AFS and found one in the Pixhawk parameter list. Upon searching for the same (or similar) parameter with Tower in the solo parameters, nothing could be discovered. I then contacted 3DR support and asked them which parameter controlled this and/or which altitude is the ceiling. I never received this info but was told that I'd need to factory reset the solo and controller, perform the mandatory update, and then attempt again.

I don't want to revert FW back to an older version honestly, but the tech said that v1.5.2 was the cause of this symptom.

Does anyone know what the actual launch ceiling is? And which parameter controls this FS? And if it's even editable in Tower, or do I need another application to get to this parameter?

Thanks in advance.

PS, I ran searches for this, and read this entire thread. Could not find anything that way.

 

[carpy]

Hello and Thank-you...

Is it a single file I need? What is that files extension?
When I unzipped the download there were about 200 files extracted. Most of them with an .h extension.

You got the wrong file. It's this one.