Hello everyone:
Yesterday, what it seemed like a nice day to fly, it became the end to my IRIS+. I just started flying over a wheat field and suddenly the IRIS+ stopped responding telemetry commands, raised up itselft for about 50 meters, then flew away and went side until it crashed, like if a motor had stopped working.
The results: all the four legs got crashed, the chasis is all with scratches, the front red leds didn't turn on anymore and the GoPro Hero3+ housing scratches too. Fortunately the Gimbal was not installed.
I'm feeling pretty dissapointed now on the IRIS+ since I spent so much money on it. Today sent an email to Help department at 3DRobotics hoping for an explanation of what happened and looking forward for some kind of warranty.
Here is the video and the photo showing how the IRIS+ ended up so I wondering if you guys could notice something wrong on this attempt to fly.
Thanks!
Log files: https://www.dropbox.com/s/1nzuiixs0lba4ju/QUADROTOR.zip?dl=0
Replies
hi guys.. sorry , i just saw this post from a random search on IRIS+ crashes.. the original poster showed a link to his video.
in the video i detected the sounds of very high vibration,,, high vibration is caused by damaged props, or way off balance.
even if the prop is not broken, and only a little bent, this can cause high vibrations,,,these vibrations severely interfere with the on-board sensors, when these sensors are disturbed, the drone cannot make proper decisions, and this is what causes many crashes.. vibrations kill drones.. always have spare props on hand, always have a prop balancer .. if you take off and it does not sound smooth, land right away..
hope this late info helps someone out there..
I have an Iris+ since the end of 2014 and I'm still novice with mixed feelings and I do not trust my iris+. Last sunday happened:
My IRIS fell down as a piece of stone.The weather was beautiful, moderate wind, low K index etc. After calibrating my iris+ I make some test flight around me inside 50m radius circle and in max 30m height. There were 4 succesful launch and landing, it seems everything is ok, the drone operated without problem. in one case (I test all of the rc functions) I switched "RTL". The Iris started the programmed RTL routine normally and then (cca 1 m above launching point) the green status lamp suddenly change to rapid blinking yellow (with crisp beep) and started quick to raised itself and fly away. after crazy flyng he fell down (cca.350m away and the altitude were about 100m or more).
The gimbal totally broken and the upper cover cracked. Seems electronic parts and gopro survive the chrash. (I measured 9,5 battery voltage after crashing. what do you think battery may survive this voltage level?)
I think at first were battery failsafe problem, but I dont understand the behaviour of the iris. After he was kicking failsafe mode the control totally lost, no react to the radio control. I panicked. The battery failsafe set as RTL but instead of it he was crazy and fly away. Thanks to an smart advise I examined the log which said:
1. at first was batt failsafe (but no started RTL routine)
2. immediately was EKF problem (I think my bird lost his good orientation an it seems he wanted to go to my house:-)
3. The log analisys shows compass offset problem occured and cause EKF failsafe.
some question are arised:
1. any failsafe mode overwrite the command from rc?
2. how can I avoid this or similar suddenly arised problem and get back the control?
(bad to think what about in inhabited area)
3. there are many failsafe issues may set in MP, but no one solutions against eg. compass failsafe. (it may be interesting for developers)
4. may I disabled the batt failsafe and strictly control the voltage level on the rc lcd? (but this is no good answer for compass, gyro and similar problems.)
(it is possible that the my problem more simple as I think but please be patient I'm not an techical talent)
sum: how can to recover the control avoid similar problems in the future?
thanks, and sorry for my google english:-)
irismalfunction.jpg
loganalizirisplus.jpg
I would be careful here as you need the mode where you can get to them when in trouble. You need to know right away that you do this to put it in that mode. Having Auto in the middle means you have to go through it every time you use different modes. Stabilize, Alt Hold, Position Hold, and Loiter are used most often in my case and Auto is always from takeoff.
The original IRIS configuration is:
Up, Up - Stabilize
Up, Down - Stabilize
Mid, Up - Loiter
Mid, Down - Alt Hold
Down, Up - Auto
Down, Down - RTL
I have swapped out the Loiter for Position Hold as its a little more responsive then Loiter.
If you know that both up puts you in Stabilize mode then your more likely to able to do that in a hurry and not have to take your eyes off the action.
Turning off the transmitter maybe a bad thing to do if the sensors are messed up since it needs those to do that function. Stabilize has always saved me in the past.
The only think that gets me is that something else can change the mode and until I change the mode back by moving the switches it stays in that mode and I don't know that I need to do that.
I have even placed a microcontroller on my IRIS that reads Mavlink and tells me by various flashing LEDs what mode the IRIS is in.
Having stacks of modes on a couple of switches is very poor practice and a recipe for disaster. In times of trouble you will make mistakes. Rather use a tablet or phone for autonomous modes and flight monitoring and then back home in time for tea and medals with a TX that only does stabilize, loiter and RTL.
I totally don't disagree with having too many flight modes can cause problems when you are in a panic. I am only suggesting that it can be done to your liking (I have had mine setup this way for several months, and my multi-rotor flies nice, so I haven't had any discouraging issues when doing this - only one bad flight in the beginning before my hex was completely tuned). Each pilot must take on the level of skill they are comfortable with, growing with possibilities of the flight controller as their skills increase.
I have my radio switches setup similar to my NAZA F/C (something I've been flying for almost a year) so that when switching between each of my multi-rotors, I get similar flight modes, and I only have to remember one set of positions for failsafe (it was just a personal preference). Just as Michael B. mentions (through the use of LEDs), I use the Bluetooth link to my phone to get the same feedback on which flight mode I am in. If I had a Spektrum radio, I could have the speech feedback each time a switch is moved (my buddy has this, it is super slick).
I appears I deleted the first post by accident.
My brand new Iris+ with gimble and gopro attach decide to fly away on its own until I lost sight of it. No chance of recovery. It was my second flight. all pre flight checks performed and in loiter mode. I took off got to approx 50 feet up and was adjusting the camera with FPV when I noticed it was not responsive to come down. I took off gaining altitude and flying in a straight line. I tried std mode, RTL and Land switches and nothing helped. Unable to get any help at this time from 3Drobitcs.
So I have a couple comments that the community may also be able to comment on to help alleviate these "fly-aways" and to help others in the future with pre-flight checks.
After reading through the instruction manual and pre-flight check documentation for the Iris+, and based on my own experience flying a Pixhawk Flight Controller (on a non-IRIS multi-rotor), can the user of the Iris connect to it with an Android Device (let's say phone) with Droidplanner (prior to flight) using a standard Bluetooth connection, or do you have to use the 3DR telemetry radios (and do the radios come with the Iris)?
The reason I ask is that I usually connect to my Pixhawk (via a Bluetooth module) and confirm my flight parameters and fight modes on my Android Device prior to Arming and taking-off. Its a simple check, but it confirms to me that the flight controller is responding to my radio switch inputs as I change them (I have six modes, Loiter / RTL / Drift / AUTO / Stabilize / Alt-Hold). It's kind of like the old days of planes, testing your flight control surfaces prior to taking off. If the Iris user make a simple connection to the Flight Controller prior to take-off, and they can easily check F/C responses to Radio Switch Inputs.
Also, at each new location that I fly at, I enter a couple simple Waypoints (like 2 at 15 meters) via Droidplanner and SEND them to the flight controller. This ensures that if I hit the AUTO flight mode by accident, that the multirotor stays in the vicinity of where I am flying. I have been flying long enough that even with experience, I have hit the wrong switch thinking it was another switch (and reviewing the flight logs showed I had done so).
My experience with the AUTO mode has been if you have old Waypoints entered as part of a previously programmed "AUTO" flight, and you fly somewhere different, and you accidentally hit the "AUTO" switch, the multi-rotor will attempt to go to the first waypoint of the previously programmed flight (even if it is nowhere near where you are flying). It is not clear how the flight controller responds to this action if the FENCE_ACTION is set to "Report Only", and whether FENCE_ENABLED" comes factory preset as LAND or RTL, and whether FENCE_ALT_MAX and FENCE_RADIUS come pre-programmed from the factory with a specific distance and altitude (it appears 300m is the default FENCE_RADIUS). Either way, the pilot should review these parameters as part of a pre-flight check to ensure the actions / distances meet their specific flight requirements.
Now for the guy who had the fly-away as his first or second flight, is it possible there was an erroneous waypoint programmed into the flight controller (perhaps from the factory)? I'm not purporting this is what happened, but fly-aways DON'T JUST HAPPEN, they happen for a reason. Is it possible that the flight had commenced without proper GPS lock? Several of the flight modes do not function properly without GPS lock (especially RTL) prior to take-off. And obviously, without flight logs to check, we will never know for sure. I know this was a similar problem with the Phantoms / DJI NAZA M Flight Controllers, where many users were impatient with the GPS lock process, and resulting fly-aways were common. I am also familiar with the DJI NAZA M F/C with over 300 flights with no fly-aways (I have two buddies that also fly the NAZA and we always ensure we have GPS Lock before ever taking off).
We can only train ourselves to become better pilots using the proper knowledgebase to setup the flight controller properly, and to definitely wait for GPS lock to occur prior to take-off.
Anyone know an easy way to program STB into the new IRIS+ controller, its not an option anymore. Would like to keep ALT but would also like full control of the aircraft if this does happen. It happened on my 1st gen iris and I was able to bring it back in control, but without STB, it seems as though there is nothing you can do.
Also if this happens what about turning the TX off if there is no other options, would that make it at least stop flying away?
I would imagine you can program a total of SIX flight modes into the flight controller (if it is a TRUE Pixhawk (as I have done so, see attached pic), and the transmitter is performing a channel MIX of the Flight Mode "STD/LTR/AUTO" switch and the RTL "OFF/ON" switch.
I cannot confirm if this is the way the Iris transmitter works, but ultimately the selected flight modes end-up as a single channel input at the flight controller. Here is how I set mine up:
Three Position Switch Two Position Switch F/C Flight Mode
Away Away LTR (Loiter - GPS Based)
Away Towards RTL GPS Based
Middle Away Drift GPS Based
Middle Towards AUTO GPS Based
Towards Away Stabilize Non-GPS
Towards Towards Alt-Hold Non-GPS
The Flight Mode changes would have to be made in Mission Planner, and I don't know if this can be done with the Iris. The only way to know if it is working is to have the F/C plugged into MP, and toggle your respective switches with the revised Flight Modes and see if the Transmitter Flight Mode changes on-screen. You have to revise the Flight Modes in the Advanced Settings (and note, on some computers, you only see every other line of advanced settings - I had to change my video colors to "High Contrast" to see the black text that was on a Black Bar).
MAJOR CAUTION HERE - Setting up your two channel switch (let's call it the original RTL ON/OFF control) will lose the RTL functionality on the two remaining (middle / towards) positions on the three position switch. In a panic, you have to remember to flip the three way switch to the "Away" position", then flip the two-way switch to the "towards" position. I grouped my GPS and non-GPS flight modes and made sure my THR_MID setting was setup properly to provide smooth transitions between the flight modes (you also have to remember to position the throttle at approximately "mid-stick" to achieve smoother flight mode transitions). This caused me a costly crash early-on with this F/C.
As far as turning-off the TX, yes, RTL should occur ASSUMING FS_THR is set to "1", and the FS_THR_Value has been set properly for the respective transmitter. I cannot speak to the particular setting for the Iris Transmitter, but on my Futaba Tx, the value is 975 (BUT THIS IS PARTICULAR TO FUTABA TX and RX RADIOS).
Flight Modes.JPG
@ Joe
Very good points. I always have RTL, Stabilize, and auto in the same switches and positions so less confusion. Stabalise in particular is the 'go to' mode if something seems not right.
-
1
-
2
-
3
-
4
-
5
of 8 Next