I’ve been using Cube for years; first I used Cube Black then I switched to Orange and Orange+
A few days ago I did the compass calibration again (GPS HERE3+) and at the end of the process I heard 3 descending scale sounds (let’s say “unhappy scale”). I know perfectly well that at the end of the calibration the scale must be increasing but the green bar of the calibration process on MissionPlanner had reached 100% with the word “Success” and on the Hud of MissionPlanner (in EKF) I had a regular situation, so I decided to take off.
Drone ungovernable and insensitive to any RC command… then CRASH !!!
I’m almost 100% sure that the problem is in the compass calibration (also because previous flights were regular) but now I have 2 questions to ask:
for what strange reason do I have a conflict of information? descending beep scale but “Success” message on MP and zero fault alerts
why is this damned system so unstable? if the compass is calibrated it works wonders but a cat hair out of place is enough to precipitate everything. Checks all activated in ARMING_CHECK. Yet there should be redundancy to avoid this or a tighter check before taking off if all is not more than OK
Hi Anto,
Can you provide the logs? We had a similar problem with Cube Orange+. Pre Flight checks were all ok and drone took-off in AUTO mode. But after takeoff, the drone behaved erratically in LOITER, GUIDED and RTL mode. Last RTL made it fly away including break the geofence.
A .bin log would be nice to investigate.
Usually compass issues dont cause such radical behaviour, more likely vibrations and hardware failures, but let’s see.
We had a flyaway incident after MAV_SYS_STATUS_SENSOR showed false for MAV_SYS_STATUS_SENSOR_XY_POSITION_CONTROL (0x4000 x/y position control).
The drone was behaving erratically in LOITER, RTL and GUIDED mode. The Geofence triggered RTL but it breached the geofence and moved in the opposite direction very fast.
We suspect IMU or GPS issues. Unfortunately there are no logs as the drone battery shorted after crashing and destroyed the frame and cube.
Ground Control Software : QGCS (SKYDROID – H16 Pro)
We do not see any logs in the Skydroid.
uSD card damaged due to battery heat.
I would like to know whether using the version 4.3.5 instead of 4.4.x in Arducopter have any major issues for us. Any assistance or pointers would help.
I’d be interested in seeing any recent log you might have kept from that copter.
Pity about losing that copter
4.3.7 had quite an important bug fix: f) RC input on IOMCU bug fix (RC might not be regained if lost)
…but looking through all the release notes, I would very strongly advise to go to latest stable version.
The release notes for 4.5.0 are extensive with improvements, and we’re up to 4.5.5 now.
can you give me more details on what f) IOMCU bux fix is?
Unfortunately, we don’t have the logs but we were monitoring some data remotely via Mavlink.
The GPS data shows huge variations of about 16m for the last 10 seconds. Meaning, the GPS shows at timestamp 00:30seconds to be at one location but 00:31 shows a position 16 meters away and at 00:32 it’s back at original location.
However the drone was not moving when viewed physically. Ground speed showed 9m/s but we had set max limit to be 5m/s and drone was hovering erratically and definitely not moving at 9m/s.
When RTL was triggered in this scenario, instead of going towards take-off location, it just went in the opposite direction and broke geofence.
All the release notes are listed on the Ardupilot forum and all the pull requests are in github for all to see.
On the forum just search for “copter release notes”.
That RC loss bug doesnt sound like the issue you had - yours is more like serious GPS interference.
I’m not aware of any bugs or fixes related to the behaviour your copter experienced. I listed that one because it was an obvious bug that meant you should be on at least version 4.3.7
Unless you are under some strict version control system with extensive testing, it’s important to stay close to the latest stable version and check the latest release notes in case there is a bug fix that affects you. MissionPlanner will tell you when there are new releases, and you should be connecting after every job or flying session to download logs for safe keeping. These days most countries require you to keep logs for years, and maintenance records.
You can use GPS Jam to look up your region and see of interference is common or not.
Lack of a specific colour only means there is no data for that area. GPSJam GPS/GNSS Interference Map
