Release v2.3 is coming soon... prepare

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

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

Postby rbirdie001 » Wed Oct 02, 2013 10:46 pm

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
Attachments
config.zip
My actual config.h with activated I2C GPS
(19.36 KiB) Downloaded 92 times
rbirdie001
 
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

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

Postby sismeiro » Sun Oct 06, 2013 2:37 pm

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
sismeiro
 
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

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

Postby Ringo42 » Mon Oct 07, 2013 3:53 pm

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
Ringo42
 
Posts: 11
Joined: Thu Jun 13, 2013 8:50 pm

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

Postby PatrikE » Mon Oct 07, 2013 5:15 pm

PatrikE
 
Posts: 1950
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden

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

Postby Hamburger » Mon Oct 07, 2013 8:28 pm

info on
- servos pins and setup
- private defaults
- new powermeter setup
updated in wiki and links put into config.h

Please read and enhance.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

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

Postby Hamburger » Mon Oct 07, 2013 8:30 pm

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?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

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

Postby PatrikE » Mon Oct 07, 2013 9:57 pm

Plans, FlyingWing and BI Servos was also changed.
PatrikE
 
Posts: 1950
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden

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

Postby city_kid » Tue Oct 08, 2013 10:12 am

@Hamburger

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

Many thanks!

city_kid
User avatar
city_kid
 
Posts: 64
Joined: Wed Apr 03, 2013 8:09 pm
Location: Birmingham UK

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

Postby Hamburger » Tue Oct 08, 2013 10:34 am

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.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

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

Postby obor » Sun Oct 13, 2013 5:09 pm

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
obor
 
Posts: 26
Joined: Sun Mar 17, 2013 11:58 pm

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

Postby teslahed » Mon Oct 14, 2013 2:24 am

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.
teslahed
 
Posts: 84
Joined: Wed Jun 27, 2012 2:51 pm

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

Postby tovrin » Mon Oct 14, 2013 7:10 pm

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.
tovrin
 
Posts: 705
Joined: Tue Sep 20, 2011 4:08 pm

Postby BarneyG » Mon Oct 14, 2013 7:41 pm

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
BarneyG
 
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

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

Postby sismeiro » Mon Oct 14, 2013 8:30 pm

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
sismeiro
 
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re:

Postby teslahed » Mon Oct 14, 2013 10:23 pm

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.
teslahed
 
Posts: 84
Joined: Wed Jun 27, 2012 2:51 pm

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

Postby iosonologio » Tue Oct 15, 2013 12:40 pm

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?
iosonologio
 
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

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

Postby BarneyG » Tue Oct 15, 2013 1:42 pm

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.
BarneyG
 
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

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

Postby timecop » Tue Oct 15, 2013 1:52 pm

The baro / board probably heated up.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

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

Postby BarneyG » Tue Oct 15, 2013 2:38 pm

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
Last edited by BarneyG on Tue Oct 15, 2013 3:07 pm, edited 1 time in total.
BarneyG
 
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

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

Postby Ringo42 » Tue Oct 15, 2013 2:38 pm

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.
Ringo42
 
Posts: 11
Joined: Thu Jun 13, 2013 8:50 pm

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

Postby obor » Tue Oct 15, 2013 7:27 pm

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...
obor
 
Posts: 26
Joined: Sun Mar 17, 2013 11:58 pm

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

Postby iosonologio » Wed Oct 16, 2013 10:53 am

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?
iosonologio
 
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

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

Postby crashlander » Wed Oct 16, 2013 12:58 pm

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
crashlander
 
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

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

Postby mabaka » Thu Oct 17, 2013 12:57 pm

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).
mabaka
 
Posts: 21
Joined: Thu Oct 17, 2013 12:03 pm

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

Postby e_lm_70 » Fri Oct 18, 2013 1:14 pm

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
e_lm_70
 
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

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

Postby crashlander » Fri Oct 18, 2013 3:24 pm

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
crashlander
 
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

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

Postby Alexinparis » Sun Oct 20, 2013 12:00 am

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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

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

Postby iosonologio » Sun Oct 20, 2013 3:23 pm

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.
iosonologio
 
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

eeprom save in "GUI Settings" page problem

Postby quadflyer8 » Tue Oct 29, 2013 12:48 pm

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
quadflyer8
 
Posts: 6
Joined: Tue Jun 26, 2012 8:57 am

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

Postby ttcorse » Wed Oct 30, 2013 11:33 pm

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 .
ttcorse
 
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

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

Postby scrat » Thu Oct 31, 2013 9:58 pm

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.
scrat
 
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

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

Postby ttcorse » Thu Oct 31, 2013 10:29 pm

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.
ttcorse
 
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

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

Postby haydent » Thu Oct 31, 2013 11:38 pm

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
User avatar
haydent
 
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: eeprom save in "GUI Settings" page problem

Postby Alexinparis » Fri Nov 01, 2013 8:06 pm

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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

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

Postby PatrikE » Fri Nov 01, 2013 10:57 pm

Code: Select all
#define OPENLRSv2MULTI  // OpenLRS v2 Multi Rc Receiver board including ITG3205 and ADXL345

Don't compile after .cpp/.h change.
PatrikE
 
Posts: 1950
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden

Re: eeprom save in "GUI Settings" page problem

Postby Hamburger » Sun Nov 03, 2013 10:36 pm

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
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: eeprom save in "GUI Settings" page problem

Postby quadflyer8 » Mon Nov 04, 2013 9:50 pm

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
quadflyer8
 
Posts: 6
Joined: Tue Jun 26, 2012 8:57 am

Previous

Return to Software development

Who is online

Users browsing this forum: No registered users and 1 guest

cron