Open Solo 2.5-RC2 is out

[Pedals2Paddles]

Your conclusion about disarming are reasonable. It should be programmatically impossible for that to happen. The only thing that should cause a disarm in flight is if the crash detection triggers, which would require the copter to be nearly inverted and out of the control. But since the logs end prior to whatever went wrong, all we can do is speculate. And the long loops lead me to speculate it had something to do with that. But again, there's no evidence or log proving it and I could just as easily be wrong. Strange.

I jut did a quick run up test on mine sitting on the deck with the props off since it is raining. And I'm seeing slow loops on mine too. So I don't think it is just you experiencing this.

I've opened a post on the ArduPilot forum for the developers to check out. Slow loops detected in log auto analyzer

 

[Saijin_Naib]

Geez, anyone know what this stuff means.
ardupilot/TestPerformance.py at master · ArduPilot/ardupilot · GitHub

From what I understand, it is parsing through the log looking at timestamps to see how long certain functions are taking to complete, and determining if a certain percentage of them are above an allowable threshold. It looks like some of these things are defined in another file. My Pythonfu is pretty weak, however.

I jut did a quick run up test on mine sitting on the deck with the props off since it is raining. And I'm seeing slow loops on mine too. So I don't think it is just you experiencing this.
I've opened a post on the ArduPilot forum for the developers to check out. Slow loops detected in log auto analyzer

Are the loops the PID controller loops and signaling loops? Do slow loops mean that we're experiencing high CPU load for whatever reason? I wonder if the Pixhawk 2.0 Black Cubes are affected as well... Do I just run the Auto Analyze log function against a dataflash log from my Solo and copy/paste the summarized output here? I didn't note anything alarming in mine other than the motors having a delta between them in RPM.

 

[Pedals2Paddles]

Loops as in the code executing. For example, the main code for flight control runs at 400hz. That's a loop. etc etc. Not PID loops or anything that specific.

 

[XevetS]

Your conclusion about disarming are reasonable. It should be programmatically impossible for that to happen. The only thing that should cause a disarm in flight is if the crash detection triggers

This is from the ardupilot docs,

Radio Failsafe
When the failsafe will trigger
If enabled and set-up correctly the radio failsafe will trigger if:

• The pilot turns off the RC transmitter
• The vehicle travels outside of RC range (usually at around 500m ~ 700m)
• The receiver loses power (unlikely)
• The wires connecting the receiver to the flight controller are broken (unlikely). Note: with APM2 only the ch3 connection between receiver and flight controller will trigger the failsafe.

What will happen
When a radio failsafe is triggered one of the following will happen:

• Nothing if the vehicle is already disarmed
• Motors will be immediately disarmed if the vehicle is landed OR in stabilize or acro mode and the pilot’s throttle is at zero
• Return-to-Launch (RTL) if the vehicle has a GPS lock and is more than 2 meters from the home position
• LAND if the vehicle has:
  • no GPS lock OR
  • is within 2 meters of home OR
  • the FS_THR_ENABLE parameter is set to “Enabled Always Land”

• I noticed in log analyser the error regarding minimum throttle and he was in stabilized mode during the onset of the radio failsafe error maybe a correlation?

 

[Saijin_Naib]

Loops as in the code executing. For example, the main code for flight control runs at 400hz. That's a loop. etc etc. Not PID loops or anything that specific.

Looks like nothing on my Pixhawk 2.0 BlackCube. I wonder if it is something specific to the newer hardware?

Log File C:\...\tmpC02F.tmp.log
Size (kb) 15144.2294921875
No of lines 209462
Duration 5 days, 22:22:28
Vehicletype ArduCopter
Firmware Version solo-1.5.3
Firmware Hash 05a123b0
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Brownout = GOOD -
Test: Compass = FAIL - Large change in mag_field (212.83%)
Max mag field length (766.41) > recommended (550.00)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERRs found: CRASH GPS
Test: GPS = FAIL - Min satellites: 0, Max HDop: 99.99
Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 1.99, WARN: 0.75, FAIL: 1.50)
Test: Motor Balance = WARN - Motor channel averages = [1380, 1426, 1354, 1436]
Average motor output = 1399
Difference between min and max motor averages = 82
Test: NaNs = GOOD -
Test: OpticalFlow = FAIL - FAIL: no optical flow data
Test: Parameters = GOOD -
Test: PM = GOOD -
Test: Pitch/Roll = FAIL - Roll (81.82, line 105068) > maximum lean angle (35.00)
Test: Thrust = GOOD -
Test: VCC = GOOD -

 

[David Boulanger]

Your conclusion about disarming are reasonable. It should be programmatically impossible for that to happen. The only thing that should cause a disarm in flight is if the crash detection triggers, which would require the copter to be nearly inverted and out of the control. But since the logs end prior to whatever went wrong, all we can do is speculate. And the long loops lead me to speculate it had something to do with that. But again, there's no evidence or log proving it and I could just as easily be wrong. Strange.

I jut did a quick run up test on mine sitting on the deck with the props off since it is raining. And I'm seeing slow loops on mine too. So I don't think it is just you experiencing this.

I've opened a post on the ArduPilot forum for the developers to check out. Slow loops detected in log auto analyzer

Thanks Matt. I'm at a loss to figure out why those two takeoffs went bad. The whole purpose of "Baker 6" , now equipped with a HERE is to carry my Sony camera payload. Being that is about $800 worth of camera and lens, I think at the moment I will stick with 1.5.3, Stock non open Solo, and "Baker 5" which it currently flies on. I will tell you that "Baker 7" with open Solo and stock cube running 1.5.3 shows no PM fail.

 

[Saijin_Naib]

I will tell you that "Baker 7" with open Solo and stock cube running 1.5.3 shows no PM fail.

Corroborates what I see in my Pixhawk 2.0 Black Cube Solo. I think we need to do a bit more log digging with others to get the sample size up.

 

[carpy]

I know we are all speculating so I might as well too (Thanks Matt for opening the dialog with the developers so we can get to the bottom of this.)--I still believe that a motor interlock occurred. Just saying...

 

[Pedals2Paddles]

I know we are all speculating so I might as well too (Thanks Matt for opening the dialog with the developers so we can get to the bottom of this.)--I still believe that a motor interlock occurred. Just saying...

That wouldn't explain the logs suddenly stopping in mid-flight before [whatever happened] took place. The logs would show the interlock happen, disarming, and dropping. And continue until powered off.

 

[carpy]

That wouldn't explain the logs suddenly stopping in mid-flight before [whatever happened] took place. The logs would show the interlock happen, disarming, and dropping. And continue until powered off.

Maybe. I use APM Planner 2 to analyze logs (I like it better and because I'm the build guy for Planner 2 ) and it indicates an interlock occurring. But I'm not betting the farm.

 

[carpy]

BTW Matt, just installed the green cube. Outstanding job you and Kelly did. Outstanding. No issues.

 

[XevetS]

BTW Matt, just installed the green cube. Outstanding job you and Kelly did. Outstanding. No issues.

Hope mine goes well gulp, I'm positive it will...

 

[pious_greek]

sounds like another brown out

 

[David Boulanger]

sounds like another brown out

I don't know if a "brown out" would cause the Gopro to stop recording. This is the one thing I noticed that seems to make this all the more confusing. Again the green cube flies great except on my two little crashes as I was taking off. Also after crashing in the grass, The LED light were still green and red up front and flashing in the back as they should be.

 

[David Boulanger]

Hope mine goes well gulp, I'm positive it will...

You should be O.K.. I had some type of freak occurrence it seems. Green cube flies great!!

 

[NightStorm]

This is from the ardupilot docs,
Radio Failsafe
When the failsafe will trigger
If enabled and set-up correctly the radio failsafe will trigger if:

• The pilot turns off the RC transmitter
• The vehicle travels outside of RC range (usually at around 500m ~ 700m)
• The receiver loses power (unlikely)
• The wires connecting the receiver to the flight controller are broken (unlikely). Note: with APM2 only the ch3 connection between receiver and flight controller will trigger the failsafe.

Interesting coincidence, reading through this thread tonight and I had just seen this show up on my transmitter earlier today (I'd never seen it before).

Quick recap: I got my bricked Green Cube working (never did see anything show up on how to un-brick the green cube, so I fiddled around with a USB cord, Mission Planner, and an autopsied Solo on my Frankenstein bench until a heartbeat was restored).

Anyway after about 5 or 6 flights I tried a smart shot. Switched from Video to Photo, selected a Pano, and instant "Radio Failsafe" when I hit the "Select" in Solex. The thing started an RTL, the Fly button would not take it back, and it started its descent. Eventually I tried "A" (manual) and that worked. Once A had been hit "Fly" was again responsive.

I may give Pano a try again later in the week (100% chance of rain forecast for tomorrow).

 

[Pedals2Paddles]

Using which app?

 

[carpy]

Using which app?

Solex. ("...when I hit the "Select" in Solex.")

 

[Pedals2Paddles]

BTW Matt, just installed the green cube. Outstanding job you and Kelly did. Outstanding. No issues.

Thanks! Glad it's working!

Anyway after about 5 or 6 flights I tried a smart shot. Switched from Video to Photo, selected a Pano, and instant "Radio Failsafe" when I hit the "Select" in Solex. The thing started an RTL, the Fly button would not take it back, and it started its descent. Eventually I tried "A" (manual) and that worked. Once A had been hit "Fly" was again responsive. I may give Pano a try again later in the week (100% chance of rain forecast for tomorrow).

Please definitely try again and report if it repeats. Hard to tell if it's an Open Solo issue or a Solex issue (or both interacting badly) since Pano I think is totally run by Solex.

 

[cynfab]

Matt,
Regarding slow loops, I have AC 3.5.3 and OpenSolo running on my PixHawk 2.0 with 5V mod. I also have run (and flown) it with the exact same OpenSolo but with AC 1.5.3. I see NLon of under 150 with 1.5.3 during a 15 minute flight. With 3.5.3 I see 450-550 just sitting on the ground with sats acquired and no motors running. I have repeated this on 2 non-flights with 3.5.3 and it is consistently between 450-550.
I don't think the slow loop issue is with the Green Cube hardware.
If it were not snowing I would try flying 3.5.3 and dumping the logs. Maybe tomorrow...;>))