ArduCopter-3.0.1 released!

Simon October 2, 2013 at 4:29am

@ MHA

Re. TBS Discovery geometry - take a look at the Discovery manual. The angles you want (55 deg and 125 deg) are the angles between the centre line and the motor axis to CoT point.

Max Levine did an earlier post re the set-up.

Hope this helps.

I'm in the process of designing a similar frame to accommodate a 3-D printed brushless gimbal and want to ensure that the props are out of the field of view, so have been down this route recently.

Peter October 2, 2013 at 3:39am

Any news if the gps glitch fix wil be implemented in rc3?

And when can we expect rc3?

Moderator

Graham Dyer October 1, 2013 at 11:06pm

Further to my problem with my external magnetometer working but the APM not seeming to recognise it's output.

1) The onboard-magnetometer-disabling-trace is cut, ext mag (HCM5883L) is mounted 10cm above the frame, compass-dance done.

2) The magnetometer is giving valid magnetic field strength in x,y, and z directions (Mx, My, Mz), visible in the status tab in MP and apparent in both the logs (attached) and the pics below.

3) Sometimes the APM sees this data, sometimes it doesn't! No discernible pattern.

Is there anything in code that could cause this oddity intermittently with an external magnetometer?

Pic1: Rotating just the Mag, 'Y' value changes but yaw/heading (red) does not. (incorrect)

Pic2: Rotating the Mag, 'Y' value changes and yaw/heading changes. (correct)

Ext_Mag_working_2013-09-29 18-16-19.tlog

Ext_mag_not_working_2013-09-28 12-01-44.tlog

criro1999 October 1, 2013 at 4:11pm

Testing again 3.1-rc2.

I did notice that INS_MPU6K_FILTER is default as 0 zero, when installing the firmware after on a reset/erase on APM2.5.

Is that normal to be zero as default? Usually I did have it as 20 in previous releases.

Also I did notice that the vertical speed on Auto is like 2x slower on 3.1-rc2 comparing to 3.0.1, although WPNAV_SPEED_UP is 250 on both. Something is weird.

I can increase this value, but I would like to know the correct value.

I am doing missions at 80m altitudes like this and time to arrive as such altitude is like almost doubled.

Search Results for “criro1999-aerial” | 360Cities

Search 360Cities’ large database of 360° panorama content for your VR, advertising, game, or publishing project.

Rob_Lefebvre September 30, 2013 at 10:42am

I'm going to pop this processor loading thing up into a new reply. Joe Abrams has questioned the validity of my testing, in a somewhat disrespectful way, over at RCG (along with his snarky comments here). Also, I want my findings to NOT be true. So I am offering a bounty of $50 to anybody who can prove this is NOT a real problem, and show me where I've gone wrong. Seriously.

First, I'll present my test methodology:

The problem started when I was trying to use my H8 for a specific video shot, which is nothing more than a simple climb to altitude while holding position. I have the camera on an AlexMos type gimbal, and I've got the Camera Mount running, but only in a minor way. I'm simply using it to do Ch8 to Ch11 pass-through, without even any stabilization, in order to simply control the pitch of the AlexMos. I've been struggling with poor performance of Alt Hold for a while, fiddling with the PID, and could never get it where I was happy with it. On Tuesday was the first time I tried using Simple mode in Loiter, and the results were quite bad, so I stopped until I could figure out what was wrong.

So on Saturday, I took my Nerf Quad (a Tarot F450 frame) and started doing a specific test, in a controlled manner, to load up the processor. The first problem was that it's a quad, not an Octo. Randy had a good idea to program it as an XOcto or Octa-Quad. You can do this easily if you just switch motor wires 2 for 3, it's obvious when you look at the motor matrix that you can do this.

So that's what I did. A series of tests, in Quad mode, and in XOcto mode, while turning various features on and off. Each flight I attempted 2 climbs in Alt Hold mode, and 2 climbs in Loiter. Then I would download the logs and have a look. Pretty simple. You will find all of my data logs here, and you will find all the log titles fairly descriptive:

https://drive.google.com/folderview?id=0BzWH4Q7IAU5YSnBOS0FkdXBlX3c...

Here's sort of how I got started on this path. Early on, I noticed that the climb rate was different between Alt Hold and Loiter. This, despite the fact that they use the EXACT same controller. Obvious I was holding full up throttle in both tests, and you can see the DCRate which is Desired Climb Rate, is exactly the same in both.

So why is that? It's because of this line in the Alt Hold controller:

controller_desired_alt += target_rate * 0.02f;

That 0.02f is the rate that we are integrating the target rate. It's a hard-coded assumption that this function runs 50 times per second. If that function were not to run 50 times per second, then the target altitude would not increase at the desired rate, and the actual rate will fall behind the target rate. So that was my first clue that the Alt Hold controller was not running as often as it should. The AH controller is run under the "50 Hz loop". But this controller does not necessarily run at 50 Hz. It tries to, but it will get the boot if the processor is running too slow for the main 100Hz loop to run at 100 Hz.

I proved this out by hacking up the program such that the AH Loop calculates how often it is being run, and replace that 0.02f with the real rate it's running at. Now the WPAlt should ramp up at the correct rate. This test is contained in the datalog with "timer" in the title. So here you can see that this fixes the ramp rate problem.

But this just masks the problem, it does not solve it. The problem is not the climb rate, that is just a symptom of the problem that the 50Hz loop is not running fast enough. And that was in Quad mode! So, I kept going, to see how bad it gets.

Here you can see some tests with a Quad. I can actually infer what rate the 50Hz loop is running by looking at the actual climb rate. In the first example, it climbs at 200 cm/s in Loiter, with a target at 250 cm/s, so I would guestimate it's running at about 40Hz. With Mount turned on, it appears to be running about 38Hz.

Ok, so what about Octos?

Well, first we have an XOcto, without Mount or Simple Mode. Doesn't look too bad, but I can see the AH is only running at 20Hz!:

Now, let's turn Mount on. Uh Oh! Look at that Baro. You can hear the motors surging. This is because as the processor slows, the scheduler starts booting Baro Accumulate, which is what filters the baro:

And finally, we come to XOcto with Simple and Mount running. This is where the process completely breaks down. Look at the baro data! It's gone to hell, and it's dragging WPAlt with it! This thing tried to fly away, fell to the ground, all sorts of stuff. I tried running this test several times, but it kept crashing.

All of this testing was done with the EXACT same machine, in exactly the same environmental conditions, over the span of about 2 hours.

Dimitri September 30, 2013 at 1:56am

Quick question. Do I have to re-calibrate everything (compass, accell, radio, compassmot) after loading a newer firmware?

I did not do this after loading 3.1-rc2. If this is needed, I will have to report back with my Loiter results (funny thing the word Loiter in Dutch almost sounds like "Leuter". You don't wanna know :p)

Rgds,

Dimitri

Ian September 29, 2013 at 6:12pm

Can anyone tell me if ROI is working on this or the 3.1RC2 beta?

I tried both ROI, and DO Set ROI

With ROI I set a waypoint, then set ROI then more waypoints, and when it hits the ROI item it just sits in loiter forever.

With Do Set ROI it goes to the next waypoint looking at the ROI Lat-Lon as set, however on the following waypoints it goes back to facing towards the next waypoint.

So Do Set ROI works, but I have to set

WP

DO Set ROI

WP

DO Set ROI

Any idea's?

Also when setting ROI or DO SET ROI there are 4 zero's, lat lon, alt and grad. Any explanation for what these do, or how they should be set?

Xerravon September 29, 2013 at 6:02pm

Hi,

I have been trying to get an Octa-quad working correctly and I have one problem I cannot solve. it is the same problem as I brought up here a while ago.

the copter works great except in althold or loiter when I try to control the throttle it does not respond properly, very slow to ascend or descend and the motors spurt. say I am in loiter, I move the throttle to full and for 3 or 4 seconds nothing, then it may start to rise, then stop "hover" then another spurt of power and up again. descending is the same,in loiter, I decrease throttle to zero, sometimes it will still hover, then after some seconds it may start to descend, again in spurts. also in land mode it sometimes just hovers then when it does descend it is very slow.

It does this with even the 3.01 stable FW, it also does this with any FW I have tried from after august (RC2 I just tried) but the very first FW I tried on this Octa-quad did and still does seem to work properly it is the firmware dated 2013-07-27-01:07. with this it seems fine. also I have tried this with a PX4 on the same octa-quad, just swapped the APM25 and the throttle control problems go away with any FW I have tried (I have other worse compass problems with the PX4, so Ive about given up on it)

I dont know what to try, I have rebuilt this copter a couple times. there are some big differences in the params from the FW that works and the ones that do not, I will attach a pic of the differences. I also have a log file.

thanks for any help,

John

2013-09-29 19-29 1.log

parm diffs julyFW to althold throt problemFW.jpg

baris alp September 29, 2013 at 12:44pm

I'm testing 3.1rc2 for 3 days. Everything was perfect. But today;

Loiter was engaged full time at the video it flew unknows location with 11 sats and 1.47 hdop. My gps working 5hz but i saw gps time strange jumping. This may be a problem?

https://www.youtube.com/watch?v=4WeM1KJRVtE&feature=youtu.be

2013-09-28 22-37 59.log

Waladi September 29, 2013 at 10:00am

Hi All,

Little help please..

This is the first time I am using HK ESC F20A stock firmware (not SimoK as I usually used) but I still cannot calibrate the esc, anyone using the same ESC and succeed to calibrate the ESC?
I'm using HK 3.01 and Radio calibration was repeated several times and successfully calibrated. But compassmot error said "Throttle not zero, exiting", is it because the ESC's not calibrate?
Assuming the ESC is not yet calibrated, I cannot arm the board even if the ARMING_CHECK parameter was set to "0" = Disabled. Is it normal to unable to arm even though ARMING_CHECK parameter was set to "0" with ESC not calibrated yet?

Thanks in advance.

Waladi

Discussions

ArduCopter-3.0.1 released!

Replies

Activity