Recent content by Xor

Based on what I see from commits, there is new parameter: + // @Param: GND_PRESS_MIN + // @DisplayName: ground level air pressure minimum + // @Description: If the ground level air pressure is lower than this value, then the copter will not arm. This is used to prevent takeoff at high...

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...

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

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...

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

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...

It is in this commit: ROMFS: Allow use of full ESC output · 3drobotics/ardupilot-solo@60e3ebf · GitHub The comment reads >>ROMFS: Allow use of full ESC output Testing with Solo ESC's shows that saturation occurs at a PWM value of 1870.<< Old value MOT_THST_MAX, 0.940000 New value...

Just read that FB thread, 3rd comment (2nd from Philip) clearly said that because of video title they were thinking it is about ardupilot master, which indeed doesn't have workaround for solo ESC. As far as I got it - our beloved solo has hardware issue with ESC that instead of correcting 3dr...

Rethinking all this gps glitch, failsafe and ekf bugfixes - how is GPS fix working for you? I hope they really ironed out all this kinks when solo loses and not regains fix with 20 sats in view. Unfortunately for me, looks like they extended rains forecast for whole week ahead :(

Hopefully. But need to try that. Say turn on, then put on flat sheet resting on rollers (water bottles for example and try to arm). Would try in few days as soon as weather permits.

I think this is worth adding as well: Ensure RTL to takeoff, not startup location. Prior to this it would record startup location as HOME, now it will record arming location Allow use of full ESC output - This is great if it was fully tested, prior to this PWM range was limited more due to ESC...

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...

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

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?

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...