Autopilot Firmware Upgrade from 1.3.1 to 1.5.3

[dml931]

does anyone know who the developer is? I have some feedback to give. Took the updated solo for a longer flight just now (to test the RTL on battery low) and the solo went into RTL at around 35% battery. i was only about 250' up and less than 1000' out. i overrode the RTL by hitting the "fly" button and returned to where i was and was still able to fly around some and land at 25% battery. i was under the impression that the 1.5.2 would initiate a RTL when the solo reached a battery level that would allow it to return to home and land with 10% battery left. I also could not disable the low battery alarm even though it was still above 25%.

Or does anyone know the string command that can be edited to accommodate this feature to be more accurate.

 

[Xor]

Has anyone determined if it is on EKF2?

Compared revert commits in ardupilot-solo-rebase, as well as ekf2 and ekf3 in ardupilot master - I'm 100% sure it is EKF1.
solo one is 22 state EKF based on GitHub - priseborough/InertialNav: Inertial Navigation Filter, while ekf2 and ekf3 are 24 state, also based on file structure, is the same as removed ekf1 in master.

 

[Xor]

Or does anyone know the string command that can be edited to accommodate this feature to be more accurate.

35% sounds strange, but right in the second post:
Look for a FS_BATT_CURR_RTL parameter, it is in default params, which is set to 30.000000 at the moment and was bumped from 26, my wild guess would be because it is intended for sitescan with higher payload.
To get idea it should be amps per hour used
// Conversions: 1000 milliamps per amp & 3600 seconds per hour
// home_distance is in cm
// fs_batt_curr_rtl is in amps

 

[dml931]

35% sounds strange,

i thought so too, which is why im requesting to find the developer to inform them of my experience.

35%
Look for a FS_BATT_CURR_RTL parameter, it is in default params, which is set to 30.000000 at the moment and was bumped from 26, my wild guess would be because it is intended for sitescan with higher payload.
To get idea it should be amps per hour used
// Conversions: 1000 milliamps per amp & 3600 seconds per hour
// home_distance is in cm
// fs_batt_curr_rtl is in amps

thank you for this info!

do we know the algorithm used to determine the RTL battery low activation? from what you just wrote, it sounds like its not an algorithm but more of a fixed formula. or did i misinterpret your comment?

 

[Pedals2Paddles]

The developer is 3DR, and they are not taking feedback from the consumer community. Read the second post in this thread (the one that said READ THIS FIRST) for how to adjust that setting. The solo as normally configured uses 19-21 amps in normal flight. The default parameter is 30 amps, which forces it home sooner. It also is designed for the heavier site scan solo which is heavier and uses more power than our consumer birds. Lower the parameter and it will solve your problem.

No, there is no means to disable the annoying low battery once that threashold is crossed.

 

[Xor]

do we know the algorithm used to determine the RTL battery low activation? from what you just wrote, it sounds like its not an algorithm but more of a fixed formula. or did i misinterpret your comment?

It is here: ardupilot-solo/sensors.pde at master · 3drobotics/ardupilot-solo · GitHub

From code comments it is doing this (my note in []):
// calculate mAh required to rise [get difference from current height and required rtl height and calculate using predefined rise speed and fs_batt_curr_rtl]
// calculate mAh required to fly home [based on distance,fs_batt_curr_rtl and predefined rtl speed]
// calculate mAh required to descend to LAND_START_ALT [diff from rtl height and land height by fs_batt_curr_rtl and predefined descent speed]
// calculate mAh required to descend from LAND_START_ALT to ground [land to ground alt multiplied by fs_batt_curr_rtl, LAND_START_ALT is altitude in cm where land controller switches to slow rate of descent, it is set in config as 1000cm = 10 meters from ground]
// sum up required mAh fs

So in nutshell, it uses fs_batt_curr_rtl configured constant (as multiplier) in all this calculations, both for ascend, descend and fly home, of course it is rough.
What strange to me, assumption that current draw during rtl is 30A, means total flight time is 10 minutes with 5200mah battery (which might be the case for sitescan package), on the other hand during last part of flight we see faster battery discharge, will need to play around to find best with and/or without gimbal and gopro.
Unfortunately cannot test new firmware as we got poor weather in north cal at the moment.

 

[Xor]

Read the second post in this thread (the one that said READ THIS FIRST) for how to adjust that setting.

I had no chance to look into tower parameters, but from the code it should be FS_BATT_CURR_RTL instead of FS_CURRENT_RTL isn't it?

 

[dml931]

The developer is 3DR, and they are not taking feedback from the consumer community. Read the second post in this thread (the one that said READ THIS FIRST) for how to adjust that setting. The solo as normally configured uses 19-21 amps in normal flight. The default parameter is 30 amps, which forces it home sooner. It also is designed for the heavier site scan solo which is heavier and uses more power than our consumer birds. Lower the parameter and it will solve your problem.

No, there is no means to disable the annoying low battery once that threashold is crossed.

noted. strait and to the point answers. thanks. BTW, i did read that comment before i started asking questions and posting replies, i guess i just forgot that detail when i posted this last one. my mistake. perhaps you should retitle that to say "READ THIS MULTIPLE TIMES", or "MEMORIZE THIS INFO"

It is here: ardupilot-solo/sensors.pde at master · 3drobotics/ardupilot-solo · GitHub

From code comments it is doing this (my note in []):
// calculate mAh required to rise [get difference from current height and required rtl height and calculate using predefined rise speed and fs_batt_curr_rtl]
// calculate mAh required to fly home [based on distance,fs_batt_curr_rtl and predefined rtl speed]
// calculate mAh required to descend to LAND_START_ALT [diff from rtl height and land height by fs_batt_curr_rtl and predefined descent speed]
// calculate mAh required to descend from LAND_START_ALT to ground [land to ground alt multiplied by fs_batt_curr_rtl, LAND_START_ALT is altitude in cm where land controller switches to slow rate of descent, it is set in config as 1000cm = 10 meters from ground]
// sum up required mAh fs

So in nutshell, it uses fs_batt_curr_rtl configured constant (as multiplier) in all this calculations, both for ascend, descend and fly home, of course it is rough.
What strange to me, assumption that current draw during rtl is 30A, means total flight time is 10 minutes with 5200mah battery (which might be the case for sitescan package), on the other hand during last part of flight we see faster battery discharge, will need to play around to find best with and/or without gimbal and gopro.
Unfortunately cannot test new firmware as we got poor weather in north cal at the moment.

Im eager to hear about your findings once the weather clears for you. and thanks for breaking down the formula solo uses for this feature. it sounds way more complicated that i had imagined in my head originally. thats some pretty cool info though. thanks again!

 

[dml931]

I had no chance to look into tower parameters, but from the code it should be FS_BATT_CURR_RTL instead of FS_CURRENT_RTL isn't it?

just checked mine with tower. its: FS_BATT_CURR_RTL

 

[Pedals2Paddles]

You're right. I'll update my post to reflect that. I'm going to see what my lowered settings yield this weekend too. It will be trial and error to find a setting you like I think.

 

[dml931]

I'm going to see what my lowered settings yield this weekend too. It will be trial and error to find a setting you like I think.

kinda figuring that out now. ima see what 22 does to start, and adjust accordingly from there.

 

[carpy]

Not sure if it was mentioned previously the RTL speed was slowed down a bit in 1.5.2, it went from 1000 to 900.

 

[Xor]

Not sure if it was mentioned previously the RTL speed was slowed down a bit in 1.5.2, it went from 1000 to 900.

I guess we need and compile consumer relevant commits, will try to do it soon

 

[Pedals2Paddles]

I have my RTL speed parameter set rather high. I forget the value, but it amounts to about 28mph. The way I see it, if that failsafe has engaged, I want it home immeidately. There is no reason to dilly dally, and the amount of power required to go that fast is negligibly more. I also lowered the RTL hover time from 5 seconds to 1 second. And increased the climb/descent rates.

 

[speatuk]

I used filezilla (Mac Version)
worked a treat
Don't forget to set port to 22 or it doesn't connect

 

[BigTulsa]

Question...when you say 'reboot Solo', is it hard reboot or soft (hard=Power off of the Solo vs soft=reboot from the App)? Or does it matter?

 

[speatuk]

Question...when you say 'reboot Solo', is it hard reboot or soft (hard=Power off of the Solo vs soft=reboot from the App)? Or does it matter?

Power off solo and the controller.
But as soon as the fw is uploaded it goes through the motions of updating itself, (solo) then the lights flash to say the fw is uploaded just like a factory 3dr update.


Sent from my iPhone using Tapatalk

 

[BigTulsa]

So once the firmware is installed you'll get the tones like I got on my first update (these tones are the same tones a Pixhawk FC usually makes once the firmware is updated). That's when I should do a power cycle then?

 

[dml931]

So once the firmware is installed you'll get the tones like I got on my first update (these tones are the same tones a Pixhawk FC usually makes once the firmware is updated). That's when I should do a power cycle then?

no. follow all the instructions in post #1. after step 6, step 7 says to reboot solo (hard boot - power off and then back on) step 8 will happen AFTER the reboot if you did it correctly.

 

[Xor]

Ok, went through commits gathering data, will copy info from post 2 as well, feel free to copy it (or part) back to post 2.
NOTE: Tried to gather all major things, leaving minor or irrelevant (such as Sony R10C gimbal fixes) out. Highlighted what I think is important, but is not in post 2

• 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. Increase min esc pwm when thrust priority is set.​

• Ensure RTL to takeoff, not startup location

• 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%.
Also reduced RTL_SPEED from 1000 to 900 (in cm/s). Was 22.36mph, now 900 cm/s to 20.13mph. 28mph is 1251.71​

• Arming changes:

EKF: Don't allow ground based magnetic anomaly to fail GPS checks
Add adjustable pre-arm check for minimum air pressure
Do not perform IMU calibration when arming
Allow operation from a surface with large magnetic anomaly​

• EKF:

Don't use IMU2 accel data - Set the accel sensor weighting to be 100% IMU1 and 0% IMU2. This is an airframe specific modification.
Ensure in-flight yaw alignment is performed if over-written​

• PID Changes to pitch/roll [Changed: ATC_LEAD_RLL_R, ATC_LEAD_RLL_W, RATE_PIT_FILT_HZ, RATE_RLL_D, RATE_RLL_FILT_HZ]
• Allow use of full ESC output [Testing with Solo ESC's shows that saturation occurs at a PWM value of 1870]
• Reduce speed in guided mode if uncontrolled height loss occurs
• lock gimbal forward during compass cal, default to RC targeting
• ekf_check: if GPS glitch is active when GPS is regained, set gps glitch mode revert flag

* should prevent vehicle from staying in ALT_HOLD after the following FS sequence:
1. GPS LOST
2. GPS DEGRADED
3. GPS REGAINED
4. GPS RECOVERED​

• State transition on position loss, if mode doesn't require RC and requires GPS, it will initiate set_mode_land_with_pause

• Various GPS Glitch and failsafe changes/bugfixes:

gps_glitch: fs mode change logic for site scan
gps_glitch: allow RC free modes to init even in glitch
gps_glitch: logging gps glitch events
gps_glitch: wait for position_ok before consider GPS glitch cleared
gps_glitch: clear gps_glitch_switch_mode_on_resolve flag after resolving
ekf_check: only use gps glitch mode reversion when ekf_failsafe attempts reversion
gps failsafes: handling of concurrent gps and ekf fs
ekf_check: upon clearing EKF failsafe, do not automatically revert to LOITER if in a battery failsafe
gps_glitch: upon clearing GPS glitch failsafe, do not automatically revert to LOITER if in a battery failsafe​