-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VTail issue on 2.7.1 with LUX & SPF3 Clone #616
Comments
CLI DUMP: versionBetaFlight/SPRACINGF3 2.7.1 May 16 2016 / 20:47:21 (74cd38a)dump mastermixermixer VTAIL4 featurefeature -RX_PPM beeperbeeper GYRO_CALIBRATED mapmap TAER1234 serialserial 0 1 115200 57600 0 115200 ledled 0 15,15:ES:IA:0 colorcolor 0 0,0,0 auxaux 0 0 0 1850 2100 adjrangeadjrange 0 0 0 900 900 0 0 rxrangerxrange 0 1000 2000 servoservo 0 1000 2000 1500 90 90 100 -1 set mid_rc = 1500 rxfailrxfail 0 a profileprofile 0 set gps_pos_p = 15 rateprofilerateprofile 0 set rc_rate = 114 |
blackbox_log_2016-06-27_100139.TXT Blackbox Log |
What you describe is like a hard fault has occurred. Or a loop that never exits. |
How can we diagnose a hard fault? I'm not entirely clear on what would be the trigger. Speaking with my friend and test pilot today, he intimated he suspects that its an issue of noise. In our latest conversation he explained that the build up of noise, user error, bad PIDs or mounting leads to accumulated noise, preventing the closing of the loop and leading to desync issues. With the LUX board, I can see this as the primary source of the issue. It has two points of potential noise; the FC mount and the V itself, which has a direct line to the central chassis. However, with the SPF3 board, mounting is not an issue and the V is carbon vs. 3D printed engineering grade material. The method of testing, for him, is to flip and roll throttling in and out. This seems the most likely way to to reproduce the issue. Do this enough times and it seems to be method for achieving this. For the SPF3 board, I believe we will keep the looptime to 2Khz w. the F396 ESCs. With the LUX, maybe we will limit it to 4Khz. I'm building a third bird now, with SPF3, DYS BLHeli_S 30A ESCs, new 3D material and Rebel 2600kv motors. I'm going to load this with Betaflight 2.9.0 and the latest BLS firmware to see if we can reproduce the issue. As with the previous one, I'll limit this build to 2Khz. |
There is a remote possibility that this could be caused by an integer overflow error in the MWREWRITE PID. I don't think it is that likely, but it is worth checking for the purpose of elimination. Can try retesting with the LUXFLOAT PID to see if you can reproduce the problem? |
@blckmn @martinbudden |
@HorusDrones |
Both birds are mechanically sound however I can't claim to be 100% on the electronic side. That said, I've been reviewing some of the previous release notes and updating myself on the CLI commands and it occurred to me that despite using the Multishot protocol, the unsynced_fast_pwm is OFF and the motor_pwm_rate = 1600. Do you think that there is something happening here? I've seen in 2.8 and on, you added the anti_desync_power_step option. Based on my understanding, could this address any issues assuming that the motor_pwm_rate and unsynced_fast_pwm is set correctly? That said, I've found limited information about what are the proper setting for the motor_pwm rate. With regard to unsynced_fast_pwm, the idea is run it when you're going over 2Khz correct? |
One way in which we can rule out a hard fault is by flashing a LED constantly and at a high rate in the hard fault handler. That way, if it crashes due to a fault (which it shouldn't - but I have seen it before when buffers overflow or similar) then it will sit there with a high speed flash until power is cycled. Thoughts? |
@blckmn @HorusDrones |
@blckmn |
true a good BB log will always help diagnose. I just don't like the symptom of completely unresponsive. It smells of a lock up, like a never exiting loop, or hard fault. Of course there's a thousand possibilities - so I'm probably wrong. |
I am yet to reproduce that on the current code base :). Simply 100% sure it What about rx ;)....power brown out..... true a good BB log will always help diagnose. I just don't like the symptom — |
@borisbstyle I’ll get you new logs ASAP. Any commentary on the motor_pwm_rate / unsynced_fast_pwm question? Or the anti_desync_power_step option? The thing that is most confusing really, is that the motors have full throttle authority, however do not respond to aileron, elevator or rudder inputs. If you’d like to test this out on some actual hardware, I’d love to send you a frame for free. Visit http://www.horus-drones.com and let me know if you’d like a Harpy or Merlin in an email, to vision@horus-drones.com, with your address and I will send you one. |
@HorusDrones |
@HorusDrones , |
Yeah @martinbudden deserves it! |
@borisbstyle @martinbudden Thank you both, I'd love to take you up on it! Having anyone working closely with the code development is a dream come true for me. @martinbudden Send me an email to vision@horus-drones.com with your address and I'll ship out a frame or two to you asap! |
closing this one due to lack of activity. Open new issues if the issue is still there |
I have experienced two crashes due to unresponsive flight controllers using the VTail mix. I've spoken to Dominic about as well, however in these instances when we have been flying acro. While doing flip and rolls, the flight controllers have suddenly become unresponsive to input. This issue does not persist after the crash, which makes it even more interesting. Both frames, after a prop swap and a quick check-up have been flying with the same hardware since. So here are the basics of the two frames this occurred with.
VTail #1 - 250mm, 2600kv motors, DYS XM30 V2 w. Multishot, LUX FC set at 8K with the standard VTail mix.
VTail #2 - 180mm, 2950kv motors, LittleBee Pro 20A w. Multishot, SPF3 Clone, set at 4k with the standard VTail mix.
On both occasions, each airframe had been flying fine, exhibiting no issues during maneuvers, flipping and rolling with aplomb. Then suddenly, on a particular flip or roll, it froze while upside-down and then either dove for the ground or free fell, depending on the angle of the pitch at that moment. Myself and my tester both dropped the throttle and actively tried to get it to respond to yaw, pitch or roll inputs, but no input was exhibited by the airframe. In the most recent incident, he was roughly 120 or more feet off the ground, no rssi issues, nothing of note. The airframe was flying great he was very happy with it, so he goes for another high-rate roll and we all watched as it just locked when he got inverted. He dropped the throttle to roughly 30% and quickly, but not frantically, tried every input he could. Given the height and size he had plenty of time to do this, however it resulted in a crash. Just one broken part aside from the props.
The importance of describing the second incident vs the first is that this happened with VTail #2. Number 2 uses the SPF3 Clone uses the MPU on I2C, whereas the LUX using the 6500 has noise which is often blamed for moments like this (and I believe you have addressed), but is clearly not the culprit if it can be replicated on completely different hardware.
We will be pulling our blackbox to see if we can recover any information, however I wanted to bring this to your attention because we suspect it maybe something within the code (why I also brought it up to Dominic), however I don't know or understand how this would happen with a VTail vs a Quad based on my limited understanding of how the mixing factors in to the PID loop.
Warm Regards
Sherif Manganas
Horus Drones
The text was updated successfully, but these errors were encountered: