I loaded the APM 2.24 with all the default parameters today and went flying. Stabilization and FBWA worked fine but when switching to AUTO or RTL modes, the plane goes into a dive. I've tried setting waypoints with both relative and absolute altitudes with the same end results.
Does anyone know what is going on?
There is a memory check/health report in the 2.24 Mavlink stream.
Chris, I'm waiting for an FTDI cable to come in, in order to unbrick my two Xbees that went out on the last version. I'll take a look at the health report then...unless there is a way of logging it on-board?
I flew today and everything went well. The only thing I did differently was to load the code via APM planner instead of the Arduino IDE. One of the things I've been doing is to use my own naming convention for the different saves with my personal modifications. For example, I had saved the latest version of ArduPlane as "ArduPilotMega2_24" instead of the standard "ArduPilotMega".
I'm wondering if the fact that I'm not opening the sketch named "ArduPilotMega" in order to compile has anything to do with this problem.
I'll be testing that theory tomorrow on more flights.
Rigel, why do you need a FTDI cable to unbrick an Xbee? The USB adapter you already use on the ground will work as well.
Because being the great solderer that I am, my modules are stuck to the adapters. :o(
Chris, my plane is down and out for the count :o(
Attached is the log file...I hope you can make something of it. Basically I switched it to AUTO, and the plane proceeded to waypoint 1, then 2, then 3. On its way to 3 it nose dived (see elevation profile), I quickly switched to stabilize which did nothing and by the time I switched to Manual it was too late.
The one thing I had done was to add Alpo's camera stabilization code to the medium loop.
Let me know if you can come up with anything based on the log.
I have also had this nose dive after switching to auto mode. Happened twice - almost exacly as being described here, except that for me it occured immediately on switching to auto mode. Ironically the flight right before that one was perfect. All I did was land, and change batteries and relaunch.
I believe this happend to me pre - 2.24 and I believe pre 2.23. I never posted about it as for some reason I had no log. All my code was uploaded with AMP and unmodified.
really looking forward to possible explannations as I have been reluctant to try again in a new airframe
Rigel (and all),
There is not really enough info in that log to tell anything. Whenever you are having a problem I would recommend turning on the following log message set. GPS, NTUN, CTUN, CMD, MODE, PM, That set is a lot more help in debugging problems.
Frankendrone is coming out of the ER and should be back in the air by tomorrow. I'll enable the logs you've mentioned and hopefully will land my plane in one piece this time.
Please load the latest code from the Mission Planner and test that. As I mentioned before, there were rare cases of EEPROM corruption in previous versions of the code, but that's been fixed.
Just do a full Mission Planner setup, including EEPROM erase, after you loaded the new code.
What version code were you using?
We know of no issues with people have loaded the official 2.24 code from the Mission Planner. The only issues seem to crop up with earlier version of code that people modified and loaded with Arduino, which makes me suspect that they've changed something that causes memory overflows. (2.24 report state of memory in MAVlink so you should have a warning on the ground if something you've done is causing trouble)
I've been using version 2.24
From my tests, everything worked fine with 2.24 loaded both from APM Planner and Arduino IDE. Things got screwy when I added the following code:
APM_RC.OutputCh(CH_8, constrain(1500 - ((dcm.roll_sensor * 0.1) + 50),1300,1700));
APM_RC.OutputCh(CH_7, constrain(1500 - ((dcm.pitch_sensor * 0.1) * 1.7 - 30),1300,1700));
I first tried it in the fast loop which caused immediate problems when switched to AUTO and I then tried it in the medium loop which kind of worked for a while until the crash.
As soon as my Xbees are back in order I'll be able to check the memory issues. In the meantime I'll try another flight following Doug's suggestions and will post the results.
We had the same problem although we use the 2.23 firmware version. I attached the log file (at 20 % you can see the Auto mode) In Stabilized mode everything is perfect. We don't want to change the firmware version until we make sure that is solve the problem because when we tried to upgrade it,it killed the chip somehow.
Many thanks and greetings from Hungary