Tridge,
Today we had a similar mishap with our plane. Unfortunately it ended in crash
On the first flight after takeoff in manual mode the plane took a nose down attitude and did not answer the command deep (we attribute to a human pilot error). We were able to repair it.
We check everything on earth and apparently worked quite right. We did procedure to reach the radio, we check each connection, the CG, and all good.
We left in manual mode and eleven seconds later the plane crashed.
The human pilot and two people reported missing command.
When analyzing the telemetry we find that the autopilot gave the correct signal output as it will indicate the radio.
We are misplaced with behavior.
We use the plane for quite some time and never reacted this way.
We have a similar plane to X8 Skywalker with PX4 FMU and IO APM: Plane 3.2.0 released.
cheers,
Martin
Post the .bin or .log
Hi
We had a very similar issue with the 3.2 pixhawk but it was like a tail heavy. We flew for 10 minutes without any problem but suddenly the plane starts to behave as tail heavy and we were not able to control it even in manual mode.
After a difficult landing, the CG was 100% correct.
We are not able to identify the issue.
Here it is.
@martin,
Either your attached file is invisible or you did not attach it:-)
You attached a tlog to your first post, maybe you can attach a data flash log to a new post.
Regards,
TCIII GM
Hi John and Martin,
I just wanted to let both of you know that I’m not ignoring you. I have looked at the logs both of you posted, but as yet I can’t see anything wrong.
For example, here is a graph of the RC input and servo output for Martins flight:
uav.tridgell.net/ManualFailure/martin_manual.png
as you can see, chan1 in and chan1 output match exactly, as does chan2 in and chan2 out. Given this plane is using “old style” elevon mixing that is exactly how it should be in manual - it copies what the transmitter sends straight to the servo outputs.
So just looking at the log it looks like everything worked perfectly. That doesn’t mean I’m doubting what you are saying, it just means we need to find some other way to debug this.
I think we should concentrate on trying to reproduce this on the ground. The ArduPilot code should not be behaving any differently on the ground to in the air when in manual mode. When someone tells me that it does behave differently I usually think about the following possibilities:
- battery voltage dropping when under load (motor running) and affecting receiver or servos in some way
- something heavy (like battery) shifting in the plane
- a pilot induced stall
Can you make sure you’ve eliminated these simpler explanations?
If those are eliminated then we’re looking at something pretty strange! Can you try doing ground tests with the motor running? What about with transmitter in low power range test mode? With air blowing over the airspeed sensor?
What I’m trying to do is suggest ways you can reproduce the problem without crashing again. If you can reproduce it perhaps we can work out what is going on.
Cheers, Tridge
Tridge,
Thanks for your Recommendations.
We have an another plane for as soon as possible start With The ground tests.
Regarding the accident, we saw exactly the same in the logs, which worried us even more, because for us it was clearly a loss of control, or a delay in the response.
We will perform all tests and publish the results
Cheers,
Martin
so, this all happened in Manual mode ?
What exectly should I try to reproduce , what scenario do you think caused it ? (low airspeed etc?)
I think my case fits on this post.
Today I went test my arduplane on my super tested EPO Cessna. First of all, say I flown about more than 200 times with this plane, I know she reacts to stick movements and was think is best option to start, well know airplane, perfectly trimmed.
Well, I tested radio on ground, on manual and stabilize modes, all moves as expected. Check GC, put on runway, wait until gps is locked and go to the air.
After take off, I feel she not flight as expected, moves more aggressive than usually does. Trying to turn, she starts to move violently, reacts to stick movements but something is wrong, like servos moves twice, really can not find words to describe how she feels. After try to stabilize (all flight on manual mode), finally starts to lurch and crash.
On my house, I do some research: On logs and every radio input overlaps with radio output (must to be). I do another test (thinking servos moves more than before put ardupilot), on receiver´s channel 1 connect parallel one servo and ardupilot, then put added servo side by side airplane servo and move on radio alieron stick. I see servo connected to arduplane is slower and moves little hopping.
There is a way to correct this?
Yes, dont fly in 3.2! I have been testing aircraft and setting ailerons on the desk for 20 min in manual mode. Then I noticed that rc control has some serius lag. I tested it. On fast movements - it even dont move the ailerons or elevator. Lag was about 0,5 seconds. Maybe more. When I removed power and reconnect battery again - it worked again normal and fast. It must be some software issue.
I was so lucky that I saw that post and saw this bug on the ground. My new aircraft would be pancake by now.
Hi Drashiel and FPVSLO. I’m interested in chasing down the problems your both reporting. Any chance you have the logs and can post those so I can download them and have a look? It would also be great to know what APM hardware you are using? Are the Pixhawks or something else? And what version of the APM software you have on your hardware.
@Drashiel - When you fly on Manual mode the RC input’s effectively go straight to the servo’s. The APM software does nothing. The problem your describing could be a power issue - how are you powering the APM in your aircraft and your servos?
As for connecting CH1 from your receiver to both a Servo and APM I have never thought of doing that and I’m honestly not sure what would happen but its an interesting test - I will also do this and report back what happens.
@FPVSLO - I haven’t personally seen any lag when I do bench testing. You do need to give the APM a few seconds to start up. When you say you removed the power and reconnected again did you change anthing else? Can you replicate this issue? Does it occur randomly? So you plug and unplug a few times and it occurs perhaps 3 times out of 10 or something like that?
Thanks, Grant.
I noticed this lag only after running pixhawk long time in manual. Like 20 min.
It all worked ok for first 10-15 min as I was setting ailerons on the bench. Then servo become lagged with quick movement. It was like this - move stick - nothing happens - quick servo move after 0,5 second to required position. If moving stick very quickly - servo did move at all.
It should be difficult to fly if this happen in air. As I was testing this - I think only way to save aircraft - very gentle movement on sticks.
After reconnect battery - lag immidiately disappeared.
I had at the time:
Pixhawk firmware 3,2
airspeed sensor (pixhawk digital model)
no telemetry (USB connection only)
buzzer
switch
I2C extension
USB extension cable
No video transmitters on board. Just servo connections. Pixhawk was new - no previus firmware.
I did not try to replicate - just reload version 3.1.1.
I will post log later.
[quote=“gmorph”]Hi Drashiel and FPVSLO.
You do need to give the APM a few seconds to start up.
Thanks, Grant.[/quote]
it worked ok after startup for more than 10 min.
No.
I did not try to replicate as I need to wait more that 10 min to even try. After startups it is ok.
@FPVSLO,
So you are powering your Pixhawk on the bench with the USB cable.
I assume that you are using a BEC to power the servos on the Pixhawk servo output power bus rails while powering the Pixhawk with the USB cable?
Is the BEC output voltage 5vdc or a higher voltage?
Do you have the recommended 5.6vdc zener diode across the BEC input to the servo output power bus rails? http://plane.ardupilot.com/wiki/common-pixhawk-overview/#Powering
Are the servos analog or digital?
Regards,
TCIII GM
[quote=“TCIII”]@FPVSLO,
So you are powering your Pixhawk on the bench with the USB cable.
I assume that you are using a BEC to power the servos on the Pixhawk servo output power bus rails while powering the Pixhawk with the USB cable?
Is the BEC output voltage 5vdc or a higher voltage?
Do you have the recommended 5.6vdc zener diode across the BEC input to the servo output power bus rails? http://plane.ardupilot.com/wiki/common-pixhawk-overview/#Powering
Are the servos analog or digital?
Regards,
TCIII GM[/quote]
It was powered with USB cable, 3DR power module and BEC. Servos are simple analog mini servos. Note, that this was on the bech - no aerodynamic load on servos.
No zener diode on BEC input.
log is here:
dropbox.com/sh/ayhxsbibuk0e … Pamba?dl=0
I noticed some strange thing - maybe look ch1 in ch1 out. I maybe try to replicate and post video.
@FPVSLO,
I would recommend installing the zener diode across the Pixhawk servo output bus power rails as there have been several reported crashes where servo induced spikes (>5.6vdc) on the servo output bus power rail caused the Pixhawk to reset.
Regards,
TCIII GM
[quote=“gmorph”]Hi Drashiel and FPVSLO. I’m interested in chasing down the problems your both reporting. Any chance you have the logs and can post those so I can download them and have a look? It would also be great to know what APM hardware you are using? Are the Pixhawks or something else? And what version of the APM software you have on your hardware.
@Drashiel - When you fly on Manual mode the RC input’s effectively go straight to the servo’s. The APM software does nothing. The problem your describing could be a power issue - how are you powering the APM in your aircraft and your servos?
As for connecting CH1 from your receiver to both a Servo and APM I have never thought of doing that and I’m honestly not sure what would happen but its an interesting test - I will also do this and report back what happens.
Thanks, Grant.[/quote]
Dear gmorph,
It is a strange issue, was my first flight on apm and airplane was complete unresponsive, mount ardupilot (not pixhawk) on another plane (easystar) and downgrade to version 3.1.1 and works much better. Servos moves on ground but not same as connected directly to receiver, movement is not “consistent” as connect servo to receiver. I have two power supply, one for servos and radio and another to apm and receiver board, airplane responses but not as usual this make me think power is correct but something on the code not work must to be.
I attach bin file of crash, interesting part is in the beginning because she only flew one or two minutes before crash.
Sound like the same problem, i alreade posted this in another thread. :
I think i just crashes my Go discover due to this problem.
Did a groundcheck everything was ok, went up in the air and after 10 seconds or something the plane was reacting very slow to command. it flipped inverted and i was not able to recover it.
After the crash i checked and i saw that my elevons only moved a few mm’s …
This is why i could not recover it…
This was on 3.2.2, i now updated to 3.2.3 and the problem dissapeared…
I am seriously afraid to fly with the APM now.
Any ideas someone ?
It looks like all the people with these problem fly delta’s ( Elevon related problem )
Edit - ignore that, I misread your firmware version numbers
I don’t want to hijack this thread but i think we are having the same problem.
Here is my log file.
If anyone could have a quick look that would be great.
flight starts at 44%, after take off i did a right turn and then it went out of control…
After the crash i checked and found that the aileron almost didn’t move…
Went home, connected it again, same problem, updated to 3.2.3 and the problem is gone.
But wil this happen again ? Because this was the end result 
