Thread Tools
Feb 24, 2020, 04:40 PM
Registered User
dkemxr's Avatar
Is GND_EFFECT_COMP enabled?

Quote:
Originally Posted by jones007
Ah, that makes sense. I forgot it is using Oneshot125.

So I think what seems to have been happening is that it landed but didn't recognize that it was down, and it looks like maybe it was still trying to change position - moving backward, and this effort kept motors 1 and 3 too high to trip the landing detection. The quads look just like long-range freestyle quads, but have the battery on the bottom, and they land on the battery. Sitting on the battery it doesn't take too much effort for them to tip. I wonder if this would have been prevented if I had had more stable landing gear on it. In the end, the damage was a set of props, so $4, but if it had hit people or property in the process of determining that it had crashed, it would be a more serious issue. We've had a few hundred flights, and only had this happen once, but it would be nice to find a reasonable remediation. Is there something else we can set to make it easier to detect landing?
Sign up now
to remove ads between posts
Feb 25, 2020, 01:39 PM
Registered User
Quote:
Originally Posted by dkemxr
Is GND_EFFECT_COMP enabled?
No - it's disabled. I hadn't noticed that feature before. We do have very short gear (none at all really), such that the prop hub is less than a prop radius from the ground. However, the gouge indicates that enabling this might cause issue with altitude estimates if there are high vibes. I don't know what the threshold is for "high vibes," but we do get a fair amount of clipping in high speed flight. I guess we could try it.
Feb 25, 2020, 02:35 PM
Registered User
I'm looking through the landing description more carefully now. Looking at the logs, our reported baro alt at touchdown was around 9m. This was just over a 10 minute flight on a day with pretty moderate temps. That's below the 10m threshold, but not by much. However, looking at the beginning of the log, I see that reported alt at arming was nearly 8m. When we do the swarm operations, we power all the quads on the runway, and then it might be 10 or 15 minutes before we arm. I'm guessing that the alt drift is due to the board heating up while it's on a warm runway in still air. Is there a way to reset baro alt prior to arming to account for drift? It was a cool day. Ambient was maybe 20 C, but temp at arming was about 32 C cooling to about 21 C in flight.

Another question. We had one that performed a secondary battery failsafe landing. Using 3.5.7-dev, we don't have the voltage-sag logic in there for battery failsafe, and to maximize endurance we are using very low-C batteries, so there is huge voltage sag. We're slowly creeping the failsafe threshold voltage down, but we run into problems (both in Plane and Copter), where we are in the middle of a landing procedure (still in auto), sometimes at a pretty low alt, but battery failsafe is triggered, and the aircraft tries to climb back to its RTL alt, which is sometimes several hundred meters up. This will almost always trigger the secondary land-now failsafe. We're trying to figure out if there is a reasonable way to keep it from going RTL while it's so close to the actual landing. Maybe there's something as simple as lowering the failsafe voltage threshold on the fly so that it's basically impossible to trigger it.
Feb 25, 2020, 04:04 PM
Registered User
dkemxr's Avatar
If you are already tuned in to using a -dev version maybe you should try 4.0.4-dev on one copter experimentally. I'm using it on a 5" to play around with in-flight dynamic FFT on the Notch Filter and it's flying OK. There are more choices for battery failsafe and as of today (coincidentally) there is a 1Hz low pass filter on acceleration during landing to improve landing detection. This I have not checked out as it's back to rain/snow here.

Quote:
Originally Posted by jones007
I'm looking through the landing description more carefully now. Looking at the logs, our reported baro alt at touchdown was around 9m. This was just over a 10 minute flight on a day with pretty moderate temps. That's below the 10m threshold, but not by much. However, looking at the beginning of the log, I see that reported alt at arming was nearly 8m. When we do the swarm operations, we power all the quads on the runway, and then it might be 10 or 15 minutes before we arm. I'm guessing that the alt drift is due to the board heating up while it's on a warm runway in still air. Is there a way to reset baro alt prior to arming to account for drift? It was a cool day. Ambient was maybe 20 C, but temp at arming was about 32 C cooling to about 21 C in flight.

Another question. We had one that performed a secondary battery failsafe landing. Using 3.5.7-dev, we don't have the voltage-sag logic in there for battery failsafe, and to maximize endurance we are using very low-C batteries, so there is huge voltage sag. We're slowly creeping the failsafe threshold voltage down, but we run into problems (both in Plane and Copter), where we are in the middle of a landing procedure (still in auto), sometimes at a pretty low alt, but battery failsafe is triggered, and the aircraft tries to climb back to its RTL alt, which is sometimes several hundred meters up. This will almost always trigger the secondary land-now failsafe. We're trying to figure out if there is a reasonable way to keep it from going RTL while it's so close to the actual landing. Maybe there's something as simple as lowering the failsafe voltage threshold on the fly so that it's basically impossible to trigger it.
Feb 25, 2020, 05:58 PM
Registered User
Quote:
Originally Posted by dkemxr
If you are already tuned in to using a -dev version maybe you should try 4.0.4-dev on one copter experimentally. I'm using it on a 5" to play around with in-flight dynamic FFT on the Notch Filter and it's flying OK. There are more choices for battery failsafe and as of today (coincidentally) there is a 1Hz low pass filter on acceleration during landing to improve landing detection. This I have not checked out as it's back to rain/snow here.
The problem we have is that our dev version has some fairly specific code for specialized failsafe behaviors and additional messages. I have a colleague that has been doing doing the coding and merging, but he has so far not been able to get our changes working on anything above 3.5. HHe hasn't looked at it in a while, but I think he is planning to take another stab at it. I'd love to have DShot and the battery IR calculations in ours.

Also, I tried loading a 4.0 in a different quad with Pixracer the other day, and I was unable to get any RC signals from a DSMX sat Rx. Switching to any version 3.X it worked fine. Not sure what is up with that. I'm curious if they have moved to some newer version of serial coms that doesn't recognize the older sat Rx signals.
Feb 26, 2020, 09:27 PM
Registered User
Interestingly, I just loaded AP4.0.4 on an X2.1 and RC works fine. Maybe I need to try AC4 again to see if it's working now.
Mar 24, 2020, 03:38 AM
Still flying
Ramnes's Avatar

Pixracer 2 BLHELI_32 connection


Hi
Im trying to connect BLHELI_32 SW to my DYS Ari 35A ESCs through the Pixracer V15 with teh latest PX4 FW, 1.10.1 which I believe should be kind of PnP, but Im missing something here and cant see what. Can someone please help me?

Pixracer is set to DSHOT1200

Jorn
Mar 24, 2020, 10:47 AM
Registered User
dkemxr's Avatar
So to be clear you are using the PX4 Flight Stack firmware not Ardupilot?

Quote:
Originally Posted by Ramnes
Hi
Im trying to connect BLHELI_32 SW to my DYS Ari 35A ESCs through the Pixracer V15 with teh latest PX4 FW, 1.10.1 which I believe should be kind of PnP, but Im missing something here and cant see what. Can someone please help me?

Pixracer is set to DSHOT1200

Jorn
Mar 24, 2020, 11:19 AM
Still flying
Ramnes's Avatar
Quote:
Originally Posted by dkemxr
So to be clear you are using the PX4 Flight Stack firmware not Ardupilot?
Hi
Yes, thats right. Thought Id try the Qgroundcontrol, but it there is a solution for use with the Mission Planner Ill go back.
Mar 24, 2020, 12:19 PM
Registered User
dkemxr's Avatar
If you mean Ardupilot there is no problem using Dshot but Dshot1200 may not fly. Dshot150 is recommended. I have tried Dshot1200 on the bench with a Pixhawk and strange things happened. 300 & 600 seemed to run Ok but I use 150. Not that anyone would be able to tell the difference...

But anyway I'm not that familair with PX4 but here are the guidlines.
https://docs.px4.io/master/en/peripherals/dshot.html

Quote:
Originally Posted by Ramnes
Hi
Yes, thats right. Thought Id try the Qgroundcontrol, but it there is a solution for use with the Mission Planner Ill go back.


Quick Reply
Message:

Thread Tools