Page 2 of 2

Re: Release v2.3 is coming soon... prepare

Posted: Wed Oct 02, 2013 10:46 pm
by rbirdie001
Alexinparis wrote:
rbirdie001 wrote:Hi,
today I tested r1573 in 328 (Crius SE) with I2C_GPS_NAV_v2_2 loaded in Arduino Promini and ALWAYS after powering ON I see three I2C errors in GUI. Then it works normally and number of errors remains on 3, but previously it wasn't like this. Probably just bad timing during bootup, but doesn't look nice because we, ordinary users, were taught that I2C errors are bad and shouldn't be there ;) .

I see also the 3 errors when I use a I2C_GPS_NAV. I suppose it will be corrected with EOS GPS update.

Another strange thing is that when I change some values (like PID) over GUI and press "WRITE" button, FC reboots. It also started happenning after connecting I2C GPS.
Can someone verify this before 2.3 release?
Thanks!
Roman

I can't reproduce it.

Hi Alex,
I again tried to get rid of reboot after writing data to FC so I again cleared its EEPROM and reloaded r1573. I have Crius SE board with connected I2C GPS in Promini. Behavior is exactly the same - three I2C errors from the beginning and reboot when writing settings to EEPROM. See this video:
http://www.youtube.com/watch?v=5r_KaEdLsfI
Note, that after unwanted reboot I2C errors are not there anymore (it confirms reboot?).
I'm attaching my actual config.h, no other file was altered. You can try to reproduce the fault...
When I disconected I2C GPS and disabled it in config.h, writing to EEPROM worked perfectly without reboot, as it should.
Sorry, I'm used that what works for everyone, it usually doesn't work for me. At least I should be good as a beta tester ;)
Roman

Re: Release v2.3 is coming soon... prepare

Posted: Sun Oct 06, 2013 2:37 pm
by sismeiro
Hi to all,

Just giving my feedback regarding the pre v2.3. I tested it with my Xcopter that has a Crius SE FC and didn't found any problem. My rig is nothing fancy, just a X525 with ANGLE and MAG activated.

I still have to tune the PIDs since I felt the Xcopter too loose when flying with defaults. I used the LCD via Blueterm in Android to increase the roll and pitch P to 5.4 just to test. It flew better but now I think I need to change the PID for the LEVEL because it seems to take too long to return to horizontal. Any suggestions?

It's looking good to be released sometime soon. Excellent work from the developers and off course, Alex.

Regards,
Luis Sismeiro

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 07, 2013 3:53 pm
by Ringo42
I'm new to multiwii. My board has 2.2 on it. where do I get 2.3 when it comes out? Will it be posted here? I've got an issue where the rear left motor doesn't power up correctly and I'm hoping 2.3 will fix it.
Thanks

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 07, 2013 5:15 pm
by PatrikE

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 07, 2013 8:28 pm
by Hamburger
info on
- servos pins and setup
- private defaults
- new powermeter setup
updated in wiki and links put into config.h

Please read and enhance.

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 07, 2013 8:30 pm
by Hamburger
I seem to remember we moved some servo pins for some coptertypes. In case this would collide with former motor pins it could easily fry a servo fast. So a warning notice would be good. Anyone remember which coptertype(s) was affected beyond TRI on mega with hardware.pwm?

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 07, 2013 9:57 pm
by PatrikE
Plans, FlyingWing and BI Servos was also changed.

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 08, 2013 10:12 am
by city_kid
@Hamburger

Where is the "updated wiki" for v2.3....?

Many thanks!

city_kid

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 08, 2013 10:34 am
by Hamburger
from trunk/Readme.txt:

Documentation for releases should be in the official wiki at
http://www.multiwii.com/wiki

Dunno know how it was spelled in last release notes.
Have fun.

Re: Release v2.3 is coming soon... prepare

Posted: Sun Oct 13, 2013 5:09 pm
by obor
Hi,
One question: do you plan to integrate changing pids with POT value and Ziegler-Nichols algorythm as described here:
viewtopic.php?f=7&t=1701
?
Thanks

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 14, 2013 2:24 am
by teslahed
It would be great to have a potentiometer you could use to alter one or more PID values on the fly. I would start my PID tuning by linking it to P on pitch and roll and go from there. You'd need the multiwii software to output the PID setting in real time so that you could read it over bluetooth or whatever and note down the best value. Then after tuning you'd turn the potentiometer off and set the PID setting to the best value previously discovered using the GUI.

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 14, 2013 7:10 pm
by tovrin
if you have bluetooth, why not just use the android app and make changes via the app? thats hwo i do it, thoguh i dont recommend making changes in flight, as i heard it can bug out for a full second.

Posted: Mon Oct 14, 2013 7:41 pm
by BarneyG
Teslahed look at this thread ... viewtopic.php?t=1701

Also look at my thread in mruk about this feature ... I think I'll be adding it into my build at some point soon if you'd like a copy

Re: Release v2.3 is coming soon... prepare

Posted: Mon Oct 14, 2013 8:30 pm
by sismeiro
Hi,

Following the topic to say that I am prepared for 2.3 final. :)

I have being using the latest shared from SVN with my configurations like Crius SE, LCD config, LCD telemetry, etc. and all ok for my Xcopter. The test flights didn't show any problem and for me that was using 2.1 for a long time, it flies very well, only needed to increase the default P for roll and pitch.

Regards,
Luis Sismeiro

Re:

Posted: Mon Oct 14, 2013 10:23 pm
by teslahed
BarneyG wrote:Teslahed look at this thread ... viewtopic.php?t=1701

Also look at my thread in mruk about this feature ... I think I'll be adding it into my build at some point soon if you'd like a copy


Thanks Barney. If they are not adding this to the main 2.3 release then i would indeed appreciate a copy of your modified version. Especially if it's exactly the same as 2.3 except with that one mod - that would be really handy!

I have used the bluetooth aps to PID tune on the fly before, it works well. A potentiometer would give better results i think - easier and quicker to make small precise changes in real time.

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 15, 2013 12:40 pm
by iosonologio
What about MultiWii conf. The Mac version has some troubles with the bluetooth, it is extremely slow. I know nothing about processing, so it would be better if somebody else tackles the issue.

Second problem, i have noticed some issues in the baro signal on Multiwii conf:

Baro signal has some aliasing (i.e.: two successive points with the same value), that happens really often (every 3-5 points). Since the signal in Multiwii (when on cable) is updated at around 3Hz, i think there might be a bigger underlying problem. Please notice that only baro seems to have this issue, while gyro signals are smooth.
I will need to dig into this deeper, anybody else noticed this?

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 15, 2013 1:42 pm
by BarneyG
to be honest I've kinda given up on Baro on my Crius AIOP v2 board ... I got down to -12m (and still descending) the other night while my quad was sat on the floor for about 20 mins for some testing of the latest pre release version.

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 15, 2013 1:52 pm
by timecop
The baro / board probably heated up.

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 15, 2013 2:38 pm
by BarneyG
timecop wrote:The baro / board probably heated up.


Oh I don't disagree ... I removed the foam I had covering it and it gradually returned to a reasonably correct value but the point is if I don't cover it it is affected by prop wash & light and if I do cover it is affected by heat ... either way the data it provides isn't correct and my quad isn't going to be doing what I want of it :)

Edit ... Don't get me wrong not dissing MultiWii really it is the limitations of the hardware ... putting the Baro on a separate board that wasn't in the propwash would address a number of issues, same goes for the Compass too

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 15, 2013 2:38 pm
by Ringo42
I've got the readytoflyquads pro board and the baro on it is bad too. I've seen it as low as -20m with the motors never turning on, just as It was sitting there on the table.

Re: Release v2.3 is coming soon... prepare

Posted: Tue Oct 15, 2013 7:27 pm
by obor
BarneyG wrote:to be honest I've kinda given up on Baro on my Crius AIOP v2 board ... I got down to -12m (and still descending) the other night while my quad was sat on the floor for about 20 mins for some testing of the latest pre release version.

Same for me, I never got good results on altitude with my AIOP V2 also. Simply not usable.
Another thing also which did not worked well is angle or stable mode. The Copter always drift quickly on one side or the other. It does not hold any position at all. It made me feel just like the accelero are not acurate enough to keep a perfect zero level...

Re: Release v2.3 is coming soon... prepare

Posted: Wed Oct 16, 2013 10:53 am
by iosonologio
Those are board related problems (or warming up, or simply weather change on a 20 min timescale). My was an issue about software.
I repeat the question.

Baro signal has some aliasing (i.e.: two successive points with the same value), that happens really often (every 3-5 points). Since the signal in Multiwii (when on cable) is updated at around 3Hz, i think there might be a bigger underlying problem. Please notice that only baro seems to have this issue, while gyro signals are smooth.

Did anybody see the same?

Re: Release v2.3 is coming soon... prepare

Posted: Wed Oct 16, 2013 12:58 pm
by crashlander
Long standing feature in MWII is its I term zeroing function when TH is below some value.
That is necessary feature in multi-copter world but can be considered bug for FIXEDWINGS since pilots are gliding with zero TH all the time (often) and there this feature is actually a bug!
I prpose to enclose that part of code in #ifdefs for FIXEDWING (allready described in Airplane RTH thread viewtopic.php?f=7&t=2456&start=330#p42355).

Regards
Andrej

Re: Release v2.3 is coming soon... prepare -> parameters...

Posted: Thu Oct 17, 2013 12:57 pm
by mabaka
F_CPU and I2C_SPEED usage.

I2C_SPEED parameter usage.
It is defined in config.h; its default value is for slow I2C (100 KHz), and is rarely used.
On most TWBR (TWI Bit Rate Register) register writes appears explicitly 400000L (for 400 KHz).
So something like this would be more elegant:
#define I2C_SPEED_SLOW 100000L
#define I2C_SPEED_FAST 400000L
and use one or the other in TWBR writes.

F_CPU parameter usage.
If I am not wrong, this parameter comes from:
(board used).build.f_cpu=16000000L
on boards.txt file.
It seems to be used in TWBR writes and baudrate calculations, but not in pulse width calculations.

So I understand that F_CPU must be 16 MHz, and usage on 3.3V arduinos or using the internal 8 MHz chip clock would require a massive code change.
Please, correct me if I am wrong in these assumptions.

So suppose you want to try the internal 8 MHz chip clock such on a gimbal only Multiwii usage.
Would changing in output.cpp:
map(servo[i], 1020, 2000...
to
map(servo[i], 510, 1000...
be enough, or is there a less horrible way?

(BTW, explicit 1020 and 2000 is ugly).

Re: Release v2.3 is coming soon... prepare

Posted: Fri Oct 18, 2013 1:14 pm
by e_lm_70
crashlander wrote:Long standing feature in MWII is its I term zeroing function when TH is below some value.
That is necessary feature in multi-copter world but can be considered bug for FIXEDWINGS since pilots are gliding with zero TH all the time (often) and there this feature is actually a bug!
I prpose to enclose that part of code in #ifdefs for FIXEDWING (allready described in Airplane RTH thread viewtopic.php?f=7&t=2456&start=330#p42355).

Regards
Andrej


Good point.

On my hacked MultiWii 2.1 for airplane it is one of the hack that I did.

When the throttle is zero, actually I make the error for the I term softly declining (using some destructing filtering, average like I = (I*0.9)+Error) , while in the with throttle over zero I don't make any filtering.

For instance if I want to do hand launch of an airplane, after arming, I don't want it keep the control surfaces for force to go back to the position that was at arm time, still I want the error go away in few seconds, and still I want to have some I support when gliding at zero power.

These are easy hack that can be add on MultiWii in no time ... I guess being specific airplane mode, maybe in name of a clean code these little tuning has not been done on the main stream

Re: Release v2.3 is coming soon... prepare

Posted: Fri Oct 18, 2013 3:24 pm
by crashlander
e_lm_70 wrote:For instance if I want to do hand launch of an airplane, after arming, I don't want it keep the control surfaces for force to go back to the position that was at arm time, still I want the error go away in few seconds, and still I want to have some I support when gliding at zero power.

In my yesterdays tests I did not noticed any issues with completely disabled I term zeroing. Usually I hand launch my wing in HORIZON mod, and glide with zero TH is really smooth and stable that way.
Your solution sounds same as TPA but for zero TH. Right?

Regards
Andrej

Re: Release v2.3 is coming soon... prepare

Posted: Sun Oct 20, 2013 12:00 am
by Alexinparis
iosonologio wrote:Baro signal has some aliasing (i.e.: two successive points with the same value), that happens really often (every 3-5 points). Since the signal in Multiwii (when on cable) is updated at around 3Hz, i think there might be a bigger underlying problem. Please notice that only baro seems to have this issue, while gyro signals are smooth.

Did anybody see the same?


because baro signal is not updated internally so fast.
See Baro_update() function and you will see you can't expect a new value sooner than 20ms after the previous one.

Re: Release v2.3 is coming soon... prepare

Posted: Sun Oct 20, 2013 3:23 pm
by iosonologio
Alexinparis wrote:because baro signal is not updated internally so fast.
See Baro_update() function and you will see you can't expect a new value sooner than 20ms after the previous one.


I agree on Baro being updated every 20ms.
But signal in multiwii config is received only every 300ms or so (please correct me here). It should not see any aliasing unless the baro signal is updated slower than that. (I noticed that also while sampling baro values from matlab, at really precise reading times ~500ms).
I might have some time today to dig deeper.

eeprom save in "GUI Settings" page problem

Posted: Tue Oct 29, 2013 12:48 pm
by quadflyer8
have tested in R1573 and right now in R1604 to save in the GUI "Settings page" some values.

First, i found VBATscale was not saved, but then tried other "green" values in this page:
Mintrottle / vbatscale / MAG DECL and none of them was sucessfully saved with write after changed.

After a powerdown and repower, the old values are shown in this page.
All other stuff on first multiwii GUI Page were sucessfully saved.

Have done a complete eeprom clean with Arduino sketch to verify...

using Arduino IDE 1.05 / R1604 / Promini / 328p...
cu, Michael

Re: Release v2.3 is coming soon... prepare

Posted: Wed Oct 30, 2013 11:33 pm
by ttcorse
still not solved the problem with Crius aiop v1.1 and CN-06 GPS Receiver V2.0, does not recognize the GPS and the LED remains fixed access only after resetting "card powered" recognizes and executes the GPS fix .

Re: Release v2.3 is coming soon... prepare

Posted: Thu Oct 31, 2013 9:58 pm
by scrat
ttcorse wrote:still not solved the problem with Crius aiop v1.1 and CN-06 GPS Receiver V2.0, does not recognize the GPS and the LED remains fixed access only after resetting "card powered" recognizes and executes the GPS fix .


I have had the same config like you. MWii 2.2 GPS was working every time.

Re: Release v2.3 is coming soon... prepare

Posted: Thu Oct 31, 2013 10:29 pm
by ttcorse
scrat wrote:
ttcorse wrote:still not solved the problem with Crius aiop v1.1 and CN-06 GPS Receiver V2.0, does not recognize the GPS and the LED remains fixed access only after resetting "card powered" recognizes and executes the GPS fix .


I have had the same config like you. MWii 2.2 GPS was working every time.


With 2.2 I had no problems, now is a bit uncomfortable reset every time because I also the canopy to protect all the eletrĂ´nica and every time I have to take it apart.

Re: Release v2.3 is coming soon... prepare

Posted: Thu Oct 31, 2013 11:38 pm
by haydent
hope its not too late to squeeze this into 2.3, but here is a patch to add amperage display to the GUI

viewtopic.php?p=42892#p42892

Re: eeprom save in "GUI Settings" page problem

Posted: Fri Nov 01, 2013 8:06 pm
by Alexinparis
quadflyer8 wrote:have tested in R1573 and right now in R1604 to save in the GUI "Settings page" some values.

First, i found VBATscale was not saved, but then tried other "green" values in this page:
Mintrottle / vbatscale / MAG DECL and none of them was sucessfully saved with write after changed.

After a powerdown and repower, the old values are shown in this page.
All other stuff on first multiwii GUI Page were sucessfully saved.

Have done a complete eeprom clean with Arduino sketch to verify...

using Arduino IDE 1.05 / R1604 / Promini / 328p...
cu, Michael


Hi,
I also have this problem on some of my 328p boards (not all).
there is apparently a problem with NO_FLASH_CHECK
activate #define NO_FLASH_CHECK and it should be good after a proper reset.

Re: Release v2.3 is coming soon... prepare

Posted: Fri Nov 01, 2013 10:57 pm
by PatrikE

Code: Select all

#define OPENLRSv2MULTI  // OpenLRS v2 Multi Rc Receiver board including ITG3205 and ADXL345

Don't compile after .cpp/.h change.

Re: eeprom save in "GUI Settings" page problem

Posted: Sun Nov 03, 2013 10:36 pm
by Hamburger
Alexinparis wrote:I also have this problem on some of my 328p boards (not all).
there is apparently a problem with NO_FLASH_CHECK
activate #define NO_FLASH_CHECK and it should be good after a proper reset.


my test case:
compile & upload,
run gui,
reconnect,
read,
change pid value to 17,
write,
read (pid value should be 17),
exit gui,
run gui,
reconnect,
read - observe pid value: should be 17, not default value <-- this fails

this works:

Code: Select all

//#define NO_FLASH_CHECK
//#define MULTIPLE_CONFIGURATION_PROFILES


this does not work: (after power cycle/board reset the pid value is back to default)

Code: Select all

//#define NO_FLASH_CHECK
#define MULTIPLE_CONFIGURATION_PROFILES

Re: eeprom save in "GUI Settings" page problem

Posted: Mon Nov 04, 2013 9:50 pm
by quadflyer8
Hamburger wrote:
Alexinparis wrote:I also have this problem on some of my 328p boards (not all).
there is apparently a problem with NO_FLASH_CHECK
activate #define NO_FLASH_CHECK and it should be good after a proper reset.

this works:

Code: Select all

//#define NO_FLASH_CHECK
//#define MULTIPLE_CONFIGURATION_PROFILES

Thanks Alexinparis and Hamburger, I will try this #defines.
cu,
Michael