Originally Posted by thebgrian

Good that you have your tri flying Will you mind posting your tri specific settings?
Especially for the servo and servo reversing.

I don't have too many advanced param settings:

For reversing yaw on the tail servo it's RC7_REV set to -1...Options are -1 and 1

AHRS_GPS_GAIN = 0 - but I will eventually turn this on - this requires a gps lock to function properly

INS_MP6k filter is set to 20

I have some acro settings too - but it's too early to say if those are any good. Now that I have my issues worked out - I can move on to PID tuning the autopilot settings.

For PIDs I have:
STAB_P 3.5
RATE_P 1.0
RATE_I 1.0
RATE_D .004

Using just those settings as well as the 2.9 defaults this thing flies like a dream, I mean wow - really smooth and locked in. Once I get altitude hold tuned - I'll finally be able to putt around without a deathwish.

Wish me luck guys!! my MinimOSD arrived today and I'm tearing down my quadcopter to install it and an onboard microphone..

my blog: http://fpv.techenthusiast.info

It's good to see you posting again - I'd wondered what happened to you - we practically lifted off together almost a few weeks apart then you disappeared!

You need a plane with all that space out there man

Originally Posted by Mochaboy

It's good to see you posting again - I'd wondered what happened to you - we practically lifted off together almost a few weeks apart then you disappeared!

You need a plane with all that space out there man

Thanks! yeah once Winter hit I crawled into a hole until just recently...

I am planning on getting a plane sometime

Originally Posted by Mochaboy

The devs chose 20hz as a good starting point, so that's where mine is. I should mention though that this rig is practically vibration free. Everything was dynamically balanced before I installed them (motors as well as blades)

The reason I ask is that it states in the description that 42 hz is the correct default for Aducopter.

Obviously my gimbal jitter was fixed by this setting change so I thought a similar jitter issue in the esc/motor control might be present.

Just tapping the frame with my finger would get the gimbal going wild before going from 0 to 42.

Cheers,
Andy

Originally Posted by jazzboy

The reason I ask is that it states in the description that 42 hz is the correct default for Aducopter.

Obviously my gimbal jitter was fixed by this setting change so I thought a similar jitter issue in the esc/motor control might be present.

Just tapping the frame with my finger would get the gimbal going wild before going from 0 to 42.

Cheers,
Andy

That's absolutely right - the initial default for this was 42hz, but remember this was the release candidate not the full tested release. Things change all the time. In release 2.9.2 you'll probably see that default change to 20 based on the feedback they've been getting from their users.

That particular feature is a noise filter that slows down the rate at which updates are read from the MPU6000 gyro/accelerometer. Vibrations resonate at a certain frequencies depending on where they emanate from, so that filter was introduced to dampen vibration readings.

I'm not sure if they chose a nyquist algorithm or a simple high pass filter to smooth out those readings, but the idea is that if you have a frame that has bad motor bells or even worse out of track or out of balance props, that filter will at least help to dampen the effects to the gyro.

Running it at full speed is the same thing as running at 0, so the ranges they suggest are #'s like 10 for badly vibrating frames, and 20 and up for so so frames. If you have a perfectly vibe free frame, then yeah - 42 would help.

The jitters you're seeing in the servo though - I wonder if that's noise coming from some other area of the system. If you can post telemetry logs of your chan 1-4 inputs as well as outputs we can see what the servos are doing.

Ultimately if you found something that works - stick with it...who cares why it works - the number of failure points in these rigs is such that if you spent every waking minute chasing every problem - you'd never fly (do I sound like I speak from experience _)

***
On a separate note, Randy, one of the devs from APM got back in touch regarding my problem - despite the fact that I'm running a clone (that was very cool of him by the way).

There were 3 changes to the PPM Encoder as well as the APM core code. The PPM encoder changes allowed receivers like the TFR4-B to be used. Prior to that - only receivers capable of outputting 8 channels over PPM could be used.

The other change was much larger. They changed the way digital inputs are read using a different method of interrupt handling. He pointed me at the earlier 2.8 code for the interrupt handling and I'm going to try my hand at changing the code to see if that fixes the PPM problem.

Here's where I'm at with the Tricoptex

These go back together a lot faster than they tear down. phew:

Originally Posted by Mochaboy

That's absolutely right - the initial default for this was 42hz, but remember this was the release candidate not the full tested release. Things change all the time. In release 2.9.2 you'll probably see that default change to 20 based on the feedback they've been getting from their users.

That particular feature is a noise filter that slows down the rate at which updates are read from the MPU6000 gyro/accelerometer. Vibrations resonate at a certain frequencies depending on where they emanate from, so that filter was introduced to dampen vibration readings.

I'm not sure if they chose a nyquist algorithm or a simple high pass filter to smooth out those readings, but the idea is that if you have a frame that has bad motor bells or even worse out of track or out of balance props, that filter will at least help to dampen the effects to the gyro.

Running it at full speed is the same thing as running at 0, so the ranges they suggest are #'s like 10 for badly vibrating frames, and 20 and up for so so frames. If you have a perfectly vibe free frame, then yeah - 42 would help.

The jitters you're seeing in the servo though - I wonder if that's noise coming from some other area of the system. If you can post telemetry logs of your chan 1-4 inputs as well as outputs we can see what the servos are doing.

Ultimately if you found something that works - stick with it...who cares why it works - the number of failure points in these rigs is such that if you spent every waking minute chasing every problem - you'd never fly (do I sound like I speak from experience _)

***
On a separate note, Randy, one of the devs from APM got back in touch regarding my problem - despite the fact that I'm running a clone (that was very cool of him by the way).

There were 3 changes to the PPM Encoder as well as the APM core code. The PPM encoder changes allowed receivers like the TFR4-B to be used. Prior to that - only receivers capable of outputting 8 channels over PPM could be used.

The other change was much larger. They changed the way digital inputs are read using a different method of interrupt handling. He pointed me at the earlier 2.8 code for the interrupt handling and I'm going to try my hand at changing the code to see if that fixes the PPM problem.

Thanks for the excellent breakdown. I guess the upshot is that if 42hz works my rig ain't too bad. ;-)

And good luck on getting your coding all sorted. I am really impressed with how 2.9r5 flies. Pretty much like my Logo 500!


Cheers
Andy

Tricoptex maiden running MPNG 2.9...nothing special here, just wanted to fly for 5 minutes without crashing.

Mission accomplished. Despite the twitches I LOVE the way this flew...5 minutes of tuning got me to this level of flight stability.

Tricoptex Maiden Crius MPNG 2.9 APM - Blizzard Meet of '13 (0 min 0 sec)

Originally Posted by Mochaboy

Tricoptex maiden running MPNG 2.9...nothing special here, just wanted to fly for 5 minutes without crashing.

Mission accomplished. Despite the twitches I LOVE the way this flew...5 minutes of tuning got me to this level of flight stability.

http://www.youtube.com/watch?v=-BKuzQXwVjE

Great Video! Nice snow also!... you didn't crash at all

Which pin do I connect a Max Sonar EZ0 to?

Should I be using the analog output of the EZ0?

Originally Posted by bwww

Which pin do I connect a Max Sonar EZ0 to?

Should I be using the analog output of the EZ0?

Max sonar doesn't supported by MPNG!

You can only use DYP-ME007 or similar.

Maybe if users show more support by donating, I can buy sonar like this and add support for it. But now, since I have no it, I can't add it.

EDIT: But I would to say: Latest firmwares doesn't rely on sonar in Alt Hold mode (Used only Baro and Accelerometer based inertial navigation). Now sonar only used to track surface.

I have a hc sr04 sonar which I was planning to use with megapirateng, am I to assume that this will not work as well?
Bought hc sr04 as that was in the megapirateng/Crius aiop pdf guide

Originally Posted by dinislam1395

I have a hc sr04 sonar which I was planning to use with megapirateng, am I to assume that this will not work as well?
Bought hc sr04 as that was in the megapirateng/Crius aiop pdf guide

As far as I know:
HC-SR04 has maximum distance up to 2m
DYP_ME007 has maximum distance up to 4m

But yes, you can use both sonar types.

Thanks, I shall use it since I already have it. As for powering the sonar does it get the power from the board because I am using external bec to power the whole board.