Joachim08 wrote:I am just changing from MK to Multiwii and have changed from 1.9 to pre4. I am using a quad with BMA020, WMO and D&I Board. After changing the direction for ACC-Roll and ACC-Pitch and calibration of the acc i recognized that ACC-Z is only around 64 instead of 256 with 1.9. Is that correct ?.
yes it is correct, it's due to the new 8G settings for BMA020
Alex, thanks thats understood now.
If you have time, can you check your code for the "toilet bowl effect" when on ACC hold with BMA020 ? Also others have experienced the same problem, maybe and decay value in PID control ?
I'm testing my new FREEIMUv04 and im my opinion, seeing the beaviour of ACC angle corrections in GUI There is a better angle calculation if you put in MPU6050 ACC section in sensors.pde
If you have time, can you check your code for the "toilet bowl effect" when on ACC hold with BMA020 ? Also others have experienced the same problem, maybe and decay value in PID control ?
Is there a remote possibility that the BMA020 is defective?
mgros wrote:I'm testing my new FREEIMUv04 and im my opinion, seeing the beaviour of ACC angle corrections in GUI There is a better angle calculation if you put in MPU6050 ACC section in sensors.pde
Any solution to the issue due to funny characters and messed up navigation on the LCD for the Crius in MultiWii v 2.0?
PedAnd
I confirm that Crius Multiwii Board don't work on V2.0 pre 4 with standard serial LCD, it shows the words and values messed up among other funny characters.
Is it normal that Baro shows negative results in GUI in pre4
If I Enable Baro on my 8" Quad it jumps 3m up and fall down and so on. I have Alt PID reduced to 0.7/0.015/7 doesn't change. The Baro curve looks good in GUI - normal up/down like a sinus curve. I have no i2c errors
ciskje wrote:Earth magnetic field is [0.2;0.7] (from equator to the poles) Gauss Positive BIAS during init for x&y is 1.16 Gauss, z is 1.08 (check this difference Alex!) Maximum field is so 1.86 Gauss We can work without problem with 1.3 Ga scale. (and a lot far away from overflow with the 2.5Ga during init).
If you can overflow it, it is a soft or hard iron problem (motors, speakers, or too much metal near the sensor).
Hi, The spec is not so clear for me. The spec says: "For example, if the configuration register B is set to 0x60 (Gain=3), values around +766 LSB (1.16 Ga * 660 LSB/Ga) will be placed in the X and Y data output registers and around +713 (1.08 Ga * 660 LSB/Ga) will be placed in Z data output register." So I understand it's an example of what could be measured, but not a specific scaled factor.
page 2 (summary specifications HMC5883L):
Self Test X & Y Axes ±1.16
Z Axis ±1.08 gauss
BIAS are different for x&y and z.
ok, right. I didn't look enough at this page I will correct it in the next version
Joachim08 wrote:I am just changing from MK to Multiwii and have changed from 1.9 to pre4. I am using a quad with BMA020, WMO and D&I Board. After changing the direction for ACC-Roll and ACC-Pitch and calibration of the acc i recognized that ACC-Z is only around 64 instead of 256 with 1.9. Is that correct ?.
yes it is correct, it's due to the new 8G settings for BMA020
Alex, thanks thats understood now.
If you have time, can you check your code for the "toilet bowl effect" when on ACC hold with BMA020 ? Also others have experienced the same problem, maybe and decay value in PID control ?
I've not experienced the same effect, so difficult to analyse...
Waldmensch wrote:Is it normal that Baro shows negative results in GUI in pre4
If I Enable Baro on my 8" Quad it jumps 3m up and fall down and so on. I have Alt PID reduced to 0.7/0.015/7 doesn't change. The Baro curve looks good in GUI - normal up/down like a sinus curve. I have no i2c errors
The absolute altitude given by the baro is not accurate at all and could be negative. It depends on the current atmospheric pressure.
mgros wrote:I'm testing my new FREEIMUv04 and im my opinion, seeing the beaviour of ACC angle corrections in GUI There is a better angle calculation if you put in MPU6050 ACC section in sensors.pde
confirmed! i use a MPU only setup .. so if i tilt it vertical it overshootes with z 255 .. with z 512 it looks right.
regards
Felix
everyone is right here explanation: http://forum.sparkfun.com/viewtopic.php?f=14&t=30624 I got one of the first series and the code is for it. You probably have recent one with acc scale MPU bug corrected. I will correct it for the 2.0
The oversampling setting was reduced from 8 to 4 samples. The reason was to get more unique samples. But in my opinion now the processor does exactly the same what the BMP085 does internally. Unless there is a bug in the internal oversampling, this is only a waste of CPU time. I have set the oversampling back to 8 samples witout any visual difference...
The BMP085 needs roughly about 3-4.5 milliseconds for one sample. Either the chip averages up to to 8 samples internally (faster), or you read every sample yourself and make an average in code. Since the pressure calculation is relatively complex, your can save a lot of CPU time (at least for the 8 bit AVRs).
The oversampling setting was reduced from 8 to 4 samples. The reason was to get more unique samples. But in my opinion now the processor does exactly the same what the BMP085 does internally. Unless there is a bug in the internal oversampling, this is only a waste of CPU time. I have set the oversampling back to 8 samples witout any visual difference...
It was a mod made by marbalon. I don't know if it makes a difference in flight, by it works. I understand your view, but I think it was a way to introduce more samples in the moving average vector.
Alexinparis wrote:... but I think it was a way to introduce more samples in the moving average vector.
marbalon said, he had more *unique* samples now. But that isn't true, since now are even less samples taken -> The internal averaging is a bit faster and you'll save the time for the temperature sampling. With 8 times oversampling you can reduce the average vector to half length with the same result.
Waldmensch wrote:Is it normal that Baro shows negative results in GUI in pre4
That depends on the height above sea-level where you are living. The calculated height is based on an atmospheric pressure of 1013 hPa. At the the moment, we have a pressure of about 1030 hPa here. The calculated height is therefore about 100 m lower that the reality.
Joachim08 wrote:...and i cannot use it because of the toilet bow effect with ACC on and BMA020... Looks like if have to get other sensors.....
Maybe a bit of debugging and fixing the problem is an option too
One yaw rotation in 20 seconds is not much. Did you already try to compensate with trim? Does the level functionality work beside this rotation?
Unfortunately i am not a coder....
It is not a yaw movement. Hm how can i describe it..... Maybe i will try to shot a video.... It looks similar like this : http://www.youtube.com/watch?v=txT1oh-BpPI ... when ACC is on. Level doesnt work because of this effect. Changing PID didnt help. It is working on 1.9 so i dont think its a problem with BMA020 or my quad
Alexinparis wrote: Better efficiency for hardware pwm: digitalWrite arduino function was removed in order to address directly the output ports. One consequence: motor order is no more easily configurable.
is there no chance to modify motor-outs anymore? that would be the only drawback for me and some others, who burnt a single motor-out pin from their flyduino mega...
seems that i have to change my "handicapped" mega to a new one.
It's less easier to modify the order, but it's still possible. It's just more complicated than moving 2 numbers.
i took a looooong look at the code, but i got no idea how to solve my motor-order problem ........
is there someone with a hint, how motor-order can be changed?
hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem? thanks best regards
motor suppo 2212 1000kv esc hobbywing skywalker 20a
Cronalex wrote:hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?
If you are using level mode, calibrate ACC before use!
Today I spent some time around the part to move up and running, unfortunately it has not succeeded,
So GPS LED indicates RX to RX, TX GND on TX of course connected to 5 volts also.
kommmentiert in software GPS Serial 2, at 9600 baud to 4800 and also trying times 115200, all Tries with different serial ports Bautraten no GPS feature both in space and outdoors. it all takes on the MEGA board with Bmp 020, 085 and also the Mag Bma values so the GPS.
What did I do wrong, by the way on the 1.9 is not the part that
Cronalex wrote:hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?
If you are using level mode, calibrate ACC before use!
no level mode activate .. No functions Activate .. start quadcopter gyro
Cronalex wrote:hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?
If you are using level mode, calibrate ACC before use!
no level mode activate .. No functions Activate .. start quadcopter gyro
Do the copter movings match the ones displayed in the Gui? Maybe some sort of orientation error? ...just a guess
Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor... the link on discussion... viewtopic.php?f=8&t=1290&start=180#p10679
Cronalex wrote:sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta
#define MMGYRO // Active Moving Average Function for Gyros #define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector
The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros
moving average of the gyros is really good... I have to try that on the accelerometers I keep you informed!!!
for now I have a problem loading I get this error:
MultiWii_2_0.cpp: In function 'void getEstimatedAltitude()': MultiWii_2_0:1337: error: 'AccZHigh' was not declared in this scope MultiWii_2_0:1337: error: 'AccZLow' was not declared in this scope
stay tuned!!!
Magnetron wrote:Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor... the link on discussion... viewtopic.php?f=8&t=1290&start=180#p10679
if it works it works like that of the gyroscopes is a bomb ... is to be loaded in the next version
Cronalex wrote:sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta
#define MMGYRO // Active Moving Average Function for Gyros #define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector
The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros
moving average of the gyros is really good... I have to try that on the accelerometers I keep you informed!!!
for now I have a problem loading I get this error:
MultiWii_2_0.cpp: In function 'void getEstimatedAltitude()': MultiWii_2_0:1337: error: 'AccZHigh' was not declared in this scope MultiWii_2_0:1337: error: 'AccZLow' was not declared in this scope
stay tuned!!!
Magnetron wrote:Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor... the link on discussion... viewtopic.php?f=8&t=1290&start=180#p10679
if it works it works like that of the gyroscopes is a bomb ... is to be loaded in the next version
you are a big Magnetron!!!
Hi, here is a fully barometric routine that will solve your problem:
if (currentTime < deadLine) return; deadLine = currentTime + UPDATE_INTERVAL;
//**** Alt. Set Point stabilization PID **** //calculate speed for D calculation last = BaroHistTab[BaroHistIdx]; BaroHistTab[BaroHistIdx] = BaroAlt/10; BaroHigh += BaroHistTab[BaroHistIdx]; index = (BaroHistIdx + (BARO_TAB_SIZE/2))%BARO_TAB_SIZE; BaroHigh -= BaroHistTab[index]; BaroLow += BaroHistTab[index]; BaroLow -= last; BaroHistIdx++; if (BaroHistIdx == BARO_TAB_SIZE) BaroHistIdx = 0;
BaroPID = 0; //D temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 40; BaroPID-=temp32; EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2); temp32 = AltHold - EstAlt; if (abs(temp32) < 10 && BaroPID < 10) BaroPID = 0; //remove small D parametr to reduce noise near zoro position // Magnetron1 (Michele Ardito) Trusted Z Acc #if defined(TRUSTED_ACCZ_VEL) BaroPID -= D8[PIDVEL]*(AccZHigh - AccZLow) / 30; #endif
//P BaroPID += P8[PIDALT]*constrain(temp32,(-2)*P8[PIDALT],2*P8[PIDALT])/100; BaroPID = constrain(BaroPID,-150,+150); //sum of P and D should be in range 150
//I errorAltitudeI += temp32*I8[PIDALT]/50; errorAltitudeI = constrain(errorAltitudeI,-30000,30000); temp32 = errorAltitudeI / 500; //I in range +/-60 BaroPID+=temp32; }
Cronalex wrote:sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta
#define MMGYRO // Active Moving Average Function for Gyros #define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector
The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros
moving average of the gyros is really good... I have to try that on the accelerometers I keep you informed!!!
for now I have a problem loading I get this error:
MultiWii_2_0.cpp: In function 'void getEstimatedAltitude()': MultiWii_2_0:1337: error: 'AccZHigh' was not declared in this scope MultiWii_2_0:1337: error: 'AccZLow' was not declared in this scope
stay tuned!!!
Magnetron wrote:Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor... the link on discussion... viewtopic.php?f=8&t=1290&start=180#p10679
if it works it works like that of the gyroscopes is a bomb ... is to be loaded in the next version
you are a big Magnetron!!!
Hi, here is a fully barometric routine that will solve your problem:
if (currentTime < deadLine) return; deadLine = currentTime + UPDATE_INTERVAL;
//**** Alt. Set Point stabilization PID **** //calculate speed for D calculation last = BaroHistTab[BaroHistIdx]; BaroHistTab[BaroHistIdx] = BaroAlt/10; BaroHigh += BaroHistTab[BaroHistIdx]; index = (BaroHistIdx + (BARO_TAB_SIZE/2))%BARO_TAB_SIZE; BaroHigh -= BaroHistTab[index]; BaroLow += BaroHistTab[index]; BaroLow -= last; BaroHistIdx++; if (BaroHistIdx == BARO_TAB_SIZE) BaroHistIdx = 0;
BaroPID = 0; //D temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 40; BaroPID-=temp32; EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2); temp32 = AltHold - EstAlt; if (abs(temp32) < 10 && BaroPID < 10) BaroPID = 0; //remove small D parametr to reduce noise near zoro position // Magnetron1 (Michele Ardito) Trusted Z Acc #if defined(TRUSTED_ACCZ_VEL) BaroPID -= D8[PIDVEL]*(AccZHigh - AccZLow) / 30; #endif
//P BaroPID += P8[PIDALT]*constrain(temp32,(-2)*P8[PIDALT],2*P8[PIDALT])/100; BaroPID = constrain(BaroPID,-150,+150); //sum of P and D should be in range 150
//I errorAltitudeI += temp32*I8[PIDALT]/50; errorAltitudeI = constrain(errorAltitudeI,-30000,30000); temp32 = errorAltitudeI / 500; //I in range +/-60 BaroPID+=temp32; }
yes DONE COMPILING
THE FUNCTION MUST BE // ?? to use the moving average on accelerometers:
/* This option should be uncommented if ACC Z is accurate enough when motors are running*/ /* should now be ok with BMA020 and BMA180 ACC */ //#define TRUSTED_ACCZ
//#################################################################### // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta // if the I2C speed is 100kHz use MMGYROVECTORLENGHT from 2 to 6 best was 2 and MMACCVECTORLENGHT from 4 to 10 best was 6 // if the I2C speed is 400kHz use MMGYROVECTORLENGHT from 2 to 6 best was 4 and MMACCVECTORLENGHT from 4 to 12 best was 8 //#define MMGYRO // Active Moving Average Function for Gyros #define MMGYROVECTORLENGHT 4 // Lenght of Moving Average Vector // Moving Average Accelerometers by Magnetron1 //#define MMACC // Active Moving Average Function for Accelerometers #define MMACCVECTORLENGHT 8 // Lenght of Moving Average Vector // Moving Average ServoGimbal Signal Output //#define MMSERVOGIMBAL // Active Output Moving Average Function for Servos Gimbal #define MMSERVOGIMBALVECTORLENGHT 16 // Lenght of Moving Average Vector /* Trusted AccZ Velocity Vector Magnetron1 /* This option should be uncommented if ACC Z is accurate enough when motors are running*/ #define TRUSTED_ACCZ_VEL
the line //#define TRUSTED_ACCZ is indipendent from my routines... I suggest you to leave it activate (without //)
I have a question regarding the Lipo-Alarm built in the software This is the code
/* for V BAT monitoring after the resistor divisor we should get [0V;5V]->[0;1023] on analog V_BATPIN with R1=33k and R2=51k vbat = [0;1023]*16/VBATSCALE */ #define VBAT // comment this line to suppress the vbat code #define VBATSCALE 131 // change this value if readed Battery voltage is different than real voltage #define VBATLEVEL1_3S 107 // 10,7V #define VBATLEVEL2_3S 103 // 10,3V #define VBATLEVEL3_3S 99 // 9.9V #define NO_VBAT 16 // Avoid beeping without any battery
means, the buzzer should slowly beep at 10,7 V , shouldn´t it ? But when I connect a full 12.4 V Lipo battery, the Buzzer beeps .... What figures must I change to avoid this ?
I have a question regarding the Lipo-Alarm built in the software This is the code
/* for V BAT monitoring after the resistor divisor we should get [0V;5V]->[0;1023] on analog V_BATPIN with R1=33k and R2=51k vbat = [0;1023]*16/VBATSCALE */ #define VBAT // comment this line to suppress the vbat code #define VBATSCALE 131 // change this value if readed Battery voltage is different than real voltage #define VBATLEVEL1_3S 107 // 10,7V #define VBATLEVEL2_3S 103 // 10,3V #define VBATLEVEL3_3S 99 // 9.9V #define NO_VBAT 16 // Avoid beeping without any battery
means, the buzzer should slowly beep at 10,7 V , shouldn´t it ? But when I connect a full 12.4 V Lipo battery, the Buzzer beeps .... What figures must I change to avoid this ?
Karsten
it's not a mw 2.0 error ... may be you do not configure right the vbatscale value I use 121 ...or you have swapped you resistor... check your lipo battery voltage (ex :12v6) check you midle point voltage betwen the 33k & 51k (ex:3v85)
some maths :
3.85 * [(1024/5)] = 3.85 * [204.8] = 788.48
788.48*16 = 12615.68 12615/126 =100 (126 is your 12.6v in mwc ) 100 is your vbatscale simple non ?
there seems to be a problem with hex x config in fw2.0
today i tried the actual fw 2.0. it flew ok but sometimes in left roll there was something wrong. it seemed that the left motor, connected to A0, reacts wrong. in a left roll the motor should decraese rpm but instead the rpm increased for some seconds and fighted against the other motors on the left. this happened not everytime i made a left roll. 3 times in the flight of maybe 4min. doesnt happen in the other directions.
fc. mwc board with pro mini and freeimu v0.4.3 A0 and A1 for left and right motor. ppm sum rx.
today I've play with my little quad I 've noticed a strange bug, I'was flying with a level pid "D" term less then 100,@ 90 exactly, the copter level smoother but after a moment the copter fall down.... may this help in debugging the "buggy" 2.0.
fr3d wrote:today I've play with my little quad I 've noticed a strange bug, I'was flying with a level pid "D" term less then 100,@ 90 exactly, the copter level smoother but after a moment the copter fall down.... may this help in debugging the "buggy" 2.0.
please be more accurate: "after a moment the copter fall down"
warthox wrote:there seems to be a problem with hex x config in fw2.0
today i tried the actual fw 2.0. it flew ok but sometimes in left roll there was something wrong. it seemed that the left motor, connected to A0, reacts wrong. in a left roll the motor should decraese rpm but instead the rpm increased for some seconds and fighted against the other motors on the left. this happened not everytime i made a left roll. 3 times in the flight of maybe 4min. doesnt happen in the other directions.
fc. mwc board with pro mini and freeimu v0.4.3 A0 and A1 for left and right motor. ppm sum rx.
Hi Markus, There is apparently a bug about HEX configs (and probably octo) on a promini with 2.0. I will try to reproduce it.