2.4 is finally here :)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
2.4 is finally here :)
http://code.google.com/p/multiwii/
After a very very long time, this version is finally released
A big thank for all contributions
main changes 2.3 -> 2.4
GPS
The main change in this version is for sure the code brought by EOSBandi regarding navigation (supported long time as a standolone MultiWii 2.3navi B7) .
Thanks to this major contribution, MultiWii can now navigate trought multiple WPs in an autonomous way.
The documentation about all define option can be found in this post:
viewtopic.php?viewtopic.php?f=8&t=3989
For the moment, only some GUIs can support this code to program a mission:
- WinGui from EOSBandi (http://eosbandi.com/downloads )
- EZ-GUI from Ezio (in google play apps https://play.google.com/store/apps/deta ... o.multiwii)
- mwp mission planner from stronnag (https://github.com/stronnag/mwptools)
tmp note for WinGui:
in order to work with current dev WinGUI, the version number should be switched back to 230.
otherwise an error message will occur.
in MultiWii.h , line: #define VERSION 230
will be soon supported with a new WinGui release
No support in java GUI MultiWiiConf.
Do not forget to activate #define USE_MSP_WP to be able to use waypoints.
The overall code without GPS is much shorter. However due to the change on GPS code, it is no more compatible with a 32u4 proc.
The GPS code without nav might still work on 328p proc.
A mega proc is mandatory to benefit from all the GPS functionalities.
internal code modification:
- dissociate frame parsing & frame computation
- I2C GPS is no more used as an extension with nav computation. It is now supported as a simple GPS device, and all computations stay in the FC, exactly like Serial GPS device.
- GPS Serial frame parsing is now part of generic Serial decoding code
- UBLOX GPS frame parsing improvement
IMU computation
- mostly optimization on computation time not visible for end users: less float and more 16bit integer where it's possible / some specific avr asm multiplication.
- better accuracy InvSqrt
- heading is computed even with no mag
- hungry tasks has been reduced or divided in order to minimize the jitter of loop time.
With this improvement, a constant loop time is set a little bit higher than the average and default to 2.8ms.
ACC
- Nunchuk is no more suported
Baro MS561101
- a little bit paradoxal regarding other portion of code approach in multiwii, but float computation tooked from APM appears to be shorter and faster with a minimal approximation.
- computation time smoothed thanks to a task split
- #define ALTITUDE_RESET_ON_ARM option is added
note the baro is still always reset when doing a gyro calibration
I2C
- no more speed change on the fly: all sensors are default to 400kHz.
- The only exception is when a legacy WMP is still used with a 100kHz speed. So no need to bother any longer about this speed if you don't own a genuine WMP.
- In case of I2C errors at the init stage, initialization occurs up to 5 times. This should prevent some remaining I2C errors.
Brushed motor option
- brushed motors option on 32u4 proc at 8/16/32 kHz
- brushed motors option on 328p proc at 1/4/32 kHz
viewtopic.php?viewtopic.php?f=8&t=3635&p=36883#p36877
RX receiver
- SUMD RX type introduction
- SBUS improvement / SBUS signal scaling to match other receiver range
- code factorization for all Serial type RX (Spektrum/SUMD/SBUS)
- adjustable averaging sample (AVERAGING_ARRAY_LENGTH) for non Serial RX. For Serial RX, the averaging code is removed because the signal is already natively digital.
- Serial RX should now be usable with no glitch during LCD conf
- RSSI injection on a rc channel
MSP
- new MSP message for ACC TRIM (not used in java MultiWiiConf)
- new MSP message for cells voltage
- new MSP messages for GPS navigation
- remove MSP ack for MSP_SET_RAW_RC, and only for this message
Sonar
- fix Devantech SRFxx code that was broken some time ago. But still no code integrated for alt lock using sonar.
Heli
- experimental : heli yaw precomp dependant on collective pitch
- experimental : better tail lock tacking intoo account collective pitch
Voltage
- compute watts
- experimental : individual cells voltage monitoring (alarm portion undone yet)
LCD
- LCD.lcd03 over serial support added
reference version to compile sketch
- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box
After a very very long time, this version is finally released
A big thank for all contributions
main changes 2.3 -> 2.4
GPS
The main change in this version is for sure the code brought by EOSBandi regarding navigation (supported long time as a standolone MultiWii 2.3navi B7) .
Thanks to this major contribution, MultiWii can now navigate trought multiple WPs in an autonomous way.
The documentation about all define option can be found in this post:
viewtopic.php?viewtopic.php?f=8&t=3989
For the moment, only some GUIs can support this code to program a mission:
- WinGui from EOSBandi (http://eosbandi.com/downloads )
- EZ-GUI from Ezio (in google play apps https://play.google.com/store/apps/deta ... o.multiwii)
- mwp mission planner from stronnag (https://github.com/stronnag/mwptools)
tmp note for WinGui:
in order to work with current dev WinGUI, the version number should be switched back to 230.
otherwise an error message will occur.
in MultiWii.h , line: #define VERSION 230
will be soon supported with a new WinGui release
No support in java GUI MultiWiiConf.
Do not forget to activate #define USE_MSP_WP to be able to use waypoints.
The overall code without GPS is much shorter. However due to the change on GPS code, it is no more compatible with a 32u4 proc.
The GPS code without nav might still work on 328p proc.
A mega proc is mandatory to benefit from all the GPS functionalities.
internal code modification:
- dissociate frame parsing & frame computation
- I2C GPS is no more used as an extension with nav computation. It is now supported as a simple GPS device, and all computations stay in the FC, exactly like Serial GPS device.
- GPS Serial frame parsing is now part of generic Serial decoding code
- UBLOX GPS frame parsing improvement
IMU computation
- mostly optimization on computation time not visible for end users: less float and more 16bit integer where it's possible / some specific avr asm multiplication.
- better accuracy InvSqrt
- heading is computed even with no mag
- hungry tasks has been reduced or divided in order to minimize the jitter of loop time.
With this improvement, a constant loop time is set a little bit higher than the average and default to 2.8ms.
ACC
- Nunchuk is no more suported
Baro MS561101
- a little bit paradoxal regarding other portion of code approach in multiwii, but float computation tooked from APM appears to be shorter and faster with a minimal approximation.
- computation time smoothed thanks to a task split
- #define ALTITUDE_RESET_ON_ARM option is added
note the baro is still always reset when doing a gyro calibration
I2C
- no more speed change on the fly: all sensors are default to 400kHz.
- The only exception is when a legacy WMP is still used with a 100kHz speed. So no need to bother any longer about this speed if you don't own a genuine WMP.
- In case of I2C errors at the init stage, initialization occurs up to 5 times. This should prevent some remaining I2C errors.
Brushed motor option
- brushed motors option on 32u4 proc at 8/16/32 kHz
- brushed motors option on 328p proc at 1/4/32 kHz
viewtopic.php?viewtopic.php?f=8&t=3635&p=36883#p36877
RX receiver
- SUMD RX type introduction
- SBUS improvement / SBUS signal scaling to match other receiver range
- code factorization for all Serial type RX (Spektrum/SUMD/SBUS)
- adjustable averaging sample (AVERAGING_ARRAY_LENGTH) for non Serial RX. For Serial RX, the averaging code is removed because the signal is already natively digital.
- Serial RX should now be usable with no glitch during LCD conf
- RSSI injection on a rc channel
MSP
- new MSP message for ACC TRIM (not used in java MultiWiiConf)
- new MSP message for cells voltage
- new MSP messages for GPS navigation
- remove MSP ack for MSP_SET_RAW_RC, and only for this message
Sonar
- fix Devantech SRFxx code that was broken some time ago. But still no code integrated for alt lock using sonar.
Heli
- experimental : heli yaw precomp dependant on collective pitch
- experimental : better tail lock tacking intoo account collective pitch
Voltage
- compute watts
- experimental : individual cells voltage monitoring (alarm portion undone yet)
LCD
- LCD.lcd03 over serial support added
reference version to compile sketch
- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box
Re: 2.4 is finally here :)
thanks for your continued work all !
Re: 2.4 is finally here :)
+1
Many thanks!
An epic journey, to be sure
Many thanks!
An epic journey, to be sure
Re: 2.4 is finally here :)
Fantastic!
Thanks to all involved in making this release possible
Now we have a good base to add and test new features...
Thanks to all involved in making this release possible
Now we have a good base to add and test new features...
Re: 2.4 is finally here :)
Congratulations.
Flew it yesterday. Performed as expected.
Flew it yesterday. Performed as expected.
Re: 2.4 is finally here :)
@stonemag,
Can you provide compiled Gui's for non developers?
Not everyone have a compiler installed or the knowledge howto..
Win,Mac & Linux for most users.
Can you provide compiled Gui's for non developers?
Not everyone have a compiler installed or the knowledge howto..
Win,Mac & Linux for most users.
-
- Posts: 4
- Joined: Sun Jan 11, 2015 2:15 pm
Re: 2.4 is finally here :)
It's like you read my mind and added precisely the features I wanted! I love the RSSI possibility.
Re: 2.4 is finally here :)
Hi all. Will this work with a crius aiopro v2 board. Many thanks.
Re: 2.4 is finally here :)
Alexinparis wrote:reference version to compile sketch
- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box
Is the Mac version of Arduino 1.6.1 excluded because it's broken? I upgraded to 1.6.1 and had to go back to 1.6.0 because 1.6.1 was spewing error messages when attempting to build from my svn sandbox. I haven't updated my sandbox with 2.4 final yet.
Re: 2.4 is finally here :)
willow609 wrote:Hi all. Will this work with a crius aiopro v2 board. Many thanks.
It will work great with this board!
Re: 2.4 is finally here :)
Excellent that's great news cheers.
-
- Posts: 3
- Joined: Sun Nov 02, 2014 2:32 pm
Re: 2.4 is finally here :)
great news, thanks guys
-
- Posts: 3
- Joined: Sun Nov 02, 2014 2:32 pm
Re: 2.4 is finally here :)
Are the stored parameters compatible with 2.3 or do I need to erase the EPROM space?
Re: 2.4 is finally here :)
TheBum wrote:Alexinparis wrote:reference version to compile sketch
- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box
Is the Mac version of Arduino 1.6.1 excluded because it's broken? I upgraded to 1.6.1 and had to go back to 1.6.0 because 1.6.1 was spewing error messages when attempting to build from my svn sandbox. I haven't updated my sandbox with 2.4 final yet.
Nevermind. I wrongly assumed that my board and serial port settings would be retained with the Arduino update. I did notice that the compilation with 1.6.1 is considerably smaller than with 1.6.0.
Re: 2.4 is finally here :)
zed_thirteen wrote:Are the stored parameters compatible with 2.3 or do I need to erase the EPROM space?
for almost all configs you want to erase first.
-
- Posts: 46
- Joined: Mon Oct 20, 2014 11:29 pm
Re: 2.4 is finally here :)
Hi all,
thank you for the great work! --
By the way, where should any bug reports for 2.4 go?
Incidentally, I have a bug report . Inflight calibration with the CALIB switch does not work as designed. The fix is as follows:
lines 1016..1018 of MultiWii.cpp currently look like this (in 2.4, but the bug is present in 2.3 as well):
and should look like that:
Without setting AccInflightCalibrationActive, the calibration will be continuously restarted while the CALIB switch is active. After landing and disarming, and releasing the switch, the actual measurement will take place and the accelerometer values (of the copter that is standing on the ground) will be taken as reference. This is definitely not what inflight calibration should do.
Cheers, Leco
thank you for the great work! --
By the way, where should any bug reports for 2.4 go?
Incidentally, I have a bug report . Inflight calibration with the CALIB switch does not work as designed. The fix is as follows:
lines 1016..1018 of MultiWii.cpp currently look like this (in 2.4, but the bug is present in 2.3 as well):
Code: Select all
if (!AccInflightCalibrationActive && !AccInflightCalibrationMeasurementDone){
InflightcalibratingA = 50;
}
and should look like that:
Code: Select all
if (!AccInflightCalibrationActive && !AccInflightCalibrationMeasurementDone){
InflightcalibratingA = 50; AccInflightCalibrationActive = 1;
}
Without setting AccInflightCalibrationActive, the calibration will be continuously restarted while the CALIB switch is active. After landing and disarming, and releasing the switch, the actual measurement will take place and the accelerometer values (of the copter that is standing on the ground) will be taken as reference. This is definitely not what inflight calibration should do.
Cheers, Leco
Re: 2.4 is finally here :)
Well, I've done 5 navigation flights with the new version in the last two days. All seems to be working.
Side note:
However I've picked a bad time to do these tests as on every flight something would go haywire. Right now we have very strong geomagnetic interference and heavy solar activity. I usually get 10 sat's locked but sometimes the number of sat's came down to 5 during flight which made navigation go crazy.
As I write this we will have a solar eclipse in Europe in an hour or so. Maybe the phenomena is causing the erratic behavior during the flights
Side note:
However I've picked a bad time to do these tests as on every flight something would go haywire. Right now we have very strong geomagnetic interference and heavy solar activity. I usually get 10 sat's locked but sometimes the number of sat's came down to 5 during flight which made navigation go crazy.
As I write this we will have a solar eclipse in Europe in an hour or so. Maybe the phenomena is causing the erratic behavior during the flights
Re: 2.4 is finally here :)
I know, the 2.4pre discussion has been closed and the 2.4 has been released.
However, I found an issue with the following line of code just today:
So the amperage resolution has been reduced by the factor 100 and the range has been extended by the same factor.
That means for my small copter a very poor accuracy in particular at low load.
The variables will overflow at 6500A - that's good news for big copters!
But, is this really what we want? Is there really someone requiring 6500A?
I thing a good compromise would be the following code, which should be acceptable for smaller and bigger copters:
However, I found an issue with the following line of code just today:
Code: Select all
analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA]
So the amperage resolution has been reduced by the factor 100 and the range has been extended by the same factor.
That means for my small copter a very poor accuracy in particular at low load.
The variables will overflow at 6500A - that's good news for big copters!
But, is this really what we want? Is there really someone requiring 6500A?
I thing a good compromise would be the following code, which should be acceptable for smaller and bigger copters:
Code: Select all
analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 10; // [10mA]
Re: 2.4 is finally here :)
Do you really see accurate measurements with 10mA steps from your sensor all the way through the adc?
Me I feel lucky if the value is accurate at the 1A digit.
Which sensor and RC.filter do you use please?
Me I feel lucky if the value is accurate at the 1A digit.
Which sensor and RC.filter do you use please?
Re: 2.4 is finally here :)
Hi Hamburger,
With a PINT2mA of roughly 100 you will always have a difference of 100=0.1A even when filtering.
I got a PINT2mA of 74 resulting to a 0.444 A or 0.518 A when armed. The display flips between both values.
When dividing by 100 - as done in MW 2.4 - the result is: The display swaps between the values 0.400 A and 0.500 A. So what is the benefit of doing so?
My proposal as a compromise was to chose a basis of 10mA (instead of 1mA in MW 2.3 or 100mA in MW 2.4). That would allow a better accuracy and a good range up to 650A. The values will flip (between 0.44 A and 0.51 A), but as I have explained they will do in any case.
Of course, I don't.Hamburger wrote:Do you really see accurate measurements with 10mA steps from your sensor all the way through the adc?
With a PINT2mA of roughly 100 you will always have a difference of 100=0.1A even when filtering.
I got a PINT2mA of 74 resulting to a 0.444 A or 0.518 A when armed. The display flips between both values.
When dividing by 100 - as done in MW 2.4 - the result is: The display swaps between the values 0.400 A and 0.500 A. So what is the benefit of doing so?
My proposal as a compromise was to chose a basis of 10mA (instead of 1mA in MW 2.3 or 100mA in MW 2.4). That would allow a better accuracy and a good range up to 650A. The values will flip (between 0.44 A and 0.51 A), but as I have explained they will do in any case.
Re: 2.4 is finally here :)
with your current sensor and a given current, how stable is the value you see for analogRead()? How many bits is noise?
I am not convinced it is a good idea to display digits which carry useless random values. I left the first decimal only to show trend and existing fluctuation.
For the pure information I would only display amps as integer value without any decimals.
I welcome your giving this some thought. As far as I can tell without looking at the code, changes may impact the gui (over msp) and the lcd:telemetry stuff.
I am not convinced it is a good idea to display digits which carry useless random values. I left the first decimal only to show trend and existing fluctuation.
For the pure information I would only display amps as integer value without any decimals.
I welcome your giving this some thought. As far as I can tell without looking at the code, changes may impact the gui (over msp) and the lcd:telemetry stuff.
Re: 2.4 is finally here :)
Hi Hamburger,
Thank you for the elaboration. I share your point that it is actually not worth to undertake the effort of changing the protocol for some more flickering decimals.
So, I can live with the current resolution of 100mA, since the more important variable pMeter[] has not been changed compared to MW 2.3.
I just was curious about the reasons for the change from mA to 100mA, which took place in MW 2.4.
My only plee for the current implementation would be to add a rounding like
Thank you for the elaboration. I share your point that it is actually not worth to undertake the effort of changing the protocol for some more flickering decimals.
So, I can live with the current resolution of 100mA, since the more important variable pMeter[] has not been changed compared to MW 2.3.
I just was curious about the reasons for the change from mA to 100mA, which took place in MW 2.4.
My only plee for the current implementation would be to add a rounding like
Code: Select all
analog.amperage = (((uint32_t)powerValue * conf.pint2ma) + 50) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA]
Re: 2.4 is finally here :)
I'll add my $0.02 to the amperage discussion. I chose to go with a 50A Hall effect sensor for my mini quad and the resolution works out to 61.25mA (80mV/A). I don't think you'll get much lower than that, and higher rated sensors will be even worse. Therefore, 100mA resolution on the display should be more than sufficient.
Re: 2.4 is finally here :)
There's a documentation typo in 2.4 that was there in 2.3 and, being the anal-retentive person I am, it's driving me nuts.
In MultiWii.cpp, the comment at the end of the following line is wrong:
It should be 100 mA * msec based on the equation. The unscaled units are mA * µsec. To get 10 mA * msec, you'd have to divide by 10 and 1000, i.e. 10000.
In MultiWii.cpp, the comment at the end of the following line is wrong:
Code: Select all
pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/100000; // [10 mA * msec]
It should be 100 mA * msec based on the equation. The unscaled units are mA * µsec. To get 10 mA * msec, you'd have to divide by 10 and 1000, i.e. 10000.
Re: 2.4 is finally here :)
TheBum wrote:I'll add my $0.02 to the amperage discussion. I chose to go with a 50A Hall effect sensor for my mini quad and the resolution works out to 61.25mA (80mV/A). I don't think you'll get much lower than that, and higher rated sensors will be even worse. Therefore, 100mA resolution on the display should be more than sufficient.
thanks for the input. What is your experience with the accuracy of analogRead() in MWii on avr boards?
Re: 2.4 is finally here :)
TheBum wrote:There's a documentation typo in 2.4 that was there in 2.3 and, being the anal-retentive person I am, it's driving me nuts.
In MultiWii.cpp, the comment at the end of the following line is wrong:Code: Select all
pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/100000; // [10 mA * msec]
It should be 100 mA * msec based on the equation. The unscaled units are mA * µsec. To get 10 mA * msec, you'd have to divide by 10 and 1000, i.e. 10000.
I do not think it would justify a recall of v2.4, but I will take a closer look for v2.5. Thanks.
Re: 2.4 is finally here :)
I am getting longitude spikes with 8-10 satellites....I have a multiwii pro running 2.4 and navi b7...any thoughts? Switched from 2.3 with b5 and i did clear eeprom when updating to 2.4. Little bit of a newbie here. Thanks.
Steve
Steve
Re: 2.4 is finally here :)
Hamburger wrote:I do not think it would justify a recall of v2.4, but I will take a closer look for v2.5. Thanks.
I don't either, but it needed to be pointed out IMO.
- jaysonragasa
- Posts: 53
- Joined: Wed Jan 28, 2015 6:40 am
- Location: Philippines
- Contact:
Re: 2.4 is finally here :)
I made a small changes in AlexK PID_CONTRORLLER based on cleanflight's "ReWrite"
Code: Select all
#define GYRO_I_MAX 256
#define ACC_I_MAX 256
prop = min(max(abs(rcCommand[PITCH]), abs(rcCommand[ROLL])), 500); // range [0;500]
//----------PID controller----------
for (axis = 0; axis < 3; axis++) {
//-----Get the desired angle rate depending on flight mode
//if ((f.ANGLE_MODE || f.HORIZON_MODE) && axis < 2) { // MODE relying on ACC
// // calculate error and limit the angle to 50 degrees max inclination
// // errorAngle = constrain((rcCommand[axis] << 1) + GPS_angle[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
//}
if (axis == 2) {//YAW is always gyro-controlled (MAG correction is applied to rcCommand)
AngleRateTmp = (((int32_t) (conf.yawRate + 27) * rcCommand[2]) >> 5);
}
else {
// calculate error and limit the angle to 50 degrees max inclination
#if GPS
//errorAngle = constrain((rcCommand[axis] << 1) + GPS_angle[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
errorAngle = constrain(2 * rcCommand[axis] + GPS_angle[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
#else
errorAngle = constrain(2 * rcCommand[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
#endif
if (!f.ANGLE_MODE) {//control is GYRO based (ACRO and HORIZON - direct sticks control is applied to rate PID
AngleRateTmp = ((int32_t) (conf.rollPitchRate + 27) * rcCommand[axis]) >> 4;
if (f.HORIZON_MODE) {
//mix up angle error to desired AngleRateTmp to add a little auto-level feel
AngleRateTmp += ((int32_t) errorAngle * conf.pid[PIDLEVEL].I8) >> 8;
}
}
else {//it's the ANGLE mode - control is angle based, so control loop is needed
AngleRateTmp = ((int32_t) errorAngle * conf.pid[PIDLEVEL].P8) >> 4;
}
}
//--------low-level gyro-based PID. ----------
//Used in stand-alone mode for ACRO, controlled by higher level regulators in other modes
//-----calculate scaled error.AngleRates
//multiplication of rcCommand corresponds to changing the sticks scaling here
RateError = AngleRateTmp - imu.gyroData[axis];
//-----calculate P component
PTerm = ((int32_t) RateError * conf.pid[axis].P8) >> 7;
//-----calculate I component
//there should be no division before accumulating the error to integrator, because the precision would be reduced.
//Precision is critical, as I prevents from long-time drift. Thus, 32 bits integrator is used.
//Time correction (to avoid different I scaling for different builds based on average cycle time)
//is normalized to cycle time = 2048.
errorGyroI[axis] += (((int32_t) RateError * cycleTime) >> 11) * conf.pid[axis].I8;
//limit maximum integrator value to prevent WindUp - accumulating extreme values when system is saturated.
//I coefficient (I8) moved before integration to make limiting independent from PID settings
errorGyroI[axis] = constrain(errorGyroI[axis], (int32_t) -GYRO_I_MAX << 13, (int32_t) +GYRO_I_MAX << 13);
ITerm = errorGyroI[axis] >> 13;
//-----calculate D-term
delta = RateError - lastError[axis]; // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
lastError[axis] = RateError;
//Correct difference by cycle time. Cycle time is jittery (can be different 2 times), so calculated difference
// would be scaled by different dt each time. Division by dT fixes that.
delta = ((int32_t) delta * ((uint16_t) 0xFFFF / (cycleTime >> 4))) >> 6;
//add moving average here to reduce noise
deltaSum = delta1[axis] + delta2[axis] + delta;
delta2[axis] = delta1[axis];
delta1[axis] = delta;
//DTerm = (deltaSum*conf.pid[axis].D8)>>8;
//Solve overflow in calculation above...
DTerm = ((int32_t) deltaSum * conf.pid[axis].D8) >> 8;
//-----calculate total PID output
axisPID[axis] = PTerm + ITerm + DTerm;
}
Re: 2.4 is finally here :)
jaysonragasa wrote:I made a small changes in AlexK PID_CONTRORLLER based on cleanflight's "ReWrite"
And what is the benefit of this exercise?
Re: 2.4 is finally here :)
Looks great. I compiled it - but have not flown it yet. I've implemented this on an airplane, the flight characteristics are very nice.
If I were to make a small donation, where should I send it? (knowing this is a loaded question). Not sure how this message board is funded - or who exactly is doing all the work these days?
EDIT:
Never mind, found the donation link (it was documented after all). Going directly to this forum bypasses the main 'home' screen with donation info. Thanks for the efforts!
If I were to make a small donation, where should I send it? (knowing this is a loaded question). Not sure how this message board is funded - or who exactly is doing all the work these days?
EDIT:
Never mind, found the donation link (it was documented after all). Going directly to this forum bypasses the main 'home' screen with donation info. Thanks for the efforts!
Re: 2.4 is finally here :)
Good work on 2.4
What does this mean? We now have some heading hold using just a gyro and accel as an option? If so how do we activate this feature or is it on all the time?
Alexinparis wrote:- heading is computed even with no mag
What does this mean? We now have some heading hold using just a gyro and accel as an option? If so how do we activate this feature or is it on all the time?
Re: 2.4 is finally here :)
RCvertt wrote:Good work on 2.4Alexinparis wrote:- heading is computed even with no mag
What does this mean? We now have some heading hold using just a gyro and accel as an option? If so how do we activate this feature or is it on all the time?
The only method I can think of without a mag sensor is GPS, and then only when the model is moving.
Re: 2.4 is finally here :)
the ide does not compile if activate:
#define SERVO TILT
Shows the following error:
In file included from Output.cpp:3:0:
Output.cpp: In function 'void __vector_14()':
def.h:1431:38: error: 'PORTL' was not declared in this scope
#define SERVO_1_PIN_HIGH PORTL |= 1<<5;
^
def.h:683:24: note: in expansion of macro 'SERVO_1_PIN_HIGH'
#define SERVO_1_HIGH SERVO_1_PIN_HIGH
^
Output.cpp:908:7: note: in expansion of macro 'SERVO_1_HIGH'
SERVO_1_HIGH; // set servo 1's pin high
^
def.h:1432:38: error: 'PORTL' was not declared in this scope
#define SERVO_1_PIN_LOW PORTL &= ~(1<<5);
^
Output.cpp:897:7: note: in definition of macro 'SERVO_PULSE'
LAST_PIN_LOW; \
^
def.h:684:23: note: in expansion of macro 'SERVO_1_PIN_LOW'
#define SERVO_1_LOW SERVO_1_PIN_LOW
^
Output.cpp:915:50: note: in expansion of macro 'SERVO_1_LOW'
SERVO_PULSE(SERVO_2_HIGH,2,SERVO_2_ARR_POS,SERVO_1_LOW); // the same here
^
In file included from Output.cpp:3:0:
def.h:1435:38: error: 'PORTL' was not declared in this scope
#define SERVO_2_PIN_LOW PORTL &= ~(1<<4);
^
def.h:689:20: note: in expansion of macro 'SERVO_2_PIN_LOW'
#define LAST_LOW SERVO_2_PIN_LOW
^
Output.cpp:936:7: note: in expansion of macro 'LAST_LOW'
LAST_LOW;
^
Errore durante la compilazione
#define SERVO TILT
Shows the following error:
In file included from Output.cpp:3:0:
Output.cpp: In function 'void __vector_14()':
def.h:1431:38: error: 'PORTL' was not declared in this scope
#define SERVO_1_PIN_HIGH PORTL |= 1<<5;
^
def.h:683:24: note: in expansion of macro 'SERVO_1_PIN_HIGH'
#define SERVO_1_HIGH SERVO_1_PIN_HIGH
^
Output.cpp:908:7: note: in expansion of macro 'SERVO_1_HIGH'
SERVO_1_HIGH; // set servo 1's pin high
^
def.h:1432:38: error: 'PORTL' was not declared in this scope
#define SERVO_1_PIN_LOW PORTL &= ~(1<<5);
^
Output.cpp:897:7: note: in definition of macro 'SERVO_PULSE'
LAST_PIN_LOW; \
^
def.h:684:23: note: in expansion of macro 'SERVO_1_PIN_LOW'
#define SERVO_1_LOW SERVO_1_PIN_LOW
^
Output.cpp:915:50: note: in expansion of macro 'SERVO_1_LOW'
SERVO_PULSE(SERVO_2_HIGH,2,SERVO_2_ARR_POS,SERVO_1_LOW); // the same here
^
In file included from Output.cpp:3:0:
def.h:1435:38: error: 'PORTL' was not declared in this scope
#define SERVO_2_PIN_LOW PORTL &= ~(1<<4);
^
def.h:689:20: note: in expansion of macro 'SERVO_2_PIN_LOW'
#define LAST_LOW SERVO_2_PIN_LOW
^
Output.cpp:936:7: note: in expansion of macro 'LAST_LOW'
LAST_LOW;
^
Errore durante la compilazione
Re: 2.4 is finally here :)
Hi all,
i had some troubles the last few days with 2 multiwii pro boards with mtk gps.
It seems #init Mtkgps does not work in multiwii 2.4.
Until now i had no time to test the new release and give feedback. Sorry....
This is what happened:
I got a brandnew multiwii pro board from HK.
Of course i wanted to start with 2.4 rightaway.
As usual i uncomment all GPS settings that are needed:
#define FFIMUv2
#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS
The GPS module would not initialize... I tried my secound new board, same behaviour.
I redownloaded the multiwii sketch and reconfigured it a secound time to be sure i have messed nothing up.
I gave up on 2.4 and flashed 2.3.
Istant i got a working gps with the same configuration. So i commented //#define INIT_MTK_GPS in 2.4 and gave it another try.
Now i got instant satlock with 2.4, works as it should.
I will not find the bug in the code, if there is one.....you know my programming skills are like
but maybe someone other does.
Thank you!
Greetz Noc
edit: Sorry, did not see there already was an topic -> viewtopic.php?f=18&t=6317
i had some troubles the last few days with 2 multiwii pro boards with mtk gps.
It seems #init Mtkgps does not work in multiwii 2.4.
Until now i had no time to test the new release and give feedback. Sorry....
This is what happened:
I got a brandnew multiwii pro board from HK.
Of course i wanted to start with 2.4 rightaway.
As usual i uncomment all GPS settings that are needed:
#define FFIMUv2
#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS
The GPS module would not initialize... I tried my secound new board, same behaviour.
I redownloaded the multiwii sketch and reconfigured it a secound time to be sure i have messed nothing up.
I gave up on 2.4 and flashed 2.3.
Istant i got a working gps with the same configuration. So i commented //#define INIT_MTK_GPS in 2.4 and gave it another try.
Now i got instant satlock with 2.4, works as it should.
I will not find the bug in the code, if there is one.....you know my programming skills are like
but maybe someone other does.
Thank you!
Greetz Noc
edit: Sorry, did not see there already was an topic -> viewtopic.php?f=18&t=6317
Re: 2.4 is finally here :)
Sure about that? I've never heard of heading hold with GPS only. GPS is rather inaccurate so I can't imagine that being the case?TheBum wrote:The only method I can think of without a mag sensor is GPS, and then only when the model is moving.
I've heard of gyros only heading hold. That's how all helicopter heading hold was done before and many still do it that way. Some integrate the accel now for a more accurate heading hold when a mag isn't used.
Re: 2.4 is finally here :)
ttcorse wrote:the ide does not compile if activate:
#define SERVO TILT
Errore durante la compilazione
Please zip your config.h and post that here. Which version of IDE do you use?
Re: 2.4 is finally here :)
my ide is arduino 1.6.1
Thanks
-
- Posts: 9
- Joined: Mon Jul 28, 2014 10:28 am
Re: 2.4 is finally here :)
Hi All
sorry. I want to know if i want to use ublox gps with srf04 sonar Do I still have to use MWC I2C-GPS NAV module board with I2C_GPS_NAV code on multiwii 2.4??????
sorry. I want to know if i want to use ublox gps with srf04 sonar Do I still have to use MWC I2C-GPS NAV module board with I2C_GPS_NAV code on multiwii 2.4??????
Re: 2.4 is finally here :)
No, you can't and you have to use the additional i2c_gps_nav module.m.homayoun wrote:I want to know if i want to use ublox gps with srf04 sonar Do I still have to use MWC I2C-GPS NAV module board with I2C_GPS_NAV code on multiwii 2.4
Under http://www.multiwii.com/forum/viewtopic.php?f=8&t=6282 it is being discussed how to integrate the SRF04 into multiwii 2.4. But, there seem to be many questions and issues. The best thingwould be to use an i2c based sonar module like the SRF08, which has already been integrated.
Re: 2.4 is finally here :)
Hi everybody,
I stuck in the same way with my MTK GPS.
I've just bought a HK multiwii pro, and updated it to 2.4,
I tried these settings:
#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS
tried to change baud rate, but nothing appened in the GUI.
can you please help me to find a way to make it work ?
thanks by advance.
Fred
I stuck in the same way with my MTK GPS.
I've just bought a HK multiwii pro, and updated it to 2.4,
I tried these settings:
#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS
tried to change baud rate, but nothing appened in the GUI.
can you please help me to find a way to make it work ?
thanks by advance.
Fred
Re: 2.4 is finally here :)
Just a curious observation since I've updated my Flip1.5 (RTFQuads) board installed on a tricopter.
The first thing I noticed when I plug the board into the computer and connected with MultiWiiConf is that the graphic representation for the tricopter shows it rotating clockwise until I recalibrate the gyros. Interestingly, when I but a battery in an fly it, it does the same clockwise yaw in rate mode, but I can compensate with steady stick yaw input (or trim probably, but I didn't try using TX trim). This is after powering it up on a steady/flat platform and waiting a good amount of time after the LED's indicate ready state before arming. If I land, and use stick commands to recalibrate the gyros, it removes the yaw drift when I take off again.
I'm using the released version of MW2.4 / MWC 2.4. I erased the eeprom before flashing the new version, and have in fact done so twice just for good measure.
I'm assuming this is related to the new implementation of the compass heading using the gyro/accelerometers INS input without a need for a magnetometer, but I'm flying in rate mode without any heading hold feature even enabled.
Has anyone else seen this?
The first thing I noticed when I plug the board into the computer and connected with MultiWiiConf is that the graphic representation for the tricopter shows it rotating clockwise until I recalibrate the gyros. Interestingly, when I but a battery in an fly it, it does the same clockwise yaw in rate mode, but I can compensate with steady stick yaw input (or trim probably, but I didn't try using TX trim). This is after powering it up on a steady/flat platform and waiting a good amount of time after the LED's indicate ready state before arming. If I land, and use stick commands to recalibrate the gyros, it removes the yaw drift when I take off again.
I'm using the released version of MW2.4 / MWC 2.4. I erased the eeprom before flashing the new version, and have in fact done so twice just for good measure.
I'm assuming this is related to the new implementation of the compass heading using the gyro/accelerometers INS input without a need for a magnetometer, but I'm flying in rate mode without any heading hold feature even enabled.
Has anyone else seen this?
Re: 2.4 is finally here :)
@Fred
Did you try my solution a few posts above?
Greetz Noc
Did you try my solution a few posts above?
Greetz Noc
Re: 2.4 is finally here :)
@Alex: r1771 "replace some pinMode() by direct DDR port manipulation"
What is the advantage?
What is the advantage?
-
- Posts: 234
- Joined: Wed Dec 24, 2014 1:20 am
- Location: ......
Re: 2.4 is finally here :)
Fredasss wrote:Hi everybody,
I stuck in the same way with my MTK GPS.
I've just bought a HK multiwii pro, and updated it to 2.4,
I tried these settings:
#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS
tried to change baud rate, but nothing appened in the GUI.
can you please help me to find a way to make it work ?
thanks by advance.
Fred
Change your serial baud to 115200. Leave GPS baud at 57600. Only use these settings on First firmware upload:
#define SERIAL2_COM_SPEED 57600
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define INIT_MTK_GPS
Use these settings on SECOND upload:
#define SERIAL2_COM_SPEED 57600
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
On the second upload, re-comment the #define INIT_MTK_GPS statement so it looks like this again.
//#define INIT_MTK_GPS
The statement #define INIT_MTK_GPS
is what initializes the module. After initialization you must re comment this on second upload by adding // in front.
Make sure that your TX lead on the module goes to the RX pin on the FC. Make sure that RX lad on module goes to TX pin on FC. The following step is IMPORTANT! Make sure in your Arduino sketch in the GPS section that the following:
#define USE_MSP_WP
is not commented (commenting is adding the two slashes.)
Make sure that your failsafe is enabled before using GPS (or on any other flight for that matter.)
Re: 2.4 is finally here :)
Leo wrote:@Alex: r1771 "replace some pinMode() by direct DDR port manipulation"
What is the advantage?
+1
If there aren't advantages I preferred as it was before because more easy to read/understand.
My 2 cents
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: 2.4 is finally here :)
Leo wrote:@Alex: r1771 "replace some pinMode() by direct DDR port manipulation"
What is the advantage?
Hi,
This is the same principle as writing for instance on a mega: PORTF|= 1<<7; instead of digitalWrite(A0, HIGH)
For digitalWrite, the advantage is obvious: much faster.
For pinMode, as it is required only once, the speed is not so important.
But removing every call of pinMode (which is still not the case, and still to do in Output.cpp) could free something like 350 bytes.
Arduino pinMode code for reference:
Code: Select all
void pinMode(uint8_t pin, uint8_t mode)
{
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
volatile uint8_t *reg, *out;
if (port == NOT_A_PIN) return;
// JWS: can I let the optimizer do this?
reg = portModeRegister(port);
out = portOutputRegister(port);
if (mode == INPUT) {
uint8_t oldSREG = SREG;
cli();
*reg &= ~bit;
*out &= ~bit;
SREG = oldSREG;
} else if (mode == INPUT_PULLUP) {
uint8_t oldSREG = SREG;
cli();
*reg &= ~bit;
*out |= bit;
SREG = oldSREG;
} else {
uint8_t oldSREG = SREG;
cli();
*reg |= bit;
SREG = oldSREG;
}
}
Re: 2.4 is finally here :) Buzzer Question
Multiwii 2.4 I've a onboard LiPo LED and I installed a buzzer.
It buzzes on certain actions from the TX.
My question why doesn't it buzz on ARMED/DIS_ARMED? Do I just have to rely on seeing the LED?
Carl334
Posts: 9
Joined: Mon Jan 12, 2015 10:01 am
It buzzes on certain actions from the TX.
My question why doesn't it buzz on ARMED/DIS_ARMED? Do I just have to rely on seeing the LED?
Carl334
Posts: 9
Joined: Mon Jan 12, 2015 10:01 am
Re: 2.4 is finally here :)
I have just updated a MultiWii Pro to Ver. 2.4 and am having a problem with connecting to WinGUI latest version.
First problem was a software mis-match as it was expecting Ver 230, but is seeing Ver.240. That was an easy fix in MultiWii.h as usual.
On loading the sketch to the board again, on connecting, it throws up the Navi Version error: "GUI Version: v7. Controller version: v5. Navigation Functions Disabled."
Clicking OK, the board connects and all is working - GPS working fine with sat. locks, (8 indoors with an MTK!!!) but obviously no mission capability and mission buttons are disabled, as would be expected
If I change the MultiWii.h to: #define NAVI_VERSION 7 //This allow sync with GUI, on attempting to connect to the WinGUI I get a program error "Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue." etc.
The error message begins with "Value of '15' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'. Parameter name: Value." indication an out of range error relating to the .net framework I assume?
Has anyone else come across this and found a solution at all?
Thanks in advance for any help.
First problem was a software mis-match as it was expecting Ver 230, but is seeing Ver.240. That was an easy fix in MultiWii.h as usual.
On loading the sketch to the board again, on connecting, it throws up the Navi Version error: "GUI Version: v7. Controller version: v5. Navigation Functions Disabled."
Clicking OK, the board connects and all is working - GPS working fine with sat. locks, (8 indoors with an MTK!!!) but obviously no mission capability and mission buttons are disabled, as would be expected
If I change the MultiWii.h to: #define NAVI_VERSION 7 //This allow sync with GUI, on attempting to connect to the WinGUI I get a program error "Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue." etc.
The error message begins with "Value of '15' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'. Parameter name: Value." indication an out of range error relating to the .net framework I assume?
Has anyone else come across this and found a solution at all?
Thanks in advance for any help.