MultiWii

Hi guys,

Just a question is it normal my cycle time on 1.9 is 6000 before on the last dev it was 4800 ?

Thanks for your answer

Yes,
4800 is too low to be stable for this config.
6000 is a proven working cycle time with WMP+NK.

I've got a cycle time of 4500 with the latest version this has not changed from the earlier versions.
Why is this too low?
My T-copter is flying very well.

-WM+ genuine
-BMA020
-BMP085
-HMC5883

Thanks so just one more question : I constated that the 1.9 looks more "agressive" in flight. I can imagine that the cycle time has an inflance on the Pid factors, but witch one ?
In theory more cycle time need less P or not? Is there a law ?

Bledi wrote:Thanks so just one more question : I constated that the 1.9 looks more "agressive" in flight. I can imagine that the cycle time has an inflance on the Pid factors, but witch one ?
In theory more cycle time need less P or not? Is there a law ?

Normally with a shorter cycle time, you should be able to raise a little bit P.

I made major modifications to MultiWii 1.9 in order to make it work with the ATmega128RFA1 , which has a built-in 2.4 GHz radio right inside the chip.

After the modifications and using the serial port, the cycle time is about 2200.

I made more code changes that redirected all serial port data to the radio instead, so I can plug my custom "transmitter" (another ATmega128RFA1 circuit) into MultiWiiConf instead of plugging in the quadcopter itself, so I can use MultiWiiConf while flying.

This code change raised the cycle time to about 2500, because the "on receive data" interrupt is slightly longer.

You guys say that 6000 is normal.

My question is: Am I making an improvement? Or is this change going to have a negative impact? Is there such a thing as "too short cycle time"?

Hi,
this is a good question Franck.
Mine is the following: could Alex or somebody experienced with MWII could give us a range of "good" and "bad" cycle time for the 1.9 version ?

Something like:

1) for WMP only I2C device connected onboard
good: 3500 to 7000
bad: <3500 or >7000

2) for WMP+NK I2C devices connected on board
good: range
bad: another range

...

I'm running v1.9 and had cycle time around 3600 with only a WMP on board.

Thanks !

I have about 2600 with 1.9 if my memory is correct. (cant check it right now)

I have ITG3200, NK (i2c connected), BMP085, HMC5883 and running i2c on 400Hz.
But I have very weird behavior, it is "shaking" in the air, both in stable and acro-mode.
But this is with totally uncalibrated PID. This is about my first time this Quad is up in the air.
Don't know if this is SW related or something with the ESC.

It was stable with 1,8 patch1 before I rebuilt the sensor board and added the pressure sensor and the magnetometer, but same shaky behavior with 1,8 patch1 now.

Edit: The cycle-time is between 2800 and 3100.
I get ~3400 with 100Khz i2c. (with all sensors active)

I get 1600 in cycle time with only ITG3200 and 400Khz.
2400 with ITG3200,NK and 400Khz.

my data is taken from a quad that uses ITG-3200 and BMA180 on 400 KHz. In a few days I might be able to make another prototype that uses a MPU-6000 instead, I think I can get both accelerometer and gyro data in one long I2C transaction

Niclas, did you get your data with your radio transmitter active?

Also I solved the shaky problem by raising D a bit, try that

Hi,
The cycle time depends clearly on the config.

For WMP+NK config (clone or not), it should be 6000 (+/-10), and more if you need to change the interleaving delay.
For a WMP only config at 100kHz: around 3200
For a WMP only config at 400kHz (ie clones): around 2100
For an ITG3200 config only: less than 2000
For a (WMP at 400kHz or ITG3200) + ACC (other than NK) : around 2600
For a full 9DOF+baro board: around 3000

I think every cycle times bellow 4000 should give a similar flight attitude.

The specific WMP+NK config is known to be less stable due to its quite high cycle time.

Frank> I get about the same time with/without the Tx active. (it decreases about 50-100 when i activate the Tx)
Good info about D-value. I'll try that! How much did you raise it?

The lower cycle time the better? Or am I'm wrong on that point? We get better refresh-rate from the sensors, and that's good in my world.
But maybe that requires some tweaking in the control loops then?

Edit:
My cycle time is quite "jumpy", it differs between 2700 and 3000, it that normal?