I just put payload on my quad, it has flown several flights before this with no payload and no issue. I also flew a one issue free flight before this one for 17 min (the entire flight time) with the new payload.
The here2 flashes in some error code in flight, I couldn’t see which colors or sequence it had but I saw a blue and red flash. The drone than starts to descend slowly. Full throttle won’t do anything. It’s forcing me to land on the spot. I still have pitch, roll, and yaw control.
In the log I can see error codes regarding the ekf and a compass error. But I don’t know why it decided to force me to land.
The only changes I did between my good and bad flights was:
New firmware, latest copter.
And I stole 5v from a CAN port to power a seagull map2 camera trigger via the servo rail. Nothing else is powered by the CAN port and since the map2 draws less current than a here2, I thought I could use the CAN voltage supply.
Maybe someone could take a look at what might be wrong here, Thanks!
The compass stopped providing data (well 4s to do it and it should be 200msec), Position Down Innovations went high and Land Mode triggered from EKF Failsafe. I don’t know what all those “CAN125 Registered Topic for 0X1 0X6” mean but it started logging them at this point. My guess is it means something has gone wrong
hm, this happend two flights in a row. Maybe it’s because I powered the cameratrigger from a can port. I used the power wires and connected them to the servo rail. The only thing that’s taking power from there is the cameratrigger. But maybe it messes with the system to do that.
Edit: When I look at the power tab in log analysis, and the voltage reading from the servo rail, I can see that it drops out two times. Since I use a CAN port to power the servo rail and the camera trigger maybe the voltage drop affects the system. CAN 1 which has the gps and compass probably has the same internal power supply and therefore a voltage drop on CAN 2 also would reflect on CAN 1. This would cause the here 2 to reboot or at least not work correctly. I’ll use an external power supply to power the camera trigger and test fly again tomorrow.
It was a bad CAN cable, or that and something else. When I twisted the cable and pulled a bit on it the here would lose power. So it basically lost the gps and compass.
Should it really go into land mode than? Not alt.hold? The cube has 2 more compasses to use and if I lose the here2 and it just decides to land, that could be dangerous in a real situation/not a test flight.
This is a screen of what the cube says when I unplug the here2. It feels like it’s complaining about a bit to much. Like attitude, and altitude. That has nothing with or should be handled without gps and compass.
okay, but the ekf handles more than position estimate, right? If an IMU would fail, would the cube use one of the other two? Or would something else happen?
It could be. It will drift with the wind w/o control action so it depends on the circumstance. I always have it set to Land but that has twice resulted in the craft landing in a tree. Another time in the middle of a very large corn field. All recovered.
I think I’ll set it to alt.hold, I almost never fly far enough so that flying in alt.hold would be an issue. Most of my flying hours are in alt.hold or stabilize anyways.
Should I use EKF3 or EKF2. For a while ago, I got told that I should use EKF2 since 3 was a bit to new and not well tested. Which should I use now? And what’s the difference between them?
Sorry to hijack and revive an old thread, but this is the only place I could find this error. I got a similar problem with ArduCopter 4.3.3 and two HERE3 GPS plugged in the CAN bus ports.
Sample of error messages:
EKF variance
LandingGear: DEPLOY
EKF Failsafe: changed to LAND Mode
CAN[125] Registered Topic for 0x1 0x6
CAN[125] Registered Topic for 0x5 0x1
CAN[125] Registered Topic for 0x6 0x8
CAN[125] Registered Topic for 0x6 0x1
CAN[125] Registered Topic for 0x6 0x24
CAN[125] Registered Topic for 0x6 0x70
CAN[125] Registered Topic for 0x6 0x3E
CAN[125] Registered Topic for 0xA 0x4
CAN[125] Registered Topic for 0x1 0x7
CAN[125] Registered Topic for 0x1 0x61
CAN[125] Registered Topic for 0x1 0x4
CAN[124] try baud 19200
CAN[125] try baud 115200
CAN[124] try baud 38400
CAN[125] try baud 4800
CAN[124] try baud 57600
CAN[125] try baud 19200
CAN[124] try baud 230400
CAN[125] try baud 38400
CAN[124] try baud 460800
CAN[125] try baud 57600
CAN[124] try baud 9600
CAN[125] try baud 230400
CAN[125] initialised
CAN[124] try baud 115200
CAN[124] try baud 4800
CAN[124] try baud 19200
CAN[125] 0 raw flags = 16842753 sz 36
CAN[125] 3 raw flags = 16842752 sz 36
CAN[125] 5 raw flags = 16842753 sz 36
CAN[125] 6 raw flags = 16842753 sz 36
Does anyone know what could be causing this error?
Also, why is the CAN port trying baud rates typical of serial ports that are not usually used for CAN communication?
I was thinking we might have to call in the big guns regarding the CAN GNSS messages but I think I found the problem.
There are two “events” in the log where both GNSS units are equally affected. You can see where the GNSS units go bad that also the power flags change. (I only showed one Delta here for clarity)
41 = power brick valid + something changed + peripheral overcurrent (a couple of small spikes of these)
33 = power brick valid + something changed
See the Power Flags reference below
I think all the CAN messages about baud rates and registered for Topics are normal boot up of the CAN GNSS units, and it’s just that normally we dont get to see all that since the Flight Controller would not normally be fully operational when that occurs (or they are obscured)
You are going to have to examine the current draw of peripherals, possible offload one or more devices to a separate BEC.
Also adjust these to suit your region, and cut back on the number of constellations so the GPS.Delta is more consistent. Typically two constellations are enough, GPS plus one other. Select SBAS if you have it in your region.
GPS_GNSS_MODE
GPS_GNSS_MODE2
You should definitely set these correctly
BATT_ARM_VOLT
BATT_CRT_VOLT
BATT_FS_CRT_ACT
and I think this one is wrong MOT_BAT_VOLT_MIN
Let me know if you are not sure about calculating those voltages exactly or why you really should set them.
Power Flag values
1 MAV_POWER_STATUS_BRICK_VALID // main brick power supply valid
2 MAV_POWER_STATUS_SERVO_VALID // main servo power supply valid for FMU
4 MAV_POWER_STATUS_USB_CONNECTED // USB power is connected
8 MAV_POWER_STATUS_PERIPH_OVERCURRENT // peripheral supply is in over-current state
16 MAV_POWER_STATUS_PERIPH_HIPOWER_OVERCURRENT // hi-power peripheral supply is in over-current state
32 MAV_POWER_STATUS_CHANGED // Power status has changed since boot
The only things powered from the flight controller are the 2 GPS, and the LED on the safety switch if you want to count that.
I’ll look into the rest of your suggestions.
