ArduCopter 2.7.1 will become available on Mission Planner and in the downloads area shortly. This release contains a few important bug fixes as well as the first implementation of the MPU6000 sensor-fusion code.
Detailed changes are in the commit log. Here's a summary:
- Preliminary support for MPU6000 on board sensor-fusion (DMP)
- AP_Limits: Experimental "bounce" mode, for smaller spaces (LIM_RECMODE)
- Bug fix for yaw error buildup on takeoff
- Fix in Auto mode for failsafe handling
- Fixes to 3-axis camera gimbal code
I dont get to fly much so firmware versions go by without me even getting around to testing them. After updating from 2.6 to 2.7.1 my telemetry module on my quad got bricked. I though this might be a 2.7.1 firmware problem so I went back to 2.6 but my telemetry still didn't work. I managed to un-brick it and then loaded 2.7.1 again, just to find that the module got bricked AGAIN. I then un-bricked it with 2.7.1 already loaded on my quad and it seems to be holding now. Anybody else perhaps having the same problems???
It's 30A of Jdrones
@Andre: i think it's unfortunately just a coincidence.
Check if the on board module is alive using FTDI cable and a terminal program, like Putty.
What do you mean with "bricked"?
The release 2.7.1 has some little problems we are trying to solve, some reported by me during the test and unfortunately for now unresolved, but it certainly can not break a module with the new firmware.
Well, it's been a rough weekend with about 75% failure rate on new electronics I tried to get working. But, this makes me feel better. My first images piped back down to ground control from up high!
This is with a 3DR Quad, 5.8GHz camera, USB capture card, a $10 pitch gimbal mounted to a vibration damping subframe. And Mission Planner and Arducopter 2.7.1 of course.
It's taken my 10 months to get here (Spent a lot of time farting around with Trad Helis and working on the code).
But I'd say this could now be done for about $1000 and a month of work if you just follow all the tried and true hardware.
Now to get my circular polarized antennas on the transmitter and an antenna tracker...
No, unfortunately you can't see the image that the sensor is taking from within the mission planner so the only way to do it is to use the python script that's also in the library. I guess we could put it into the mission planner..it's not quite as trivial as it sounds to do that..but not impossible.
That use to happen to me, and i thought it got fixed in 2.7.1. I had me xbee get bricked easily 50 times. It just stopped at 2.7.1.
That's a big part of why we developed the 3DR radios. They don't brick. (And they're half the price of Xbees and work better).
I've stopped using XBees entirely. Just too much hassle.
I've never had any hassles with mine in the past and it works perfectly. I just hope it's not going to happen again with future versions...
Congrats! It all gets easier from here ;-)
I flew around today looking at the abiity of the compass learn and auto declinate features.
I've found that turning them to 0 (off) that the altitude hold along with loiter are more accurate to the RC controls.
Being using the APM 2 it has a compass that is closer to the gauss from the ESC wires.
This upsets the magnetometer when flying.
Sorry, I've been away for a week at the AUVSI conf so I haven't been keeping up with this thread.
I had a look at your logs and they're very abnormal. At row 4368, a little dot (".") appears in the log which is a sign that your logs are corrupted. I suspect that all data beyond that point is not useful..the "AHRS.renorm_blowup_count" jumps to 78 which is a sign that your attitude solution is messed up, the pitch goes -17757 and from then only the ATT message appear. The logs then restart at around row 27460 although the welcome message doesn't appear so it looks like we're seeing the beginning of another flight wher ether logs weren't erased properly.
The kmz location not matching reality is probably because that's data from an earlier flight.
I don't know what to say really..erase all your logs again. The sudden pitch forward could be a software error but I'd lean more towards a brown-out. There is this issue with motors pulsing that I'm actively looking at but that's not causing people to flip over as far as I know.
I got my althold tuned out nicely without foam and the apm2 directly exposed on the quad. Than i had another "brilliant idea" for the heating up BEC on ESC1 and no seperate BEC at hand. I got 4 BEC in my quad why not use one to power APM one to power RX and one to power minimosd? So i rerouted the powersupply and used only one GND to avoid groundloops. The effect is: All leds flicker but the copter will not arm anymore :( . When hooked up via USB to the PC it arms. I don't know why i screwed it up now - but i did :). I have to get a extra BEC and redo the powersupply. Perhaps this info helps others with such a brilliant idea like mine.....