Solo Development Area

[XevetS]

You shouldn't be flashing the Sitescan firmware onto a normal Solo, the Sitescan version uses different ESCs, there's a hard coded power limit in the normal Solo Arducopter so you risk removing that and only bad things will happen if that safeguard goes.

Wait for the official Arducopter Master to be available for Solo, that's far better anyway.

Never heard of this you have proof of what you are stating?

 

[Ian [P13]]

Never heard of this you have proof of what you are stating?

It's been discussed a number of times on the Solo Facebook page, Philip Rowse has discussed this matter, the Solo ESCs could fail causing a brown out, so there was a fix put into Arducopter Solo to hard code less thrust before Solo was launched. Vu has confirmed the SiteScan Solo has improved ESCs to carry a heavier payload so it's likely the hard coded limit will have been removed otherwise there would no gain.

This is one of the key reasons that Arducopter Master wasn't rushed onto Solo as it doesn't have the hardcoded "fix" for the normal Solo ESCs so this will be one of the additions to Master that will be tested.

 

[Ian [P13]]

This is one of the discussions here:

Facebook

 

[XevetS]

fliersguy and I flew with firmware 1.5.2 today--worked great. Standard stuff, nothing too challenging. I give it a big thumbs up!

Hello,

I flashed this to my stock solo Is this going to be a problem, The last post states this firmware update is for site scan solos only, not a store bought consumer grade Solo is this true?

 

[cynfab]

I'd like to see the commits to the 1.3.2-->1.5.2 codebase that implement this.
GitHub - 3drobotics/ardupilot-solo
Not everyone uses Facebook so some won't be able to see the discussions that happen there.
No commits have been made to:
GitHub - SoloSmartDeveloping/ardupilot: Community project to make Solo work with ArduPilot master branch
in 5 months so, where is this development happening?
ArduPilot is GPLV3 so sources should be available.

 

[carpy]

If we are lucky, at some point the devs will create a branch from master for the Solo. However, I believe it will not be for Pixhawk 2--it will be for Pixhawk 2.1. That would be great for the rest of us that will/have bought the Pixhawk 2.1 for Solo and have the ability.
So for now all we have is ardupilot-solo and of course the option of staying on 1.3.1. I for one, want the bug fixes in 1.5.2 and I'm willing to take the risk which I feel after looking at all the code changes is low.

 

[pious_greek]

I

I'd like to see the commits to the 1.3.2-->1.5.2 codebase that implement this.
GitHub - 3drobotics/ardupilot-solo
Not everyone uses Facebook so some won't be able to see the discussions that happen there.
No commits have been made to:
GitHub - SoloSmartDeveloping/ardupilot: Community project to make Solo work with ArduPilot master branch
in 5 months so, where is this development happening?
ArduPilot is GPLV3 so sources should be available.

I have gone through the effort of actively blocking all Facebook content on my network. I suppose I'll reconsider this, but Solo development should be free of Facebook...

 

[carpy]

I think we need a separate Solo Development area under Solo (same level as Solo Discussion)--this single thread is not enough. I'm hoping one of the Admins can make this happen.

 

[Ian [P13]]

I'd like to see the commits to the 1.3.2-->1.5.2 codebase that implement this.
GitHub - 3drobotics/ardupilot-solo
Not everyone uses Facebook so some won't be able to see the discussions that happen there.
No commits have been made to:
GitHub - SoloSmartDeveloping/ardupilot: Community project to make Solo work with ArduPilot master branch
in 5 months so, where is this development happening?
ArduPilot is GPLV3 so sources should be available.

It's happening over on the Ardupilot forum, the code is tied in with the green Pixhawk 2.1 Cube that Philip Rowse is selling as the code will be using the heated IMUs which aren't present in the stock Solo.

If the motor code has been changed as is likely for Sitescan the risk is high. I may check the code tomorrow if time permits.

 

[Pedals2Paddles]

I do not see anything in any of the release notes for 1.3.2 to the current 1.5.2 the indicates it is for Site Scan solos only. I also don't see anything in that FB post stating 1.3.2+ has that modification and is only for Site Scan. I'm not saying it is or it isn't. Just that nothing anywhere says so. I would love to see something conclusive on it. Or see what parameters need to be altered to compensate if that is possible.

 

[Pedals2Paddles]

I flew 3 batteries with 1.5.2 today. It worked great. Except the new distance based battery failsafe sucks. Great thought but not sure WTF it's thinking. I'm in a field within 500-1000ft of the home location. And it's engaging the failsafe at 18-22%.

 

[Ian [P13]]

It's not a parameter it's the motor slew that is hard coded, so that needs checking. Don't expect an obvious release note as the fix was confidential.

 

[Ian [P13]]

The motors on Solo are perfectly fine, the teathered Solo ran over 40 days 24/7 then at NAB so the motors last well past the suggested replacement time of around 150 hours. Any motor pods failures have been due to ESCs and not motors.

It's a FET that is different on the Sitescan Solo ESCs.

 

[Pedals2Paddles]

It's not a parameter it's the motor slew that is hard coded, so that needs checking. Don't expect an obvious release note as the fix was confidential.

I see. It's high power scenarios that are problematic, right? Too much current blowing out the FETs? So in theory, for most more gentle photography flight, it wouldn't be a factor? If I can be relatively confident it's only high power output scenarios that cause it, I'm ok with that. All the other changes that come with the 1.3.2+ firmware are really good stuff.

 

[Ian [P13]]

This was the fix (motor slew rate limiter for current limiting):

Release solo-1.2.3 · 3drobotics/ardupilot-solo · GitHub

So you need to make sure changes haven't happened recently to the following code that could drive the ESCs harder:

ardupilot-solo/libraries/AP_Motors/AP_MotorsMatrix.cpp

There's some discussion here about ESC failures prior to the original code change: enable slew-rate control to prevent overcurrent by arthurbenemann · Pull Request #2 · 3drobotics/solo-esc-simonk · GitHub

 

[XevetS]

I think we need a separate Solo Development area under Solo (same level as Solo Discussion)--this single thread is not enough. I'm hoping one of the Admins can make this happen.

I flew 3 batteries with 1.5.2 today. It worked great. Except the new distance based battery failsafe sucks. Great thought but not sure WTF it's thinking. I'm in a field within 500-1000ft of the home location. And it's engaging the failsafe at 18-22%.

I'm thinking that happened to me

 

[pious_greek]

Ian, are the DF13 connectors different on the sitescan motorpods? Are there any other distinguishing characteristics?

 

[cynfab]

Those changes that you referred to in:
Release solo-1.2.3 · 3drobotics/ardupilot-solo · GitHub
specifically commit # dad46b1ecc26494b7dd4f4817d59a7c9559da338
where this was added:

+ static const int16_t slew_per_step = 6;
+ static const int16_t slew_minimum = 1330;
+ for (i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++) {
+ if (motor_enabled) {
+ _max_motor_out = max(_max_motor_out, slew_minimum-slew_per_step);
+ int16_t max_increment = motor_out - _max_motor_out;
+
+ if (max_increment > slew_per_step) {
+ max_increment = slew_per_step;
+ } else if (max_increment < -slew_per_step) {
+ max_increment = -slew_per_step;
+ }
+
+ _max_motor_out += max_increment;
+
+ _max_motor_out = max(_max_motor_out, slew_minimum-slew_per_step);
+
+ motor_out = min(motor_out, _max_motor_out);
+ }
+ }
+

are also in 1.3.1 which is flying in (almost) every solo as well as 1.5.2.
They happened on 10-16-2015. When 3DR was still in the commercial drone business and updates were coming at reasonable intervals.
1.2.3 was an evolutionary step towards 1.3.1. I am interested in any changes that happened subsequent to 1.3.1 that would effect the ESC operation.

 

[Pedals2Paddles]

Are you saying 1.5.2 has the modified code to prevent burning out the ESCs? Confident or speculating?

 

[cynfab]

Without a strict analysis I can't be sure. but much if not all of the the code referred to in:
Release solo-1.2.3 · 3drobotics/ardupilot-solo · GitHub
is in 1.3.1 as well as 1.5.2.
There are a lot of commits and it will take time to evaluate them all.
That's why I asked about specific commits that related to ESC operation.
I don't know, but some folks supposedly do. I'd like to know too.