Weird LED pattern + can't arm motors
Hello all,
I've been trying to troubleshoot this problem for a few weeks and I'm starting to get desperate. I tried going through as many threads from this forum as I could and didn't find anything conclusive, so I thought I would ask. Let's hope one of you knows what's happening here. I'll try to give as much info as possible, so please stay with me:
The setting:
- I'm a first-time Arduino user and new to DIYdrones.
- This copter is a X-setup quad.
- I assembled the whole setup, soldering the boards myself, from the jDrones kit.
- I'm using bullet connectors between motors and ESCs, but I put a drop of solder to join the rotating part to the shaft as some people in the forums claim they did.
- Using a DX7 radio and AR7000 receiver.
The problem:
Loading the code and configuring it works correctly. When I reset the board and put the switch in "fly" position, then plug the LiPo, I get a weird blinking pattern on the ABC LEDs on the IMU. I say weird because I could not find anything like it either in the wiki or the forums. It goes kinda like this: A (green) and C (red) flash one after the other 4 times each, then the red one stays lit for a little while, then it starts again. This is when the A light should be staying on, meaning the motors aren't armed yet. Funny thing is, SOMETIMES, after looping the blinking pattern for 5-10 minutes, it does stay on, and I am able to arm my motors (I did a few times already and could control them somewhat correctly with my radio as far as I can tell). It doesn't happen often enough to justify installing the props yet, and I don't know what makes it work some times and not other times, nor do I know why it happens in the first place.
Here is a video of the blinking lights (I took apart the mounting boards so I could film it better with my phonecam, but I can guarantee everything is connected correctly and this is the exact same behavior as when the copter is assembled):
http://www.youtube.com/watch?v=7ern-nodcqQ
Steps taken to fix it until now:
- Re-read the whole wiki countless times.
- Searched the forums.
- Tried loading the code both from Arduino and as many versions of the Mission Planner as I could.
- Tried configuring it with both the CLI and the mission planner. Everything seems to be in order with both ways.
- Tried re-calibrating ESCs (through the CLI only. didn't try to recalibrate manually as I felt I was getting further away from the source of the problem).
- Tried taking the magnetometer and GPS out of the equation because I suspected they didn't initialize correctly. LEDs still have the weird sequence.
- Took apart the copter, checked all the solders on the APM and IMU, corrected a few, put it back together, still no dice.
If you need more details just tell me what and how to get them.
If you also have this problem please speak up.
Thanks in advance to whoever paid attention to this thread!
- Kevin
Replies to This Discussion
-
3D RoboticsPermalink Reply by Guillermo Romero on -
Try the options "erase" and "reset" in the setup menu at CLI. Erase will erase your EEPROM, and after reset through the menu, you need to press 2 times the reset button on APM. That may help. Also, check the switch with a multimeter on the pins, the beep test (continuity).
-
Permalink Reply by Oliver on -
Can you connect a USB cable, connect via the Arduino Serial Console (same as for CLI setup) and post a brief trace of the output when the lights are blinking in Flight Mode?
Either the Calibration Fails, or you have an issue where your board keeps rebooting.
Ollie.
-
Permalink Reply by Kevin Bouchard on -
Ok, after a good month and a half, filled with frustration about this build and other IRL distractions, I jumped back on the proverbial horse.
Guillermo, I tried resetting the boards, recalibrated the ESCs, that didn't change anything. I'd like to have more details about which switch you're talking about so I can whip out my multimeter and give you relevant data.
Oliver, I think you got me very near a conclusive diagnosis; doing what you told me gave me the following trace:
Init ACM
RAM: 1725
FW Version 104
----------------------------------------------------
Init Gyro******** (the asterisks go on for as long as I don't turn off the board)
So I think that as you said, the calibration fails, at the gyro part. Is there any way to solve this? What should I look for next?
I'm currently trying to get a trace from one of those elusive tests where I can actually arm the motors, to see if that Init Gyro part goes through.Has anyone else been having this problem? It's most likely hardware-based (I think) since I get the same behavior with every firmware version I try.
EDIT: YAY! Data!
here's the trace when the board boots correctly:
Init ACM
RAM: 1725
FW Version 104
----------------------------------------------------
Init Gyro**********IMU
----------------------------------------------------
Gyro Offsets: 49.73, -322.05, 43.48
Accel Offsets: -207.50, -29.14, -29.35
G!G!G!G!G!G!G!G!G!G!G!G!
GPS
----------------------------------------------------
disabled
Ready to FLY (Followed by script commands)
Sooo... most likely the gyro? What's the next step? I'll try to check where the Gyro is on the IMU and see if everything is in order. I'm getting desperate with this and I don't think I have the money right now to buy another APM/IMU, so please, any help is appreciated.
-
Permalink Reply by Stafford Brunk on -
I am getting this exact same issue on two different quads. Both are + configs, have Xbees, GPS, magnetometers, etc. I have ruled out hardware issues (by visual inspection and because both quads used to fly fine). I have not yet been able to figure out the cause. This started happening around the time I upgraded to 2.0.34 or 2.0.35.
-
3D RoboticsPermalink Reply by Chris Anderson on -
Stafford: do your boards pass the IMU tests?
-
Permalink Reply by Stafford Brunk on
-
One does the other does not. One quad is using the first revisions of the APM and Oilpan. I flew this hardware using Ardupirates for a long time. Switching to Arducopter 2 has me seeing this gyro issue. This is the one that fails the IMU test.
The other quad is the latest APM/Oilpan. This quad passes the IMU test but will exhibit the same gyro issue on occasion. It is harder to reproduce the gyro problem on this hardware.
Both sets of hardware were purchased via DIYDrones.
-
3D RoboticsPermalink Reply by Chris Anderson on -
Any hardware that doesn't pass the IMU test shouldn't be flown with AC2. The Ardupirates code didn't check for hardware problems the way AC2 does, so you may not have noticed issues.
-
Permalink Reply by Stafford Brunk on
-
I see. I never had any issues while flying Ardupirates. What would be a good way to verify that my gyros are bad and it is not a bug in the AC2 code? I am hesitant to immediately blame the hardware since I only recently started having issues (after a software upgrade...).
I am further wary of the AC2 code since I have not yet gotten it to fly well. Even on my new hardware, I have issues taking off and strange motor spikes.
-
3D RoboticsPermalink Reply by Chris Anderson on -
There are loads of tests in AC2 you can use. Start with the IMU and ADC tests in the CLI. You probably won't be able to connect via MAVLink because your IMU is failing, but if you can you see the sensor output graphically there.
If Ardupirates is working for you, then you should probably stick with that. AC2 is working on all the hardware we've tested it on. Hundreds of IMUs.
-
Permalink Reply by Stafford Brunk on
-
I can appreciate that AC2 is working on hundreds of IMUs. But it is not working on my two IMUs.
I find it difficult to believe that I have been flying with a bad gyro for months now. Even if Ardupirates didn't check for bad hardware, a bad gyro should produce some interesting scenarios when attempting to fly.
I am also getting take-off difficulties, random and sometimes dangerous motor pulses (even when sitting on the ground), radio blackouts that are not related to the transmitter or receiver, and this gyro issue. This is all on the latest supported hardware.
I am not trying to be disrespectful or difficult in any way, but I have been trying since AC2 first went into beta to get it flying and have yet to be successful. Sticking with ardupirates is not really a solution since that project will eventually migrate over to the new AC2 codebase.
-
3D RoboticsPermalink Reply by Chris Anderson on -
I hear you. How can I help?
-
-
3D RoboticsPermalink Reply by Chris Anderson on -
Yes, that looks like a busted gyro. You can contact customer support from the store you bought it from, but if it's out of its warranty period they may not be able to help.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Documentation Editors
51 members
-
ArduRover User Group
184 members
-
Swiss Drone Group
11 members
-
Andropilot Users Group
182 members
-
ArduCopter User Group
1290 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
