Autopilot Firmware Upgrade from 1.3.1 to 1.5.3

[carpy]

Please use Open Solo to upgrade your firmware to 1.5.3. I will leave these instructions here in case you do not have Solex/SidePilot and want to upgrade just the firmware.
documentation/README.md at master · OpenSolo/documentation · GitHub

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!

 

[Pedals2Paddles]

READ THIS BEFORE ASKING A QUESTION PLEASE

This is the firmware on the Arducopter based Pixhawk in the solo. This is what controls the motors, takes inputs from the sensors, compass, GPS, etc, and manages stable flight. It is the same device many of use use in our DIY drones, with some solo specific modifications.

This is not the same thing as the updates you get via the app updates. Those updates contains this firmware as needed, and also update the companion computer, controller, and gimbal. That is not what this is. Put simply this Pixhawk firmware has absolutely nothing to do with smart shots, geofences, flight modes, GoPro control, gimbal control, video, photos, etc. So please do not ask if this will do anything for any of those aspects. The answer is no.

No, this is not Arducopter master. This is a 3DR solo specific version of Arducopter 3.2. It is not AC3.3, 3.4, or 3.5rcx. It contains updates and improvements to the current production release of the Solo version. 3DR has not pushed this out to it's consumer customers, but it you are not locked out from doing it yourself.

So what improvements does this give you? Many wonderful things!

• Improved landing detection. This greatly improves the solo's ability to detect it has landed. In the past, it could get confused by a rough, fast, or jerky landing. This results in it refusing to disarm or and sometimes flipping over. The new landing detection algorithm is greatly enhances. You will notice it now takes and extra second or so to disarm once you're on the ground. And you may see a little switch in the throttle. It is literally testing the ground. It works quite nicely.
  
  
• Low battery thrust priority. If the battery is getting dangerously low, it will allow itself to sacrifice yaw (rotation) control to increase thrust to prevent a crash. This could give you the thrust you need to land softly rather than dropping out of the sky.
  
  
• Distance based battery failsafe. It can now compute how much time it needs to get back to a safe landing at the home location, compare to how much battery is left, and execute the RTH failsafe based on that. The parameter defaults will calculate it based on having 10% remaining when it lands. You will notice the failsafe kicks in at 17-19% now rather than 9-11% like before. This is because it is trying to get back to a landing with 10% remaining rather than 0% remaining. You can adjust this by change the FS_BATT_CURR_RTL parameter with the Tower app or Mission Planner. It's default is 30. Reducing it to 22 or 25 will extend the flying time before failsafe, making it land at less than 10%.
  
  
• Will not lose altitude by going too fast in Follow Mode! In Smart Shots, the solo will not allow itself to go "too fast" causing a loss of altitude. Prior to this, you could go too fast, say following a moving car, and the solo would try to keep up, sacrificing altitude in the process. That will no longer happen. It will recognize it is losing altitude and back off the speed to prevent it. So for example, if you're doing a follow smart shot and start driving too fast, it will fall behind instead of crashing into the ground.
  
  
• Misc minor tweaks and adjustments to various parameters and code that probably aren't noticeable or "features". Just basic behind the scenes improvements.
  
  
• Anecdotally, I think it is remarkably more stable. I've burned through 6 batteries with this and noticed the video was the most smooth and stable I have ever captured with the solo. I cannot relate that to specific change in the firmware because I didn't write it. But I love it.

 

[cynfab]

carpy & P2P,
THanks for posting these notes and especially having the intestinal fortitude to actually try 1.5.2 on your Solos.

 

[pyrate]

Wow nice work
Not even a try at your own risk, or we are not responsible for any damage
that is confiedence

 

[IMP Concepts]

One thing I would do is rename the file to something more definitive such as: ArducopterSolo-V2.px4.

 

[Xor]

Is there is a reason to go with 1.5.2 over 1.5.3?
Releases · 3drobotics/ardupilot-solo · GitHub

 

[dml931]

flys great with the 1.5.2. just updated on my guinea pig solo and took it for a quick flight (<5min). flew as expected but i did notice the addition time to disarm the motors like mentioned above. am curious about the 1.5.3 that Xor mentioned. the github site doesn't list too many details about each release.

 

[Xor]

flys great with the 1.5.2. just updated on my guinea pig solo and took it for a quick flight (<5min). flew as expected but i did notice the addition time to disarm the motors like mentioned above. am curious about the 1.5.3 that Xor mentioned. the github site doesn't list too many details about each release.

Good to know, thanks.
On GitHub it says 1.5.3 is prerelease, but only changes from 1.5.2 is tone changes from b# to a# codes, with mention of imu3 might be some harmonic that affects it, anyway if 1.5.3 is supported I would go with it.

 

[Pedals2Paddles]

I would hold off on 1.5.3 since it is still in pre-release.

 

[Xor]

I would hold off on 1.5.3 since it is still in pre-release.

Considering only changes there are tone codes, it should be safe to use. Only question is if it is supported per 3dr.
If they did it so tones would not affect imu3, I guess there is a reason for that.

Here is the diff between 1.5.2 and master:
Comparing solo-1.5.2...master · 3drobotics/ardupilot-solo · GitHub

 

[Pedals2Paddles]

It's not what it changes that concerns me. It's that they apparently haven't tested it readied it for production release. I do not know what 3DR considers pre-release and what makes it different than a production release. Since I don't know, I can't recommend it.

 

[Xor]

It's not what it changes that concerns me. It's that they apparently haven't tested it readied it for production release. I do not know what 3DR considers pre-release and what makes it different than a production release. Since I don't know, I can't recommend it.

I would agree with you, but commit was made for a reason, checking ardupilot master shows same changes in pull request which states:
Reduce the risk of the buzzer affecting IMU's during the battery alarm #5648

Sounds like useful commit to me, will need to check what is on our current firmware

 

[User Name]

Sounds like useful commit to me, will need to check what is on our current firmware

I don't think Paddles disagrees that it sounds like a useful change, the issue is more that it hasn't been tested sufficiently enough for 3DR to classify it as a production release. The EKF changes a while back seemed like useful improvements, but upon release, they sent several Solo's out of control and at least one through someone's window.

 

[pyrate]

aint that the truth
I have been trying to figure out if this new firmware is still on ekf 1
if it is I might be tempted to try it, but if it moved over to ekf 2 I aint touching it, I will wait on master

 

[Pedals2Paddles]

Exactly. I just want to know what 3DR defines "pre-release" as. If all it means at this point is they haven't packaged it with an update to be pushed to the Site Scan Solos, then I'd be content using it. But if it means they're still doing testing and troubleshooting, then I would want to wait.

Also, I'd like to note the actual nature of it gave me chuckle. The stupid battery beeper resonates at just the right tone to possibly affect the IMU. I wonder how they came upon that one after all these years,

 

[cynfab]

Looking at the 1.5.2 code and the last update of the ardupilot-solo-rebase code, I grepped for EKF2.
Here is what I found:
The rebased code is full of references to EKF2 whereas the 1.5.2 code has a few references to EKF2 mostly dealing with logging.
So I would bet that teh 1.5.2 code uses EKF1 only.
Check out the 2 attached files.

 

[Xor]

Going through commits fr 1.3.1 - 1.5.3, one commit bothers me:
AP_NavEKF: Don't use IMU2 accel data · 3drobotics/ardupilot-solo@6a52bd6 · GitHub

AP_NavEKF: Don't use IMU2 accel data

Set the accel sensor weighting to be 100% IMU1 and 0% IMU2. This is an airframe specific modification.

And in the code:
// Force weighting to be 100% IMU1. This is an airframe specific solution to solve problems with the airframe vibration spectra and the lsm303d sampling
IMU1_weighting = 1.0f;

So, basically 3dr did not trust IMU 2 accel due to vibrations and sensor sampling... FFS...

 

[David Boulanger]

So it sound like all are happy with 1.5.2?

 

[carpy]

Yes, it's much better than 1.3.1 and it's all we have right now until PH2.1 comes out.

 

[pyrate]

Has anyone determined if it is on EKF2?