Let's try to release 2.1: second try based on r964

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Let's try to release 2.1: second try based on r964

Post by Alexinparis »

http://code.google.com/p/multiwii/downloads/list

with a text revision project:

Code: Select all

Some things everyone should be aware before upgrading to this version.

  WMP and NUNCHUCK are no longer auto recognized.
  You must explicitly declare them (or just WMP) in config.h

  Pullups are now undefined by default
    (think about activating it if you use a WMP only conf)
  LCD is not activated by default

  Failsafe is not activated by default

  There is no more .pde files
  You must use Arduino 1.0 or greater to compile the sketch (and open Multiwii.ino)

  If the GUI does not work on your setup,
    try to deactivate hardware acceleration for your display board
    or use an alternative GUI like WinGUI

  MultiWii is not a product, nor a plug and play solution.
  Don't expect to buy a compatible board and run it without a minimum knowledge.


Receiver part
  OpenLRS Multi board support done
    This is a board including an OpenLRS receiver where the atmel
    is used also to run multiwii code.
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1438


Multiwii Serial Protocol
  It's a new protocol to communicate with the FC
  It was introduced by me and tuned by Tommie
  It's a huge change, but it should ensure a generic way to communicate with the FC,
  which is less dependant to version evolutions.
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1516
 
  Now, there is no mod to the multiwii if we want to add a GUI/OSD/conf tool/...

  Compatible GUI:
    open source code, compatible with the new serial protocol
    WinGUI from EOSBandi, which is fully equivalent with the original one,
     with a better look
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1229
    mwGui from kos
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1791
    Android ones via serial bluetooth:
     - adding a bluetooth module to multiwii
       more info here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=133
     compatible apps:
      https://play.google.com/store/apps/details?id=net.xrotor.andmultiwiiconf
      https://play.google.com/store/apps/details?id=net.loide.games.bicopter
      https://play.google.com/store/apps/details?id=com.naze32.configurator

  Compatible OSD:
    open source code, compatible with the new serial protocol
    Rushduino:
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=922
    mobiDrone:
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1498

LCD config
  OLED display
    thanks to contributions of howardhb and Hamburger
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=7&t=1350

  VT100 terminal type addition
    thanks to contribution of Hamburger
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=7&t=1096

  A multiline option is added to allow the configuration on more than 2 lines
    useful for displays like OLED or VT100

  We have now a lot of possibilities regarding LCD:
    SERIAL3W : original 2x16 line from Sparkfun
    TEXTSTAR : Cat's Whisker LCD_TEXTSTAR Module CW-LCD-02
    VT100 : vt100 compatible terminal
    ETPP : Eagle Tree Power Panel LCD
    LCD03 : an i2c LCD
    OLED_I2C_128x64

New proc: ATmega32U4
  Thanks to the work from ronco.
  This proc can be found in the Arduino pro micro board, or Teensy 2.0
  The Pro Micro is similar to the Pro Mini except with an ATmega32U4 on board.
  The USB transceiver inside the 32U4 allows us to add USB connectivity on-board.
  ronco also designed a custom board named nanowii.
  One of the smallest 6DOF Multiwii board with usb, which can be now purchased.
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1337

Servo:
  Higher refresh rate:
    Some servo (mostly digital ones) can work with a higher frequency than 50Hz.
    The consequence is a sharper response.
    ronco adapted the code to make this frequency configurable
    more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1644
  Hardware PWM output:
    On MEGA boards, it's now possible to drive the gimbal servos with
    a 11-bit PWM servo resolution. Thanks to ronco.
    The hardware PWM output ensures a jitter free response.

LED flasher
  A way to set a flash LED sequence from Tommie
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1505

Throttle expo
  There is now another curve in the GUI to configure the Throttle expo.
  It's a way to smooth the throttle stick response around the hover point.
  In order to help the setting, there is a small cursor in the graph to show
  where is the current throttle input.

ACC LEVEL improvement
  The LEVE mode is improved since 2.0 thanks to new choice of
  new complementary filter coefficients and a floating point low pass filter

Headfree checkbox:
  It's possible to reset the headfree direction while flying via a checkbox.
  thanks to Tommie

Sensor:
  MPU6050: there was a bug which prevents using the gyro LPF. correted now.
  SONAR: I2C sonar SRF0x code was added but is not currently used.
  many new boards was also added in config.h file


Internal code:
  The Serial part uses now less RAM (thanks to Tommie first mod)
    RX/TX buffers are smaller than before.
  EEPROM parameters are stored in a struct, and are written in the
    EEPROM in a single step.
  MAG declination was added by EOSBandi, to have more accurate orientation.
  In some countries, it's really mandatory to set this variable right,
   otherwise it's impossible to use GPS.
  Flag var was introduced for global boolean type variables.
  Hamburger introduced some "copter exemple" in order to check
  if compilation is ok. (should be a way to remove some trivial bugs)

GUI:
  thanks to Danal, there is now the PIN number and the propeller direction
  drawed in the graph representation
  thanks to kos, we can now load and save parameters into a file
  there is now a reset button to set all parameters to default

GPS code:
  Thanks to the work of EOSBandi, we have now a working GPS code !
  The navigational routines are based on the works of Jason Short
  and the Arducopter team (another great open source project).
  EOSBandi adapted it to multiwii.
  basically, there are 2 main options for GPS: SERIAL option and I2C option.

    - If you have a spare serial port AND an AtMega1280 or 2560 microcontroller
    based FC, you can connect your GPS to that port and enable the serial GPS
    code in the code.
    Patrick introduced a way to switch automaticly because GUI message parsing
    or NMEA message parsing on the same Serial port
    (useful for promini because you can use the same port for GUI and GPS
    in an exclusive mode)
   
    - You can use an I2C_GPS board, which contains a secondary AtMega328 processor
    with a serial GPS and runs the GPS parsing and navigational computations.
    This board communicates with the FC via the I2C bus.

  more info here: http://code.google.com/p/i2c-gps-nav/downloads/list
  and here in this huge post: http://www.multiwii.com/forum/viewtopic.php?f=8&t=649

  There is also a specific GPS_FROM_OSD option:
    it's a way to use the GPS device of OSD to feed Multiwii with GPS data
    MIS OSD uses this functionality

ESC calibration
  experimental
  It's a special #define which allows to calibrate all ESCs with exaclty
   the same signal.
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=13&t=1517

AIRPLANE mode
  experimental, more info here:
  http://www.multiwii.com/forum/viewtopic.php?f=8&t=364
  https://code.google.com/p/multiwii/wiki/MWiiAirplane

HELICOPTER mode
  experimental
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1562

Dual & Single copter
  experimental
  more info here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1882

An attempt to improve the documentation via wiki
  wiki from googlecode:
  https://code.google.com/p/multiwii/w/list
  wiki from multiwii.com
  http://www.multiwii.com/wiki/index.php?title=Main_Page
  We all know the overall documentation is still to improve.


Please:
- comment the text above (some features or credits are probably not exhaustive...)
- continue to post here every bug you are aware of on this version

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: Let's try to release 2.1: second try based on r964

Post by kos »

bug : saving dialog title
bug : you can overwrite configuration file without confirmation

-> solved in r965

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Let's try to release 2.1: second try based on r964

Post by nhadrian »

I found a small bug which exists in the previous RC too.
When using OLED display, after I exit from the LCD menu, the screen remains black, not showing the initial message.

BR
Adrian

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

also new in 2.1 (from wishlist)
  • GUI visual feedback on all states (same way it is done for existent sensors now) and free up screen space next to sensors' list
  • airplane mode
  • 8MHz support
  • GUI: reset button
  • GUI: automatically turn graphs off for non present sensors
  • promicro support
  • type airplane has more features (flaperons etc.)
  • code style (indentation, variable naming convention etc.) started
  • GUI requires new ControlP5 library to compile - no backwards compatibility - binariy not affected
  • new telemetry manual stepping mode
  • type helicopter: kudos go to PatrikE
  • configurable TX stick combos for arm/disarm
  • definition for nanowii board viewtopic.php?f=6&t=1337
  • configurable rate for servo signals
  • GYRO_SMOOTHING is LCDmenu configurable items, stored in eeprom
  • new structure of config.h

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: Let's try to release 2.1: second try based on r964

Post by kos »

Hamburger wrote:also new in 2.1 (from wishlist)
  • 8MHz support


wrong , there is no support for 8mhz in 2.1

chris ables
Posts: 317
Joined: Wed Feb 08, 2012 8:42 pm
Location: United states

Re: Let's try to release 2.1: second try based on r964

Post by chris ables »

Configurable rates for esc refresh rate in gui didn't make it ?

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

nhadrian wrote:I found a small bug which exists in the previous RC too.
When using OLED display, after I exit from the LCD menu, the screen remains black, not showing the initial message.

Adrian,
why would you expect to see that same message again?

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by LenzGr »

I updated my quad using r964 today, running on a Seeeduino Mega with the "allinone" board from csg_eu and a Spektrum Satellite receiver. ESCs are HK SS20 with Simon's tgy firmware.

My configuration looks as follows:

Code: Select all


[lenz@labtop MultiWii_shared]% bzr diff
=== modified file 'config.h'
--- config.h   2012-07-03 22:04:56 +0000
+++ config.h   2012-07-07 23:43:00 +0000
@@ -28,7 +28,7 @@
     //#define BI
     //#define TRI
     //#define QUADP
-    //#define QUADX
+    #define QUADX
     //#define Y4
     //#define Y6
     //#define HEX6
@@ -50,24 +50,24 @@
     //#define MINTHROTTLE 1300 // for Turnigy Plush ESCs 10A
     //#define MINTHROTTLE 1120 // for Super Simple ESCs 10A
     //#define MINTHROTTLE 1064 // special ESC (simonk)
-    #define MINTHROTTLE 1150
+    #define MINTHROTTLE 1015
 
   /****************************    Motor maxthrottle    *******************************/
     /* this is the maximum value for the ESCs at full power, this value can be increased up to 2000 */
-      #define MAXTHROTTLE 1850
+      #define MAXTHROTTLE 2000
 
   /****************************    Mincommand          *******************************/
     /* this is the value for the ESCs when they are not armed
        in some cases, this value must be lowered down to 900 for some specific ESCs, otherwise they failed to initiate */
-      #define MINCOMMAND  1000
+      #define MINCOMMAND  900
 
   /**********************************    I2C speed   ************************************/
-    #define I2C_SPEED 100000L     //100kHz normal mode, this value must be used for a genuine WMP
-    //#define I2C_SPEED 400000L   //400kHz fast mode, it works only with some WMP clones
+    //#define I2C_SPEED 100000L     //100kHz normal mode, this value must be used for a genuine WMP
+    #define I2C_SPEED 400000L   //400kHz fast mode, it works only with some WMP clones and with most current boards
 
   /***************************    Internal i2c Pullups   ********************************/
-    /* enable internal I2C pull ups (in most cases it is better to use external pullups) */
-    //#define INTERNAL_I2C_PULLUPS
+    //enable internal I2C pull ups (in most cases it is better to use external pullups)
+    #define INTERNAL_I2C_PULLUPS
 
   /**************************************************************************************/
   /*****************          boards and sensor definitions            ******************/
@@ -91,7 +91,7 @@
       //#define QUADRINO        // full FC board 9DOF+baro board from witespy  with BMP085 baro     <- confirmed by Alex
       //#define QUADRINO_ZOOM   // full FC board 9DOF+baro board from witespy  second edition
       //#define QUADRINO_ZOOM_MS// full FC board 9DOF+baro board from witespy  second edition       <- confirmed by Alex
-      //#define ALLINONE        // full FC board or standalone 9DOF+baro board from CSG_EU
+      #define ALLINONE        // full FC board or standalone 9DOF+baro board from CSG_EU
       //#define AEROQUADSHIELDv2
       //#define ATAVRSBIN1      // Atmel 9DOF (Contribution by EOSBandi). requires 3.3V power.
       //#define SIRIUS          // Sirius Navigator IMU                                             <- confirmed by Alex
@@ -185,7 +185,7 @@
    /* optionally disable stick combinations to arm/disarm the motors.
      * In most cases one of the two options to arm/disarm via TX stick is sufficient */
     #define ALLOW_ARM_DISARM_VIA_TX_YAW
-    #define ALLOW_ARM_DISARM_VIA_TX_ROLL
+    //#define ALLOW_ARM_DISARM_VIA_TX_ROLL
 
   /***********************          Cam Stabilisation             ***********************/
     /* The following lines apply only for a pitch/roll tilt stabilization system. Uncomment the first or second line to activate it */
@@ -307,7 +307,7 @@
          Spektrum Satellites are 3V devices.  DO NOT connect to 5V!
          For MEGA boards, attach sat grey wire to RX1, pin 19. Sat black wire to ground. Sat orange wire to Mega board's 3.3V (or any other 3V to 3.3V source).
          For PROMINI, attach sat grey to RX0.  Attach sat black to ground. */
-      //#define SPEKTRUM 1024
+      #define SPEKTRUM 1024
       //#define SPEKTRUM 2048
 
     /*******************************    SBUS RECIVER    ************************************/


The code compiled fine and initial tests on the bench (using the stock PID values) looked good. The values displayed on the GUI were OK. I hope I'll get a chance to take it out tomorrow and will report back. Are you looking for any particular feedback? Any new feature that should be enabled?

The only thing that confused me (I did not notice this change when merging my old configuration) was the new possibility to also arm the copter using the roll stick - I suggest disabling that one by default to avoid nasty surprises for people who are used to arming with the yaw stick and not aware of this change.

Deet
Posts: 129
Joined: Sun Jul 08, 2012 1:54 am

Re: Let's try to release 2.1: second try based on r964

Post by Deet »

The GUI opens in a strange full screen mode on MAC OS X 10.7.4

Its a full grey screen with a lighter grey patch in the top left corner and the GUI window centred on screen

In the bottom left corner on its own is a gryg rectange with the word STOP, this closes the GUI

No Header or tool bar shows while the GUI is open

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Let's try to release 2.1: second try based on r964

Post by nhadrian »

Deet wrote:The GUI opens in a strange full screen mode on MAC OS X 10.7.4

Its a full grey screen with a lighter grey patch in the top left corner and the GUI window centred on screen

In the bottom left corner on its own is a gryg rectange with the word STOP, this closes the GUI

No Header or tool bar shows while the GUI is open


Hi,

the same here with OSX Lion...

BR Adrian

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Let's try to release 2.1: second try based on r964

Post by nhadrian »

Hamburger wrote:
nhadrian wrote:I found a small bug which exists in the previous RC too.
When using OLED display, after I exit from the LCD menu, the screen remains black, not showing the initial message.

Adrian,
why would you expect to see that same message again?


There is no sense on have any initial message at all, but, with the previous versions on the LCD the init message was always there, showing that the LCD works...
And also in the previous message the stick combos were shnown too.

BR
Adrian

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

Deet wrote:The GUI opens in a strange full screen mode on MAC OS X 10.7.4
Its a full grey screen with a lighter grey patch in the top left corner and the GUI window centred on screen
In the bottom left corner on its own is a gryg rectange with the word STOP, this closes the GUI
No Header or tool bar shows while the GUI is open


It is what Processing puts out for an exported application as fullscreen. The STOP button is an optional feature which can be turned on/off while exporting. Running as fullscreen cures some problems with GL used for the copter graphics. In some cases it is the only way to get a working GUI . Not sure if providing the macosx GUI program as fullscreen was an active decision on Alex' part but if it broadens the number of users for which the GUI works out of the box, then I am pro fullscreen and would consider the inconsistent look a minor tradeoff.

User avatar
BlueAngel
Posts: 30
Joined: Sun Feb 27, 2011 11:35 am

Re: Let's try to release 2.1: second try based on r964

Post by BlueAngel »

on my computer (Win Vista 64bit) i had sometimes with crashing GUI, just displaying grey after some time and java.exe needs much cpu power.
With GUI from r949 everything works great.
GUI form r964 starts in full screen and i can only see the normal GUI in the middle of the screen for a few milliseconds and than only full screen grey. :(

currently i am using r949 GUI with r964 code, that works without problems.

was using every time the 32bit GUI, 64bit GUI never starts on my computer.

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

Hi Adrian,
thanks for the feedback.
nhadrian wrote:There is no sense on have any initial message at all, but, with the previous versions on the LCD the init message was always there, showing that the LCD works...
And also in the previous message the stick combos were shnown too.


I tried incorporating the latest changes from Howard as best I could, maybe not good enough.
For the stick combo being displayed we have this in initLCD():

Code: Select all

#if defined(OLED_I2C_128x64) && !(defined(OLED_I2C_128x64LOGO_PERMANENT)) && defined(NEW_OLED_FONT) && !(defined(LCD_TELEMETRY))
  // no need to diplay this, if LCD telemetry is enabled
  //   optional instruction on the display......
  LCDsetLine(4); LCDprintChar("To ENTER CONFIG      ");// 21 characters on each line
  LCDsetLine(5); LCDprintChar("YAW RIGHT & PITCH FWD");
...
 

and I seem to remember Howard explicitly removed the repeated calls to initLCD(), and thus re-displaying this info. Instead he gave you the option to permanently display the logo while no other use of lcd.
Does this make sense? I always run with telemetry enabled & logo disabled, so I have never seen the stick combo info anyway.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Sebbi »

Hey,

i am pretty new to multicopter flying, but I want to help develop MultiWii in a more solid flightcontrol software. So far I have tried out 2.0 the 20120606 dev version and now this release candidate on my quadrocopter. I am flying with a pro mini and FreeIMU 4.3 with the default PIDs.

My comments here are for r964:

* level mode: works ok, however when the copter slightly moves to one direction it seems to accelerate in this direction. Shouldn't the algorithm compensate this behaviour, e.g. forward acceleration causes gravity vector to point slightly forward which would cause the pitch to compensate in the other direction stopping the acceleration. Or is this a PID problem?

* althold mode: taking off with this mode enabled is very hard as the altitude oscillates wildly. It also oscillates after switching it on when the copter is not perfectly still (vertical direction). The altitude data itself (GUI) looks ok, so this could be a PID problem, too? From looking at the code I noticed the algorithm for estimating the error directly computes the needed throttle delta ... wouldn't it be better if we had some vertical velocity variable and the copter tries to get to a certain height with a constant velocity (possibly decelerating when near target height). As everyone has different motors and copter weight the default PID values with the current algorithm will almost never work. Also, Z-acceleration is never used anywhere. I am willing to look into this if anyone is interested.

* gps hold: probably also a PID thing? I dragged my copter around and the position data seems to be super accurate (suprised me a little bit, as GPS was supposed to be like 10m off sometimes?). However, activating this mode the copter doesn't seem to hold its position with the same accuracy. In the code I noticed some variables declaring a waypoint reached if within 2 meters? Is this correct? Doesn't that introduce another inaccuracy?

* general stuff: my copter flies pretty well and I attribute a lot of my problems to me being a beginner. The code looks clean enough but could use more comments from the authors of some of the algorithms used to make it easier to understand and improve the source code. Which brings me to the last point? Why is this not on Github or some other hoster which supports true distributed development? Github would also offer a bug/issue tracker. Doing this via a forum seems very unproductive ;-)

That's it for now. I was also surprised to have the GUI in fullscreen now and it is sometimes really hard to activate one of the "aux" boxes, it "feels" like the click area is too small.

P.S.: Compiled code is now barely fitting inside a Pro Mini with FreeIMU, TinyGPS (with Sonar), Vbat and Powermeter activated. I can't use failsafe mode anymore. Does the arduino compiler optimize for size already? Have there been efforts to optimize the source code itself in this direction?

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Let's try to release 2.1: second try based on r964

Post by shikra »

Standard HEX6 and HEX6X defines still seem slightly off it was raised in one of the threads.

Untested, but I think maybe following would be closer approximation:
#ifdef HEX6
motor[0] = PIDMIX(-7/8,+1/2,+1); //REAR_R
motor[1] = PIDMIX(-7/8,-1/2,-1); //FRONT_R
motor[2] = PIDMIX(+7/8,+1/2,+1); //REAR_L
motor[3] = PIDMIX(+7/8,-1/2,-1); //FRONT_L
motor[4] = PIDMIX(+0 ,-1 ,+1); //FRONT
motor[5] = PIDMIX(+0 ,+1 ,-1); //REAR
#endif
#ifdef HEX6X
motor[0] = PIDMIX(-1/2,+7/8,+1); //REAR_R
motor[1] = PIDMIX(-1/2,-7/8,+1); //FRONT_R
motor[2] = PIDMIX(+1/2,+7/8,-1); //REAR_L
motor[3] = PIDMIX(+1/2,-7/8,-1); //FRONT_L
motor[4] = PIDMIX(-1 ,+0 ,-1); //RIGHT
motor[5] = PIDMIX(+1 ,+0 ,+1); //LEFT
#endif

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Let's try to release 2.1: second try based on r964

Post by mahowik »

about mixes and throttle expo: viewtopic.php?f=8&t=1973&p=18348#p18348

warthox
Posts: 65
Joined: Sat Jan 29, 2011 10:05 pm

Re: Let's try to release 2.1: second try based on r964

Post by warthox »

the gui is also fullscreen on win7 64bit. and its also crashing after a short time.
if possible please make it like it was until now; in a window.
fullscreen is totally useless and counterproductive.

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: Let's try to release 2.1: second try based on r964

Post by kos »

:)

ReM
Posts: 14
Joined: Sun Jul 08, 2012 12:02 pm
Location: Lithuania

Re: Let's try to release 2.1: second try based on r964

Post by ReM »

warthox wrote:the gui is also fullscreen on win7 64bit. and its also crashing after a short time.
if possible please make it like it was until now; in a window.
fullscreen is totally useless and counterproductive.


In Win7 32 bit the same...

sismeiro
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re: Let's try to release 2.1: second try based on r964

Post by sismeiro »

warthox wrote:the gui is also fullscreen on win7 64bit. and its also crashing after a short time.
if possible please make it like it was until now; in a window.
fullscreen is totally useless and counterproductive.

I also like more the window mode but we can always get Processing, the controlP5 library and "compile" a window version of the GUI.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Sebbi »

Altitude from baro is freezing after some time in this version. I don't know if this happened before, but when I leave the gui open for long enough the alt value will freeze. It's not a gui problem (I connected to the copter with a self written application and MultiWii is definetly returning a static alt value). There are no I2C errors and I'm using the FreeIMU 4.3 board.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

ok, some items are already mentioned, I will add others.

Hamburger wrote:also new in 2.1 (from wishlist)
  • GUI visual feedback on all states (same way it is done for existent sensors now) and free up screen space next to sensors' list
    => will add in description
  • airplane mode
    => already described
  • 8MHz support
    => not included
  • GUI: reset button
    => will add in description
  • GUI: automatically turn graphs off for non present sensors
    => will add in description
  • promicro support
    => already described
  • type airplane has more features (flaperons etc.)
    => experimental
  • code style (indentation, variable naming convention etc.) started
    => will add in description
  • GUI requires new ControlP5 library to compile - no backwards compatibility - binariy not affected
    => will add in description
  • new telemetry manual stepping mode
    => will add in description
  • type helicopter: kudos go to PatrikE
    => experimental, kudos already in credit ;)
  • configurable TX stick combos for arm/disarm
    => will add in description
  • definition for nanowii board viewtopic.php?f=6&t=1337
    => already described
  • configurable rate for servo signals
    => already described
  • GYRO_SMOOTHING is LCDmenu configurable items, stored in eeprom
    => one item among others in the LCD code evolution
  • new structure of config.h
    => will add in description

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

chris ables wrote:Configurable rates for esc refresh rate in gui didn't make it ?

??? there is no such functionality.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

LenzGr wrote:The code compiled fine and initial tests on the bench (using the stock PID values) looked good. The values displayed on the GUI were OK. I hope I'll get a chance to take it out tomorrow and will report back. Are you looking for any particular feedback? Any new feature that should be enabled?

Hi,
I just expect a check on your own config, to detect a potential bug or a possible ambiguity in a function.

The only thing that confused me (I did not notice this change when merging my old configuration) was the new possibility to also arm the copter using the roll stick - I suggest disabling that one by default to avoid nasty surprises for people who are used to arming with the yaw stick and not aware of this change.

ok, this if a wise remark.
//#define ALLOW_ARM_DISARM_VIA_TX_ROLL
will be commented by default.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

warthox wrote:the gui is also fullscreen on win7 64bit. and its also crashing after a short time.
if possible please make it like it was until now; in a window.
fullscreen is totally useless and counterproductive.


You're right, it was a mistake on my side.
I've tested the full screen option, and forgot to disable it while exporting the GUI binary.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

Hi,

Sebbi wrote:* level mode: works ok, however when the copter slightly moves to one direction it seems to accelerate in this direction. Shouldn't the algorithm compensate this behaviour, e.g. forward acceleration causes gravity vector to point slightly forward which would cause the pitch to compensate in the other direction stopping the acceleration. Or is this a PID problem?

It is an algorithm problem.
I don't think it could be corrected by PID.
You can change instead the GYRO vs ACC factor in IMU.ino

Code: Select all

/* Set the Gyro Weight for Gyro/Acc complementary filter */
/* Increasing this value would reduce and delay Acc influence on the output of the filter*/
/* Default WMC value: 300*/
#ifndef GYR_CMPF_FACTOR
  #define GYR_CMPF_FACTOR 400.0f
#endif




* althold mode: taking off with this mode enabled is very hard as the altitude oscillates wildly. It also oscillates after switching it on when the copter is not perfectly still (vertical direction). The altitude data itself (GUI) looks ok, so this could be a PID problem, too? From looking at the code I noticed the algorithm for estimating the error directly computes the needed throttle delta ... wouldn't it be better if we had some vertical velocity variable and the copter tries to get to a certain height with a constant velocity (possibly decelerating when near target height). As everyone has different motors and copter weight the default PID values with the current algorithm will almost never work. Also, Z-acceleration is never used anywhere. I am willing to look into this if anyone is interested.

You're welcomed to try to improve the baro mode ;)
It's not an easy task, and there was already a lot of try some months ago.

* gps hold: probably also a PID thing? I dragged my copter around and the position data seems to be super accurate (suprised me a little bit, as GPS was supposed to be like 10m off sometimes?). However, activating this mode the copter doesn't seem to hold its position with the same accuracy. In the code I noticed some variables declaring a waypoint reached if within 2 meters? Is this correct? Doesn't that introduce another inaccuracy?

I don't think so. The switch between mode should be smooth.

* general stuff: my copter flies pretty well and I attribute a lot of my problems to me being a beginner. The code looks clean enough but could use more comments from the authors of some of the algorithms used to make it easier to understand and improve the source code. Which brings me to the last point? Why is this not on Github or some other hoster which supports true distributed development? Github would also offer a bug/issue tracker. Doing this via a forum seems very unproductive ;-)

Again a Github debate...
Doing this via a forum allows to have some discussions before thinking about modifying the code.
What you can "unproductive" is what I call "stability" ;)
True distributed development can only work among a trusted community of developers sharing the same view.
I realized it's not so obvious here because some choices were made deliberately to keep some Arduino principles.

P.S.: Compiled code is now barely fitting inside a Pro Mini with FreeIMU, TinyGPS (with Sonar), Vbat and Powermeter activated. I can't use failsafe mode anymore. Does the arduino compiler optimize for size already? Have there been efforts to optimize the source code itself in this direction?

This is a domain where I would like to see more contribution :)
Code size and efficiency. I'm sure a lot can be done in this direction.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

Sebbi wrote:Altitude from baro is freezing after some time in this version. I don't know if this happened before, but when I leave the gui open for long enough the alt value will freeze. It's not a gui problem (I connected to the copter with a self written application and MultiWii is definetly returning a static alt value). There are no I2C errors and I'm using the FreeIMU 4.3 board.


I think this bug comes from here:

Code: Select all

  if (currentTime < deadLine) return;
  deadLine = currentTime + UPDATE_INTERVAL;


Once deadLine overflows, this bug occurs.

Deet
Posts: 129
Joined: Sun Jul 08, 2012 1:54 am

Re: Let's try to release 2.1: second try based on r964

Post by Deet »

Alexinparis wrote:
LenzGr wrote:

The only thing that confused me (I did not notice this change when merging my old configuration) was the new possibility to also arm the copter using the roll stick - I suggest disabling that one by default to avoid nasty surprises for people who are used to arming with the yaw stick and not aware of this change.

ok, this if a wise remark.
//#define ALLOW_ARM_DISARM_VIA_TX_ROLL
will be commented by default.


I thought this was already a default state primarily for tricopters, and only recently became an option. Commenting by default may confuse some tricopter users that arm this way

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Sebbi »

Alexinparis wrote:
Sebbi wrote:Altitude from baro is freezing after some time in this version. I don't know if this happened before, but when I leave the gui open for long enough the alt value will freeze. It's not a gui problem (I connected to the copter with a self written application and MultiWii is definetly returning a static alt value). There are no I2C errors and I'm using the FreeIMU 4.3 board.


I think this bug comes from here:

Code: Select all

  if (currentTime < deadLine) return;
  deadLine = currentTime + UPDATE_INTERVAL;


Once deadLine overflows, this bug occurs.


So it stops updating after 71 minutes. I think that should be fixed ... not only for when the copter gets its power from an external source, but eventually some copter will hover this long (i've seen videos of attempts reaching roughly an hour of flight time). With motors not armed my copter needs very little power, so it could sit there for an hour before I decide to fly and then it could be trouble ;-)

@Github: it IS easier to clone and merge (pull requests) with git in an open community. Having a bug-/issuetracker wouldn't hurt the forum feature of "discussion first, implementation later" (however, Github or any bugtracker supports this too *g*)

gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Let's try to release 2.1: second try based on r964

Post by gompf-2 »

ESC calib: initOutput() shoud be done before.

Code: Select all

initOutput();
  #if defined(ESC_CALIB_CANNOT_FLY) // <- to move in Output.pde, nothing to do here
    /* this turns into a special version of MultiWii. Its only purpose it to try and calib all attached ESCs */
    writeAllMotors(ESC_CALIB_HIGH);
    delay(3000);
    writeAllMotors(ESC_CALIB_LOW);
    delay(500);
    while (1) {
      delay(5000);
      blinkLED(2,20, 2);
    }
    exit; // statement never reached
#endif

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

Alexinparis wrote:ok, this if a wise remark.
//#define ALLOW_ARM_DISARM_VIA_TX_ROLL
will be commented by default.


I beg to differ, or I did not understand your remark - comment or uncomment?
With the new config.h philosophy, now most any feature has to be selected/enabled if desired: coptertype, sensors, etc.
So it seems logical the arm stick combos are off by default and must be enabled / uncommented if wanted.
(Some users will not want those anyway because they use a TX switch for arming/disarming)?

But whatever default we come up with - most important would be it was consistent in some logical way and _not_ changed on a whim.

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

gompf-2 wrote:ESC calib: initOutput() shoud be done before.

Sounds very reasonable. Did you verify it worked (better) with that change?

bradleyk
Posts: 48
Joined: Wed Jan 19, 2011 10:58 pm

Re: Let's try to release 2.1: second try based on r964

Post by bradleyk »

Hamburger wrote:
I beg to differ, or I did not understand your remark - comment or uncomment?
With the new config.h philosophy, now most any feature has to be selected/enabled if desired: coptertype, sensors, etc.
So it seems logical the arm stick combos are off by default and must be enabled / uncommented if wanted.
(Some users will not want those anyway because they use a TX switch for arming/disarming)?

But whatever default we come up with - most important would be it was consistent in some logical way and _not_ changed on a whim.

+1
to avoid any surprises have both commented out in the release.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

Hamburger wrote:
Alexinparis wrote:ok, this if a wise remark.
//#define ALLOW_ARM_DISARM_VIA_TX_ROLL
will be commented by default.


I beg to differ, or I did not understand your remark - comment or uncomment?
With the new config.h philosophy, now most any feature has to be selected/enabled if desired: coptertype, sensors, etc.
So it seems logical the arm stick combos are off by default and must be enabled / uncommented if wanted.
(Some users will not want those anyway because they use a TX switch for arming/disarming)?

But whatever default we come up with - most important would be it was consistent in some logical way and _not_ changed on a whim.


I'm not sure to understand:
So it seems logical the arm stick combos are off by default and must be enabled / uncommented if wanted.

before the mod, the arm stick combos were both ON by default


Ok, so we differ and the code will keep by default both possibilities.
A note will be added for tricopter users.

Code: Select all

/********************************    ARM/DISARM    *********************************/
   /* optionally disable stick combinations to arm/disarm the motors.
     * In most cases one of the two options to arm/disarm via TX stick is sufficient */
    #define ALLOW_ARM_DISARM_VIA_TX_YAW
    #define ALLOW_ARM_DISARM_VIA_TX_ROLL

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Let's try to release 2.1: second try based on r964

Post by copterrichie »

Starting with version 1.3, I have added the Beep to let me know when the copter is armed and to eliminate surprises, may I suggest adding the beeping(buzzer) to signal when the copter is armed?

Example:

Code: Select all

if (rcDelayCommand == 20) {
          armed = 1;
          Serial1.begin(SERIAL_COM_SPEED);
          Datalogging = 1;
          DataStartTime = millis();
          blinkLED(10,15,2); <--- Signal Arming...
          writeAllMotors(MINTHROTTLE);

if (rcData[YAW] < MINCHECK && armed == 1) {
        if (rcDelayCommand == 20) { // rcDelayCommand = 20 => 20x20ms = 0.4s = time to wait for a specific RC command to be acknowledged
          armed = 0;
          Datalogging = 0; // Turn Off Datalogging
          Serial1.end();
          blinkLED(10,15,3); <--- Beep to signal disarming...
          writeAllMotors(MINCOMMAND);

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

I'm not sure to understand:

two things really:
- new confg.h philosophy is: everything is turned off by default and must be enabled if desired. Even true for coptertype and sensors, so consistent would be like that for stick combos for arming.
- not everybody wants/needs both stick combos - on TRI you do not want the YAW combo; - 3D flyers and users who bind arm/disarm to auxN switch may want both disabled.

Ok, so we differ and the code will keep by default both possibilities.
A note will be added for tricopter users.

Code: Select all

/********************************    ARM/DISARM    *********************************/
   /* optionally disable stick combinations to arm/disarm the motors.
     * In most cases one of the two options to arm/disarm via TX stick is sufficient */
    #define ALLOW_ARM_DISARM_VIA_TX_YAW
    #define ALLOW_ARM_DISARM_VIA_TX_ROLL

maybe add another note for users who bind arm/disarm to auxN so they know they can turn the stick combos off. Maybe important to 3D flyers?

Whatever way round this ends up - most important to me is we keep it that way for a long time and do not change this (and other) defaults all the time. So if you think it is better to have both active by default then so be it.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: Let's try to release 2.1: second try based on r964

Post by ronco »

hi,

i think things like arm with the sticks are good to be activ on default .. maybe just to prevent 10000 support questions ;).. (in this forum and also for the HW sellers)

regards felix

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Let's try to release 2.1: second try based on r964

Post by shikra »

Yeah agree, It's bad enough now with sticks having to be outside min/max checks.

Personally I though having enabled just on yaw was the best. It is a trade off between all the support + guys accidentally disabling motors in mid air when not using switch.

tovrin
Posts: 705
Joined: Tue Sep 20, 2011 4:08 pm

Re: Let's try to release 2.1: second try based on r964

Post by tovrin »

can you disarm while flying? i was under impression throttle had to be at minimum to disarm/arm, which should prevent anyone from disarming while flying since your never at min throttle unless landed/landing. right?

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Let's try to release 2.1: second try based on r964

Post by Bledi »

No I had disarming 2 times during some special accro moves ... Now I always use switch to arm

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Sebbi »

tovrin wrote:can you disarm while flying? i was under impression throttle had to be at minimum to disarm/arm, which should prevent anyone from disarming while flying since your never at min throttle unless landed/landing. right?


3D acrobatics and/or non-copters (MultiWii supports airplanes) may see periods of no throttle while flying ... but I guess those pilots know what to commenct/uncomment to get this working ;-)

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Let's try to release 2.1: second try based on r964

Post by Bledi »

yes you are true ! ;)

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Let's try to release 2.1: second try based on r964

Post by copterrichie »

tovrin wrote:can you disarm while flying? i was under impression throttle had to be at minimum to disarm/arm, which should prevent anyone from disarming while flying since your never at min throttle unless landed/landing. right?


I agree but it has happened.

Jochen
Posts: 5
Joined: Sat Sep 03, 2011 11:14 pm

Re: Let's try to release 2.1: second try based on r964

Post by Jochen »

I got today a very interesting new Crius Board:

http://www.rctimer.com/index.php?gOo=go ... oductname=
(ATMega 2560 ·MPU6050 ·HMC5883L ·MS5611-01BA01 ·FT232RQ USB-UART chip and Micro USB receptacle)

It wold be a fine if anyone could add the IMU Code from the manual into the new release 2.1
http://www.rcgroups.com/forums/showatt. ... 1341616938

kad
Posts: 18
Joined: Sat Jun 09, 2012 1:33 am

Re: Let's try to release 2.1: second try based on r964

Post by kad »

GUI Update on my systems with r964

64 Bit Gui on Windows 7 Pro 64bit, Java 7 (32 & 64 versions installed) - Still will not run. Now get the grey fullscreen box, nothing else. Stop button does not work, have to force close.
32 Bit Gui on Windows 7 Pro 64bit, Java 7 - Continues to run fine, the fullscreen effect is unpleasant but livable.
32 Bit Gui on Windows XP Pro 32bit, Java 6 or 7 - Still no radio channel input box unless all hardware acceleration is turned off. Last time this worked correctly was 2.0 release.

-K

mvturnho
Posts: 1
Joined: Tue Jul 10, 2012 9:05 pm

Re: Let's try to release 2.1: second try based on r964

Post by mvturnho »

I have tried this release, and on the windows 7 64 bit the GUI crashes after a few seconds (and it is full screen), the MultiWiiConf_release_candidate_2_1_r949 was fine.
I have seen this beeing reported a few times but no responce as to what might be the cause.
The crash was also in the 2.0 versions and I have recompiled with new libraries from eclipse but was not able to solve this problem.
Could someone explain what is different between the 2.1_949 version and the 2.0 that this was solved in 2.1_949.

Thanks

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by alexia »

Jochen wrote:I got today a very interesting new Crius Board:

http://www.rctimer.com/index.php?gOo=go ... oductname=
(ATMega 2560 ·MPU6050 ·HMC5883L ·MS5611-01BA01 ·FT232RQ USB-UART chip and Micro USB receptacle)

It wold be a fine if anyone could add the IMU Code from the manual into the new release 2.1
http://www.rcgroups.com/forums/showatt. ... 1341616938



i think it s a good idea because this board will become a new standar in an near futur!!!matmega 2560 is a necessary for the next development!
i hope it will be take in consideration for the next release

Ainadiel
Posts: 17
Joined: Fri Jun 08, 2012 3:37 pm

Re: Let's try to release 2.1: second try based on r964

Post by Ainadiel »

Jochen wrote:I got today a very interesting new Crius Board:

http://www.rctimer.com/index.php?gOo=go ... oductname=
(ATMega 2560 ·MPU6050 ·HMC5883L ·MS5611-01BA01 ·FT232RQ USB-UART chip and Micro USB receptacle)

It wold be a fine if anyone could add the IMU Code from the manual into the new release 2.1
http://www.rcgroups.com/forums/showatt. ... 1341616938



agree, please add this code to v2.1

by the way i really like idea of "Circle" and "Follow Me" options for megapirate soft... sounds like idea for future development... especially "Follow me" so i could use my hex for snowboarding :P

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by Sebbi »

alexia wrote:
Jochen wrote:I got today a very interesting new Crius Board:

http://www.rctimer.com/index.php?gOo=go ... oductname=
(ATMega 2560 ·MPU6050 ·HMC5883L ·MS5611-01BA01 ·FT232RQ USB-UART chip and Micro USB receptacle)

It wold be a fine if anyone could add the IMU Code from the manual into the new release 2.1
http://www.rcgroups.com/forums/showatt. ... 1341616938



i think it s a good idea because this board will become a new standar in an near futur!!!matmega 2560 is a necessary for the next development!
i hope it will be take in consideration for the next release


The definitions for this board are the same as for FreeImu 4.3 ... just use that. As for the atmega 2560 being the future ... I seriously hope not, it is not a bit faster than then 328P and just offers more ports and rom/ram ... everyone should switch to 32 bit ARM and Arduino ist working on that (called "Due").

Post Reply