I finished assembling my quad copter just a few days ago. It has a navio2 mounted on a raspberry pi2 on a pretty much standard f450 frame with hc-12 uart radios. Unitl now i was pretty much only using the the mission mode since; it is flawless and kept me verrrry impressed by all the hard work behind this project, nothing to say. But then this evening, i wanted to test the longevity of my 3s lipo doing one single flight from a completely charged battery until empty. I started a little triangle mission, like shown in the image, and i forgot to set delay to the last point. I wanted to set something ridiculously long just to make sure it would drain the battery, and when i would hear low battery i would then command the quad to return to launch position. Seing the quad returning home, i then tried to put it in position hold, hoping it would just stay where it was a that very moment… wrong! The quad suddenly turned around and smashed itself against a building. Now I realise that putting geofence would of been wise, i feel blessed that nothing more happened, that will serve me a good lesson like going even further.
But still i can’t seem to understand why it did that… I joined the .bin log if someone would be kind enough to explain me what in hell happened, because the quad is completely smashed right now and if I decide to launch myself again into building another one I would very much like to understand what went wrong.
Hi mike! Thank you so much for taking a look around!
I can effectively see that signal to motor 4 went all the way up… I would have to double check but i think motor 4 was the one facing in the direction where it headed, effectively… Or the oposite ill have to check tomorrow.
In anyway, the thing i find wierd is that the battery was fully charched to 12.6v right before the flight, which was very short, before the event occured.
For the esc, to be honest i assume there was no voltage cuttoff, its one of those simonk 30a with the same description copied and pasted on every site/ebay description. It says there is no voltage cuttoff in the description, for what its worth.
I’m just begenning to understand how the logs work, you see you saw the voltage of the battery drop down? To me the quad looked pretty pumped up when i saw it taking the large … For the current i would only assume it rose a lot when it decided to fly like crazy!
The only thing that bugg is that it occured exactly at the moment when i switched mode…
Btw i had no rc receiver plugged in, in waiting one from the mail, until then im using an xbox controller, so rc override. But i did not brought it with me that time.
Hello, i do not agree with the motor 4 shutting down, if it did you would see opposite motor (3) go to idle position wich it doesn’t.
If you take a look at ATT you can clearly see that the roll and pitch commands were commanded to do what they did.
What i don’t understand is why all RC-IN are at zero for all channels. I think you should elaborate a bit more on your configuration. Are you by any chance flying it without a radio, only with telemetry? If so than all would be clear, as soon as you went to position hold all the channels went to zero except for throttle and that is why you see quad going at extreme pitch and roll and fly into building.
Well, i think it pretty much explains it… There was no rc plugged in (…) I assumed it would have took it into account there where no input of roll/pitch/yaw command, therefore ordering it tp stay in one place. I find it strange that it decided to go straight in one direction
Could it be an idea/proposition for a further improvement of the code? If for whatever reason rc channels get no input (drone being too far from controller) but the telemetry link is still up (4g usb modem plugged in) when user switches to position hold, then do a security check, and take an action accordingly? RTL, land, of whatever? Except giving it a brutal command like this… :S
Actually arducopter is not meant to be used without a radio. In case you have a radio and it goes out of range than the signal that the rx sends to the FC is fail safe and can be controlled and instructed to do an RTL for example.
The problem with your configuration is that you do not have any RC input, so you need to add a rx and configure it.
There is a flaw in AC_AttitudeControl in rc10 with the initialization of the position that can cause flyaways in Pos Hold or Loiter. It has been patched in master, backported to 3.6 and the fix will come out in rc11
Edit: Actually git log indicates this patch should be in rc10 in my build here.
Hi @ChrisOlson ! I double checked this morning, and contrary to where i posted, my firmware is 3.5.5 and not 3.6. Does it make a difference?
So at the end, are you saying that it wasn’t the fault of no rc plugged in ?
Within the image provided by emlid for the rpi, i executed the command that supposedly updated arducopter. Is there a particular version i should have installed? Or manually compile to the latest ?
No, the bug I posted the link to only exists in 3.6 up until the patch to fix it.
I don’t know about the RC. I’m a heli developer and I understand multi’s should be able to be flown without RC. But I don’t know the details of it without looking at the code. We specifically prohibit that in helicopters so you won’t be able to even start a helicopter without RC present. IMO it is not wise to fly anything without a pilot on the controls, and a GCS is not adequate controls to ensure the safety of the aircraft, property and personnel.
Technically, I’m using rc over mavlink… That’s the ‘suggested’ way to use the crossfire RC system. It has been working great.
And other people fly w/ joysticks connected to their groundstation rather than RC, and have no traditional RC receiver. It is definitely OK to fly that way.
At that time, no rc, no joystick either… i understand that there is not just ‘failesafe’ signal coming from an rc receiver (lost signal), but literally nothing since no rc receiver connected. Could it be possible to implement the same check as lost signal and RTL automatically instead ?
OK I guess that does make a difference… Because RC over mavlink is set up just like traditional RC… You can see the green bars in mission planner in the RC config, etc. So, the FC is still getting values for RC Input. I guess that’s no different than a traditional RC receiver as far as the FC is concerned.
