Arducopter 2.0.55
The latest AC2 code is posted. This is the last code before the big switchover to APM2 codebase.
What you should expect: More stability and better handling, especially if your CG is not centered.
Heres the update list from the downloads section:
Most stable flying version yet. Includes new stability patch by default and a new DCM gain and clamp value that should reduce drift due to linear acceleration in missions or long flights.
Switched rate gain calculation to use raw IMU rather than the DCM's omega. This crisps up the response a lot.
1280 has lost local flash logging, sorry, but it's just not supportable any longer.
some older tests have returned now the program memory is freed.
Remember, to use the new logging format on the 2560, you need to erase it at least once to format it.
He're the video showing just the control loop patch. The DCM patch was added later and improved the handling some more.
Jason
Replies to This Discussion
-
Permalink Reply by Rz_Ten1 on -
Btw, if anyone wants to look over the test code I was using I've attached it below. It's possible I've made some sort of non-obvious to me error, but hopefully not.
Output normally looks like this, with the failure message being when I yanked the compass:
Compass library test (HMC5843 and HMC5883L)
ArduPilot Mega BMP085 library test
Initialising barometer...
initialisation complete.
Compass auto-detected as: HMC5883L
XYZ: 188, -77, -250 Pressure:0 CPU still alive: 17
XYZ: 188, -77, -250 Pressure:83402 CPU still alive: 19
XYZ: 193, -80, -247 Pressure:83402 CPU still alive: 21
XYZ: 194, -78, -247 Pressure:83402 CPU still alive: 23
XYZ: 191, -80, -248 Pressure:83402 CPU still alive: 25
XYZ: 198, -81, -246 Pressure:83402 CPU still alive: 27
Compass Failed! No longer trying to query it...
Pressure:83402 CPU still alive: 29
Pressure:83402 CPU still alive: 31
Pressure:83402 CPU still alive: 33
Pressure:83401 CPU still alive: 35
Pressure:83401 CPU still alive: 37...and at 37 seconds everything stalls. The pressure sensor seems 'stuck' at the last reading though, so it's still not working properly. It might just need to be reinitilized, but if the code is stalled for long it doesn't really matter; the aircraft will have crashed by then. It's possible there's some timeout elsewhere that I can't get at.
Couple of other interesting facts: It doesn't always stall. When it does recover, it always seems to recover at 131 seconds. That's 131 seconds regardless of when I yank the compass. ie:
Pressure:83424 CPU still alive: 111
Pressure:83424 CPU still alive: 1310
--
Pressure:83401 CPU still alive: 37
Pressure:83401 CPU still alive: 1310 - Attachments:
-
-
i2c_hang.zip, 110 KB
-
-
Permalink Reply by Peter Seddon on -
Is this the same problem that Jani talked about a year or more ago and was the reason that I2C ESC's did not become the default for the ACM?
There do seem to be issues with the I2C bus especially with multiple masters http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html
A google turns up a number of apparently different issues that are way above my head.
Peter
-
DeveloperPermalink Reply by Marco Robustini on -
Sounds bad... :-/
-
Permalink Reply by Rz_Ten1 on
-
In this case we're not using multiple masters, it's one master and two slave devices. A very interesting article though. I did a little more fiddling just now, and it looks like the lockup greatly depends on which pins get disconnected. Losing the SDA, SDL, or VCC lines means the compass drops off, but everything remains fairly normal. Losing the Ground however, really screws things up:
That's the SCL (clock) line I'm probing. The left image is with the ground on the compass connected, and the right is with the ground disconnected. It looks like the extra bit of resistance from having an ungrounded compass is degrading the clock signal pretty significantly. Once this happens, one of two things happens: 1. There's a good chance the ATmega2560 will completely stall, and may or may not recover. 2. If it doesn't stall or stalls and recovers, the I2C bus shuts off entirely. That means no clock signals and no data signals. My probes show a nice flat line. Trying to stop and restart the TWI device though the registers is ineffective. It returns success codes for the TWI disconnect and reconnect events, but it never actually starts transmitting again.The best recommendation I can make at the moment make sure the ground line is REALLY well attached. Adding timeouts to the twi/wire libraries doesn't do much it seems.
-
DeveloperPermalink Reply by Marco Robustini on -
Ok Rz_Ten1, what do you mean with "ground line"? The negative of all the electronic?
In my configuration i've distribuition board and all the "-" of all the electric component (APM, IMU, ESC, BEC) are to the negative pole (ground line).
-
Permalink Reply by Rz_Ten1 on
-
The negative line (usually black) is synonymous with the ground. I don't like calling it the negative line as it is possible to have actual negative voltages, ie: -12V. In my case ground means the 0V or common line; the line in which all other voltages are measured against. :)
-
Permalink Reply by Arnt-Inge Hansen on -
Nice work Rz. I think a simple and temporary solution would be to find good grounding points on the compass board and apm board and solder a wire between them in case of ground loss.
-
Permalink Reply by Rz_Ten1 on
-
Edit: I originally said we should detect a compass disconnection and stop querying it if that happens. It looks like as long as the loss is on anything other then ground, as soon as it's reconnected it begins working normally again.
Sorry, I missed the edit window on the last post.
-
DeveloperPermalink Reply by Jean-Louis Naudin on -
Hello Jason and All,
I have just done a quick test flight with the Arducopter v2.0.55 on my QRO quadcopter and all seems OK with the same PID setup (see below) that I have used with the v 2.0.54 + stability patch. I have tested only the STABLE and ALT_HOLD mode due to the bad weather here. The roll/pitch attitude seems very stable in spite of gusts and a strong lateral wind.
Regards, Jean-Louis
-
Permalink Reply by Arnt-Inge Hansen on
-
It sounds great, is there any file I have to change/mod before installing 55. I will try it soon :)
-
DeveloperPermalink Reply by Jean-Louis Naudin on -
Hello, I found a small problem on the log with the 2.0.55... The baro_alt recorded in the log is still 0 in the log file... I have cheched that the variable baro_alt is updated in the firmware and it works well for the ALT_HOLD mode. The problem is set only for the log.
DataFlash.WriteInt(baro_alt); // 5
log -> CTUN, 0, 69, 379, 0, 0, 10, 0, 0, 0, 0, 18, 379, 0, 0
Does someone as this problem ?
Regards, Jean-Louis
-
Permalink Reply by Arnt-Inge Hansen on
-
Is this log problem related to mp .99
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
-
ArduRover User Group
184 members
-
Moderators
24 members
-
ArduCopter User Group
1283 members
-
ArduCopter (traditional …
180 members
-
Queensland
4 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
