Don’t know if this is the place but px4 just flew away with no response from input at all.Rejecting rtl and all other failsafes.The bad bit is the full throttle on 500w motors when close to the ground against a wall , it could have seriously hurt someone.
Hi @battlepenguin, thanks for reporting this and sorry to hear about the crash! We certainly would like to fix that. You could help us with that by providing the log file of the flight as well as detailed notes about the flight. So did you change anything? Was anything suspicious? What happened and how did you react? What were the error messages? Thanks.
Sorry , the cheap card that came with the pixhawk had a totally corrupt file system after. What concerned me at the time was that whilst flying away it refused to disarm and rtl (all reported to qgc at the time. It said rtl , posshold rejected ,disarm rejected due to being in wrong mode or something like that.No manual response in acro or stabilise. Now I realise that disarm is not a kill switch. Maybe that could be made a little clearer in the documentation.
The other thing was that after it hit the garage it fell then went full throttle whilst vertically pressed against a wall and a branch, until the battery ran out. Maybe some kind of sanity check is needed or perhaps the pixhawk had crashed completely by then.
I have since found that the external gps mag was in 100% fail but still. Other than that it is now the same as before the crash. I have successfully used arducopter with the 250mm emax rs2205 little bee fvt 30amp + gps frame for some years . The only different thing is the pixhawk is mounted firmly in soft urethane foam and runs px4. I guess it is yet another faulty pixhawk some how. It gives no errors or warnings from the hardware in qgc which was connected. It was poorly tuned but flew nicely in stabilise mode. I think I will go back to arducopter as it is very hard to tune nicely for acro and seems to have inconsistent flight characteristics. On that frame I use very low pids always. 0.09 0.09 0.0004 similar in arducopter.
You should make the logs available to users more easily also! and reduce requirements for the sd card. It all makes it safer.
If anything else turns up I will post it here.
Just remembered that the battery was not completely ran out so the pixhawk must have regained sanity at that point.
Thanks for the feedback.
If it says POSHOLD rejected, than that likely means either strong mag interference or no GPS because the estimator does not have a confident position estimate anymore.
Yes, the kill switch should always work but disarm only works in manual mode or in other modes when land is detected.
It’s documented here: https://docs.px4.io/master/en/config/safety.html#safety_switch
but maybe a note about how normal stick disarming works (and when it doesn’t work would be good).
I agree, a crash detection would be nice. It’s always a bit tricky not to produce accidental false positives.
It’s on the list of feature requests but no one has taken it on yet unfortunately.
This is odd. So basically the mode switch was still working but not the controls?
I wonder if this is the same issue as others have been seeing with v1.9 where RC “sometimes” doesn’t work as it should: https://github.com/PX4/Firmware/issues/12251. Without a log it’s difficult to say but it’s something to look into and hopefully fix anyway.
Could you share what receiver you are using? That might be a hint to see if it’s the same as reported in the issue above.
It is a TBS micro receiver and a taranis x9d plus with a tbs module . I have not had any problems with the radio link other than that before or since.The issue is the rtl rejection and then refusal to change modes even though it can get the commands via the rc.
Seems the problems occur when I try to change into rtl . The wrong mode (loiter) getting selected and rtl rejected .
After it goes into Loiter and not RTL It goes crazy , cutting and starting motors , flying off , actively rejecting rc controls refusing to switch to other modes or just turns off the motors in the sky. Other times it will rtl perfectly. Have flown acro for over an hour to tune it and no problems at all.
The fall from the sky and the flyaway plus crazy part all happened after this strange going into loiter mode instead of rtl and cutting/restarting motors so I am reluctant to switch into rtl to test it.
Ok I have learned how to view the log and am using a good card . It is rejecting rtl and using loiter instead. There is not a reason given in the log for the rejection!.
Gps is good? High intermittent jamming? and the mag I don’t know for sure.There were pylons nearby but they have never caused a problem before.
In another flight with the same gps interference it has been ok apart from refusing to land.
Wrong mode selected for RTL and then erratic behaviour the log also shows strange oscillations in stabilise mode when acro is nearly fine.
ACRO tuning log , no problems since I didn’t change modes.
Phew that was a mouthful
Wow, in loiter there are weird spikes in thrust, and I don’t understand yet where they are coming from.
@MaEtUgR does this make any sense to you? Could you have a look at the log just above? Thanks.
If your airframe has vibrations this can cause clipping (amplitude exceeding measurement range) or aliasing in the sensors. There is only so much that PX4 can do if that’s actually happening.
However, I don’t think the issues in loiter and RTL are connected to vibrations. It rather looks like some faulty input which triggers throttle to go to 0 intermittently.
The problem disappeared mostly after upgrading to 1.9.2.
However it went full thorttle upside down after landing and flipping. For some reason it decided that it should be in altitude mode according to the log. There were other errors in log, I uploaded the log but I don’t know which one it is. Luckily the kill switch was setup this time.
There are also issues with instability and random behaviour when switching modes inflight still. They never existed with the same setup and arducopter.
Thanks for your help, the software is performing adequately for my needs.
Thanks for the log!
I would expect it to go full throttle if it flips before it detects the landing. Unfortunately, we don’t have a flipped detection (yet).
I think the logged messages might be interesting for us though. @MaEtUgR could you check that they make sense?
The big full thrust, not thrust spikes in loiter are defeinitely because of land detection:
The vehicle seems to hover at around 31% thrust but the necessary hopver thrust
MPC_THR_HOVERis configured as 50% (value of 0.5). This means the land detector sees the controller can go off the thrust and the vehicle stays stead so we must be on the ground. After lowering the thrust further it sees movement again and catches the drone to not crash.
MPC_THR_HOVER to the value of