Hello guys,I give you a new configuration of my easyglider after experimental flight with Ardupilot:
I already have this model to fly FPV at 2 years, never crash and never had problems with radio interference.Now off to test new minimum and maximum values of the PID's, and after about 40 seconds of flight, the model came into spiral to the ground, the Ardupilot was disabled by the toggle. Very strange, the attitude that the model got to the ground was equal to that he earned the previous test flights with the activated ardupilot (FMA Without sensors and PID's = 30).Since I received the Ardupilot board from Sparkfun, Do not upload any file to the failsafe, even so you can have activated the ardupilot without my command?
You need to be a member of diydrones to add comments!
What you need now for sure is this:
Sorry for your EG, but Gary is right: your fixed EG will be a much better suited testbed for further experiments than a brand new glider! Good luck and keep on trying.
You flew ArduPilot 1.0 without a FMA CoPilot? That's a guaranteed crash--you had no stabilization system at all. Sorry to hear it, but I'm confused by why you would attempt that.
What kind of radio system were you flying with? 2.4Ghz or 72Mhz? It's been my experience that 2.4Ghz is more solid with respect to potential interference and noise introduced by all the added electronics onboard.
I'm trying to imagine why the ardupilot might lock you out even though you had the auto/manual switch set to manual. Two possible scenarios come to mind.
1. You are flying with a 72mhz system and radio interference caused the ardupilot to think that the manual/auto switch got set to auto.
2. With the "remove to fly" system, the code can override the mux signal from the receiver and forcibly drive the servos. That's a little scary, but properly coded, it should never happen in flight ... unless the remove to fly shunt was installed from the start?
3. Some sort of short or loose connection that manifested itself in the middle of the flight.
It would be interesting to take all the parts back home and do some post crash analysis. Did all your batteries have good voltage? Is the ardupilot unit functioning ok now? Does your receiver still work and how does it range check?
You can never say for sure if a problem you discover caused the crash, or was caused by the crash, but it might be worth going through all the systems to see what works or what doesn't. Even double check physical things like control surface hinges, linkages, etc. These things have been known to fail in flight too. If the autopilot does something oddball, it could put forces on the airframe that are way outside of normal and could cause a physical failure in flight.
With one of our early wings, the autopilot put the wing in maximum (allowed) down elevator configuration. I let it go because I had a lot of altitude and was hoping it would catch and fly itself out of the dive, but it kept forcing full down elevator and ended up doing a forward somersault at about 100 mph before I returned to manual. That was really weird and we got really lucky that we didn't shed any parts ... but our wing is designed to be bullet proof in a marine environment so it's a pretty tough bird.
At any rate, my advice would be to do as much post crash checking and analysis and debugging to try to figure out what happened and why ... otherwise it's likely to happen again on your next airframe. And if there is something going on with the basic ardupilot design (which is probably unlikely, but all things are possible) then lots of other people would sure like to know about it.
Replies
Sorry for your EG, but Gary is right: your fixed EG will be a much better suited testbed for further experiments than a brand new glider! Good luck and keep on trying.
I'm trying to imagine why the ardupilot might lock you out even though you had the auto/manual switch set to manual. Two possible scenarios come to mind.
1. You are flying with a 72mhz system and radio interference caused the ardupilot to think that the manual/auto switch got set to auto.
2. With the "remove to fly" system, the code can override the mux signal from the receiver and forcibly drive the servos. That's a little scary, but properly coded, it should never happen in flight ... unless the remove to fly shunt was installed from the start?
3. Some sort of short or loose connection that manifested itself in the middle of the flight.
It would be interesting to take all the parts back home and do some post crash analysis. Did all your batteries have good voltage? Is the ardupilot unit functioning ok now? Does your receiver still work and how does it range check?
You can never say for sure if a problem you discover caused the crash, or was caused by the crash, but it might be worth going through all the systems to see what works or what doesn't. Even double check physical things like control surface hinges, linkages, etc. These things have been known to fail in flight too. If the autopilot does something oddball, it could put forces on the airframe that are way outside of normal and could cause a physical failure in flight.
With one of our early wings, the autopilot put the wing in maximum (allowed) down elevator configuration. I let it go because I had a lot of altitude and was hoping it would catch and fly itself out of the dive, but it kept forcing full down elevator and ended up doing a forward somersault at about 100 mph before I returned to manual. That was really weird and we got really lucky that we didn't shed any parts ... but our wing is designed to be bullet proof in a marine environment so it's a pretty tough bird.
At any rate, my advice would be to do as much post crash checking and analysis and debugging to try to figure out what happened and why ... otherwise it's likely to happen again on your next airframe. And if there is something going on with the basic ardupilot design (which is probably unlikely, but all things are possible) then lots of other people would sure like to know about it.
Regards,
Curt.