Release 2.2 is coming

Alexinparis · Post by **Alexinparis** » Fri Feb 22, 2013 12:48 am

I've just uploaded a pre2.2 here:
http://code.google.com/p/multiwii/downloads/list

Purpose of this topic:
- relate and track every bug you are aware of. No wishlist item here, only factual bugs.

Suggestion for release note 2.1->2.2

main changes since the last release 2.1

***Control mode***

- introduction of HORIZON MODE.
We have now 3 modes:

ACRO mode.
This is the default one when none of the ANGLE & HORIZON BOX is activated.
The copter will continue rotating in the direction in which you tilt sticks. When you let go of sticks it will maintain that angle and not return to

level

ANGLE mode
The position of the stick indicates the angle at which the copter tries to maintain. Sticks off = level. Full sticks in any direction and it will tilt

at around 50 degrees. It's proportional in-between.
It maintains the angle set by the stick. Let go of sticks and it returns to level

HORIZON mode <- new
It's a proportional mix of the two. Sticks off = level. Full deflection = ACRO. In between it gradually mixes from LEVEL mode to ACRO.
It's a fine mix to be able to do some ACRO with the safety of ANGLE mode when you release the sticks.
It allows also a more natural way of flying as the multi seems less constrained.

- failsafe code is more strict. (thanks to MIS)
If activated, it takes into account all the main channels and it's important to stay strictly inside the [1000-2000] range.
For instance a throttle of 995 will activate the failsafe
failsafe is optional and can be activated via #define FAILSAFE

- Acrotrainer mode introduced by PatrikE
a kind of non proportional horizon mode
more info here: viewtopic.php?f=16&t=1944

- SERVO_TILT_MIX
introduced by Bledi and Gary
http://youtu.be/zKGr6iR54vM
corrected after to support optionally up to 2 AUX channels superposition to control the gimbal

- CAM STAB: (thanks to Gary and suggested or Arne)
Ability to define Cam Stab control channels used
Ability to turn off
Fix for AUX3 + 4 affecting tilt/roll with camstab enabled

***add-ons***

- pilotlamp integration (thanks to mr.rc-cam, jevermeister, doughboy )
via #define PILOTLAMP
http://code.google.com/p/multiwii/wiki/ ... _Pilotlamp

- LEDRING pattern was refined thanks to shikra
instructions here: http://code.google.com/p/multiwii/sourc ... README.txt

- variometer introduced by Hamburger
enable to get audio feedback upon rising/falling copter/plane
via #define VARIOMETER

***receiver & UART***

- option to use throttle PIN as the PPM PIN on mega boards thanks to MIS
this way you can use the UART 1 for other purpose
via #define PPM_ON_THROTTLE

- every UART port on MEGA boards can be used at the same time with different baud configuration.
ie, you can connect up to 4 GUI or OSD or anything using MSP simultaneously

- the second UART port on promicro boards can be used at the same time with different baud configuration.

- spektrum (thanks to Danal)
- spektrum satellite up to 12 channels, even if only 8 are usable in multiwii
- spektrum satellite BIND button, to associate a satellite without the main receiver

***PIN mapping***

- possibility to override some PIN definition in config.h (thanks to Hamburger)

***GPS***

- UBLOX GPS: the baud configuration is autodetected and the UBLOX binary protocol is automaticly set (thanks to MIS & EOSBandi)

- MKT GPS can now be parsed in binary mode is possible thanks to EOSBandi
made for DIYDrones MTK firmware v1.6 and v1.9

- I2C GPS:
correct directionToHome (change it to the opposite direction)
there is still a problem remaining when your distance to home reaches 654m: it overflows.
a I2C code evolution is needed to correct this problem

- a forward predictive filter was ported from the Arducopter code by EOSBandi
optional and by default activated: #define GPS_LEAD_FILTER

- first implementation of MSP_SET_WP
with the help of Ezio app (EZ-GUI), we can now control the multi with a smartphone: set a new position on a map / follow me / follow heading
see Multiwii EZ-GUI specific topic: viewtopic.php?f=8&t=2034
some video about this functionality:
http://www.youtube.com/watch?v=qpoPanmVa9Y
http://www.youtube.com/watch?v=hPj6WZex8j0
http://www.youtube.com/watch?v=nPICiiaDTnc

- AP_MODE introduced by PatrikE
used in GPS POS HOLD mode, outside the specified stick range the POS HOLD position is renew

***multiwii models***

- HELICOPTER and PLANE models was refined thanks to PatrickE and Hamburger
multiple helicopter type HELI_120_CCPM , HELI_90_DEG
servo configuration for plane, FLAP, FLAPPERON

- HEXH6 multicopter type added (thanks to shikra)

- Bi-Copter pitch direction setting

- USE_THROTTLESERVO (for airplanes), COLLECTIVE_RANGE changed (second value not offset anymore)

***GUI & OSD & LCD***

- a RECONNECT button was added by PatrickE
a file is now generated to indicate the last COM&Serial speed. The serial speed can be edited in this file to change the UART speed of GUI.

- New MultiWiiConf GUI v2.2 with graphical improvements (thanks to Magnetron and doughboy)
cool things like virtual horizon

- optional 3 independent configurations, stick selectable settings in EEPROM (thanks to MIS)
can be activated via #define MULTIPLE_CONFIGURATION_PROFILES

***LCD***

- on mega boards, it's possible to define the LCD port for LCD supporting true UART.

- more parameters are tunable via LCD conf, all the one in config.h with a small (*) besides, thanks to Hamburger
those parameters will be moved in the GUI later in another step, once we find the good way to do it.
example: failsave.throttle , vbat tunable params , powermeter tunable params

- many telemetry and LCD config enhancements (thanks to hamburger)
telemetry page 3: use long boxnames
telemetry page 2: show numerical values for sensor data next to bar graphs
no user interaction necessary to run telemetry info upon start up
set individual board name string (currently used for display; no GUI representation

yet)

- LCDconfig menu: with THROTTLE=High, increment is 10 times of normal

- servos are moved to neutral position during calibration and lcd.configuration

***OSD***

- RSSI PIN added for OSD use (thanks to Kataventos)
the RSSI output can be retrieved via a MSP message for OSD

- OSD BOX added for OSD activation (thanks to Itai)

- huge work made on an open source code OSD fully compatible with MultiWii (thanks to the team lead by Kataventos)
viewtopic.php?f=8&t=2918
http://code.google.com/p/rush-osd-development/

***IMU and baro***

- gyro calibration could be held until the MWC stops moving
introduced by MIS, and made optional after via a specific define: #define GYROCALIBRATIONFAILSAFE

- mag gain calibration is improved thanks to EOSBandi
based on Fabio FreeIMU code. We won't forget you Fabio...

- perfect euler angle computation in case of 9DOF (better heading)
no more gimbal lock in GUI representation with a 9DOF sensor

- force sensors orientation to override board specific defaults
optional in config.h

- default ACC LPF factor reduced from 16 (2^4), and is share with ACC LPF for alt hold

- gyro/acc complementary filter value increased from 400 to 600

- gyro/mag complementary filter now set to 250 instead of 200

- gyro scale factor changed from 2380 to 2279

- accelerometer now used below 1.15G and above 0.85G instead of previous 1.4G/0.6G settings

- option: SENSORS_TILT_45DEG_LEFT/RIGHT to change X/P configuration without changing board orientation

- ALT HOLD is greatly improved thanks to the code of Mahowik, a little bit optimized since
improved baro hold (PID) algorithm that includes the accelerometer z-axis
its a real major improvement for multiwii
http://www.youtube.com/watch?v=T3htaJ53Z7E

- baro calibration and calculation is improved thanks to Sebbi
baro indicates now altitude 0 when it is powered. This is the reference altitude.

- calculation of barometric altitude changed to include temperature, faster update rate

- new FC boards: SIRIUSGPS, SIRIUS_AIR, SIRIUS_AIR_GPS, MICROWII, GY_521, MultiWiiMega, DESQUARED6DOFV2GO, DESQUARED6DOFV4, LADYBIRD, MEGAWAP_V2_STD,

MEGAWAP_V2_ADV, HK_MultiWii_SE_V2, HK_MultiWii_328P, RCNet_FC, FLYDU_ULTRA

***internal improvements***

- some default PID were changed for optimization speed in PID copmputation.
The default PID should behave exactly as the previous ones.
To restore your old PID settings, just a proportion is needed.

- 5 hardware PWM servos avaliable with Mega boards on pins 44,45,46,11,12 (thanks to MIS)

- EEPROM settings secured by checksum (thanks to MIS)

- optional permanent logging to eeprom
setting: LOG_PERMANENT

- change LED blink frequency for acc-uncalibrated or tilt>25 from 50ms to 10ms

- rework of task scheduler code thanks to ideas from Sebbi
we have now a better computation time repartition

- optional fixate cycle time (by burning cpu time away)

- allow override of motor/servo mixing from config.h - no need to edit Output.ino
experimental

- faster cycle time than with v2.1

- many many hidden optimizations in the code

***documentation***

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

stable and development versions can be found here:
http://code.google.com/p/multiwii/downloads/list
For development versions you are on your own - good luck.
Don't try any development version if you don't follow dev evolution.
Don't forget a multirotor is something that can be dangerous.

For discussion and questions the official forum is at
http://www.multiwii.com/forum

Evolution of the code can be followed here:
http://code.google.com/p/multiwii/source/list

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

AlouetteIII · Post by **AlouetteIII** » Fri Feb 22, 2013 1:34 am

Previously for 2.1 could compile 32u4 + oLED + I2C GPS - with this dev 1349 it wont compile any additional item - neither GPS ; nor oLED/Telemetry.

Deet · Post by **Deet** » Fri Feb 22, 2013 1:41 am

I can compile with I2c GPS +oLED but as soon as I add telemetry the file size gets too big, it goes from 28K to 31K just by add telemetry

Mystic3D · Post by **Mystic3D** » Fri Feb 22, 2013 4:10 am

Cannot Disable
#define AP_MODE 40 // Create a deadspan for GPS.

Fix:
Change this:
if (rcOptions[BOXGPSHOLD] && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE) {
To this:
if (rcOptions[BOXGPSHOLD]
#if defined(AP_MODE)
&& abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE
#endif
) {

This is not my code, thanks to nadrian

Peter · Post by **Peter** » Fri Feb 22, 2013 9:51 am

I'm repeating myself from: viewtopic.php?f=8&t=3099&start=10

Peter wrote:I tested 1342 and the previous dev versions on a plane and a quad x.
The plane has a drotek 10dof with a ms5611 and minim osd and the quad a modified wii gyro, bma180, bmp085, hmc5883, i2c-gps, oled display, bluetooth. Both Pro mini.
I fly with FrSky combined ppm. One at 27ms and the other default.

Both setups have the same problem. They can arm 50% of the time. The problem is that the cycle times go through the roof (negative values).
Looks like a cycle time of a couple of seconds. The plane can sometimes arm, but the controls almost do not work, one change of the servos per 2 seconds.
Power disconnect and reconnect and the problem is solved sometimes. Been flying with the quad for 2 years on 1.9,2.0 and 2.1 without problems.
But the oled display and i2c-gps are relatively new.

Is this a known problem?

Failsave is not compiled in. Yesterday I tested again and got the problem only briefly, after a couple of times arming it worked.

Stars112 · Post by **Stars112** » Fri Feb 22, 2013 12:23 pm

IS the SERIAL3W LCD in Work with the 32u4?
In one of the first DEVS (1317) it dosent work.

mbrak · Post by **mbrak** » Fri Feb 22, 2013 5:46 pm

hi

just uploaded 2.2pre
works fine so far.

just my old problem still exists

i have a ublox neo 6m gps attached on ser2 on my crius allinone v.1 (hk clone)

in gui the gps coords look like:

GPS_Data1mod.jpg: (9.4 KiB) Not downloaded yet

on my oled (telemetrie page 7) it looks like:

looks like an cosmetic error

the first digit of latitude is missing in oled display.

br michael

Hamburger · Post by **Hamburger** » Fri Feb 22, 2013 6:24 pm

Can any other gps+lcd/oled telemetry userz verify above error please?

mbrak · Post by **mbrak** » Fri Feb 22, 2013 7:24 pm

hi

it seem to bee a simple format error. the digits are aligned to the right.

the format ist described here:

strcpy_P(line1,PSTR(".---.----- "));

first character is N or S depending to your location. the other 9 digits incl. the dot at the 6th place from the right.

the complete latitude term has 9 digits. 9 digits plus the dot dont fit in 9 digits space above. -> first digit is missing!

also the dot is at wrong position.....

mbrak · Post by **mbrak** » Fri Feb 22, 2013 7:27 pm

Hamburger wrote:Can any other gps+lcd/oled telemetry userz verify above error please?

hi hamburger

did you took a look at my first picture? GPS_Data1mod.JPG
it is only shown by link.

it is a limit here on this board only one picture per answer is shown?

Wayne · Post by **Wayne** » Fri Feb 22, 2013 7:55 pm

I am missing 1 decimal N and 2 decimals E and the point is in the wrong place.
Good news is I activated the GPS Filtering and my on bench speed when from over 20 to under 5 and distance home stays under 10 now. Once I get this thing outside I think this will help with my less than stellar GPS results.

mbrak · Post by **mbrak** » Fri Feb 22, 2013 7:56 pm

Problem fixed !!!

new Code in LCD.ino

Code: Select all

#if GPS
void fill_line1_gps_lat(uint8_t sat) {
  int32_t aGPS_latitude = abs(GPS_coord[LAT]);
  strcpy_P(line1,PSTR(".--.-------     "));
  //                   0123456789012345
  line1[0] = GPS_coord[LAT]<0?'S':'N';
  if (sat) {
    line1[13] = '#';
    line1[14] = digit10(GPS_numSat);
    line1[15] = digit1(GPS_numSat);
  }
  line1[1] = '0' + aGPS_latitude / 100000000- (aGPS_latitude/1000000000)* 10;
  line1[2] = '0' + aGPS_latitude / 10000000 - (aGPS_latitude/100000000)* 10;
  line1[4] = '0' + aGPS_latitude / 1000000  - (aGPS_latitude/10000000) * 10;
  line1[5] = '0' + aGPS_latitude / 100000   - (aGPS_latitude/1000000)  * 10;
  line1[6] = '0' + aGPS_latitude / 10000    - (aGPS_latitude/100000)   * 10;
  line1[7] = '0' + aGPS_latitude / 1000     - (aGPS_latitude/10000) * 10;
  line1[8] = '0' + aGPS_latitude / 100      - (aGPS_latitude/1000)  * 10;
  line1[9] = '0' + aGPS_latitude / 10       - (aGPS_latitude/100)   * 10;
  line1[10] = '0' + aGPS_latitude           - (aGPS_latitude/10)    * 10;
}
void fill_line2_gps_lon(uint8_t status) {
  int32_t aGPS_longitude = abs(GPS_coord[LON]);
  strcpy_P(line2,PSTR(".--.-------     "));
  //                   0123456789012345
  line2[0] = GPS_coord[LON]<0?'W':'E';
  if (status) {
    line2[13] = (GPS_update ? 'U' : '.');
    line2[15] = (GPS_Present ? 'P' : '.');
  }
  line2[1] = '0' + aGPS_longitude / 100000000- (aGPS_longitude/1000000000)* 10;
  line2[2] = '0' + aGPS_longitude / 10000000 - (aGPS_longitude/100000000)* 10;
  line2[4] = '0' + aGPS_longitude / 1000000  - (aGPS_longitude/10000000) * 10;
  line2[5] = '0' + aGPS_longitude / 100000   - (aGPS_longitude/1000000)  * 10;
  line2[6] = '0' + aGPS_longitude / 10000    - (aGPS_longitude/100000)   * 10;
  line2[7] = '0' + aGPS_longitude / 1000     - (aGPS_longitude/10000) * 10;
  line2[8] = '0' + aGPS_longitude / 100      - (aGPS_longitude/1000)  * 10;
  line2[9] = '0' + aGPS_longitude / 10       - (aGPS_longitude/100)   * 10;
  line2[10] = '0' + aGPS_longitude           - (aGPS_longitude/10)    * 10;
}
#endif

Hamburger · Post by **Hamburger** » Fri Feb 22, 2013 8:57 pm

Lat and lon do use same format for display.
Why is one correct but not the other?
Anyway I still have no gps to test. The code was donated by another gps user.
So before changing it based on a single user complaining I d rather get some clarification from another soirce.
Sorry but I usually do not deal with others code I have no means to test.

Hamburger · Post by **Hamburger** » Fri Feb 22, 2013 9:01 pm

Cannot lon be greater than 99 degrees?

mbrak · Post by **mbrak** » Fri Feb 22, 2013 9:02 pm

found a error in formating GPS coords.

here is the correct code for telemtrie display in LCD.ino

Code: Select all

#if GPS
void fill_line1_gps_lat(uint8_t sat) {
  int32_t aGPS_latitude = abs(GPS_coord[LAT]);
  strcpy_P(line1,PSTR(".---.-------    "));
  //                   0123456789012345
  line1[0] = GPS_coord[LAT]<0?'S':'N';
  if (sat) {
    line1[13] = '#';
    line1[14] = digit10(GPS_numSat);
    line1[15] = digit1(GPS_numSat);
  }
  line1[1]  = '0' + aGPS_latitude  / 1000000000- (aGPS_latitude/10000000000)* 10;
  line1[2]  = '0' + aGPS_latitude  / 100000000 - (aGPS_latitude/1000000000) * 10;
  line1[3]  = '0' + aGPS_latitude  / 10000000  - (aGPS_latitude/100000000)  * 10;
  line1[5]  = '0' + aGPS_latitude  / 1000000   - (aGPS_latitude/10000000)   * 10;
  line1[6]  = '0' + aGPS_latitude  / 100000    - (aGPS_latitude/1000000)    * 10;
  line1[7]  = '0' + aGPS_latitude  / 10000     - (aGPS_latitude/100000)     * 10;
  line1[8]  = '0' + aGPS_latitude  / 1000      - (aGPS_latitude/10000)      * 10;
  line1[9]  = '0' + aGPS_latitude  / 100       - (aGPS_latitude/1000)       * 10;
  line1[10] = '0' + aGPS_latitude  / 10        - (aGPS_latitude/100)        * 10;
  line1[11] = '0' + aGPS_latitude              - (aGPS_latitude/10)         * 10;
}
void fill_line2_gps_lon(uint8_t status) {
  int32_t aGPS_longitude = abs(GPS_coord[LON]);
  strcpy_P(line2,PSTR(".---.-------    "));
  //                   0123456789012345
  line2[0] = GPS_coord[LON]<0?'W':'E';
  if (status) {
    line2[13] = (GPS_update ? 'U' : '.');
    line2[15] = (GPS_Present ? 'P' : '.');
  }
  line2[1]  = '0' + aGPS_longitude / 1000000000- (aGPS_longitude/10000000000)* 10;
  line2[2]  = '0' + aGPS_longitude / 100000000 - (aGPS_longitude/1000000000) * 10;
  line2[3]  = '0' + aGPS_longitude / 10000000  - (aGPS_longitude/100000000)  * 10;
  line2[5]  = '0' + aGPS_longitude / 1000000   - (aGPS_longitude/10000000)   * 10;
  line2[6]  = '0' + aGPS_longitude / 100000    - (aGPS_longitude/1000000)    * 10;
  line2[7]  = '0' + aGPS_longitude / 10000     - (aGPS_longitude/100000)     * 10;
  line2[8]  = '0' + aGPS_longitude / 1000      - (aGPS_longitude/10000)      * 10;
  line2[9]  = '0' + aGPS_longitude / 100       - (aGPS_longitude/1000)       * 10;
  line2[10] = '0' + aGPS_longitude / 10        - (aGPS_longitude/100)        * 10;
  line2[11] = '0' + aGPS_longitude             - (aGPS_longitude/10)         * 10;
}
#endif

now all possible coordinates are shown correct. in the code above only coords with angles < 99 degrees are shown correct.
the only cosmetic i would like to have is to mute the leading "zeros" but do not know how to fix it

mbrak · Post by **mbrak** » Fri Feb 22, 2013 9:05 pm

the problem was that with UBLOX you will have additional digits for more precision. (also with MTK binary!)

the display shifted them all to the left so the leading digits are hidden.

should now be ok.

Hamburger · Post by **Hamburger** » Fri Feb 22, 2013 9:29 pm

So we are getting close.
Please post your section from config.h that resembles your gps setup.
From there we must find out if same applies for other gps setups or not.

mbrak · Post by **mbrak** » Fri Feb 22, 2013 9:51 pm

hi no problem

Code: Select all

 /* GPS using a SERIAL port
       if enabled, define here the Arduino Serial port number and the UART speed
       note: only the RX PIN is used in case of NMEA mode, the GPS is not configured by multiwii
       in NMEA mode the GPS must be configured to output GGA and RMC NMEA sentences (which is generally the default conf for most GPS devices)
       at least 5Hz update rate. uncomment the first line to select the GPS serial port of the arduino */
    #define GPS_SERIAL 2 // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
    //#define GPS_BAUD   57600
    #define GPS_BAUD   115200



       /* GPS protocol 
       NMEA  - Standard NMEA protocol GGA, GSA and RMC  sentences are needed
       UBLOX - U-Blox binary protocol, use the ublox config file (u-blox-config.ublox.txt) from the source tree 
       MTK_BINARY16 and MTK_BINARY19 - MTK3329 chipset based GPS with DIYDrones binary firmware (v1.6 or v1.9)
       With UBLOX and MTK_BINARY you don't have to use GPS_FILTERING in multiwii code !!! */

    
    //#define NMEA
    #define UBLOX
    //#define MTK_BINARY16
    //#define MTK_BINARY19
    //#define INIT_MTK_GPS        // initialize MTK GPS for using selected speed, 5Hz update rate and GGA & RMC sentence or binary settings

    //#define GPS_PROMINI_SERIAL    57600 // Will Autosense if GPS is connected when ardu boots
   
    /* I2C GPS device made with an independant arduino + GPS device
       including some navigation functions
       contribution from EOSBandi   http://code.google.com/p/i2c-gps-nav/ 
       You have to use at least I2CGpsNav code r33 */
    //#define I2C_GPS

    /* I2C GPS device made with an indeedent ATTiny[24]313 + GPS device and
       optional sonar device.    https://github.com/wertarbyte/tiny-gps/ */
    /* get GPS data from Tiny-GPS */
    //#define TINY_GPS
    /* get sonar data from Tiny-GPS */
    //#define TINY_GPS_SONAR

    /* GPS data readed from Misio-OSD - GPS module connected to OSD, and MultiWii read GPS data from OSD - tested and working OK ! */
    //#define GPS_FROM_OSD

    /* indicate a valid GPS fix with at least 5 satellites by flashing the LED  - Modified by MIS - Using stable LED (YELLOW on CRIUS AIO) led work as sat number indicator 
      - No GPS FIX -> LED blink at speed of incoming GPS frames
      - Fix and sat no. bellow 5 -> LED off
      - Fix and sat no. >= 5 -> LED blinks, one blink for 5 sat, two blinks for 6 sat, three for 7 ... */
    #define GPS_LED_INDICATOR

    //#define USE_MSP_WP                        //Enables the MSP_WP command, which is used by WinGUI to display and log Home and Poshold positions

    //#define DONT_RESET_HOME_AT_ARM             // HOME position is reset at every arm, uncomment it to prohibit it (you can set home position with GyroCalibration)

    /* GPS navigation can control the heading */
    
    #define NAV_CONTROLS_HEADING       true      // copter faces toward the navigation point, maghold must be enabled for it
    #define NAV_TAIL_FIRST             false     // true - copter comes in with tail first 
    #define NAV_SET_TAKEOFF_HEADING    true      // true - when copter arrives to home position it rotates it's head to takeoff direction
    
    
    /* Get your magnetic decliniation from here : http://magnetic-declination.com/
       Convert the degree+minutes into decimal degree by ==> degree+minutes*(1/60)
       Note the sign on declination it could be negative or positive (WEST or EAST) */
    //#define MAG_DECLINIATION  3.96f              //For Budapest Hungary.
    #define MAG_DECLINIATION  1.68f

    #define GPS_LEAD_FILTER                      // Adds a forward predictive filterig to compensate gps lag. Code based on Jason Short's lead filter implementation
    
    //#define GPS_FILTERING                        // add a 5 element moving average filter to GPS coordinates, helps eliminate gps noise but adds latency comment out to disable
    #define GPS_WP_RADIUS              200       // if we are within this distance to a waypoint then we consider it reached (distance is in cm)
    #define NAV_SLEW_RATE              30        // Adds a rate control to nav output, will smoothen out nav angle spikes

Hamburger · Post by **Hamburger** » Fri Feb 22, 2013 10:30 pm

Ok good.
I saw a factor 10 difference between mtk.binary16 and mtk.bi ary19 in eosbandi code.
Since you have ublox this exact reference does not apply but he also says to not trust documentation and applies factor 10 after looking at real data.
So chances are this same effect may be true for other gps devices and configs too.
What a nightmare! In the end we will end up with either multiple cases or we simply drop the decimal point alltogether.
Then I am for second alternative.

Deet · Post by **Deet** » Sat Feb 23, 2013 12:31 am

Is anyone addressing the compiled size issue? Pointless having the telemetry and the GPS if compiling the two means the code is too big for a mega328

copterrichie · Post by **copterrichie** » Sat Feb 23, 2013 12:36 am

Hambuger, can you post a sample config.h file with the telemetry enable please?

P.S. Is it possible to still use the GUI with the Telemetry enabled? I understand if there is a bluetooth device connected, it will have to be removed on a Promini first.

Hamburger · Post by **Hamburger** » Sat Feb 23, 2013 1:08 am

Deet wrote:Is anyone addressing the compiled size issue? Pointless having the telemetry and the GPS if compiling the two means the code is too big for a mega328

I cannot speak for gps.
For telemetry I added dedicated suppress.xyz options to exclude unwanted pages.
You caN also suppress the. Msp handling code if you do config via serial/i2c display instead of gui.

Hamburger · Post by **Hamburger** » Sat Feb 23, 2013 1:11 am

copterrichie wrote:Hambuger, can you post a sample config.h file with the telemetry enable please?

P.S. Is it possible to still use the GUI with the Telemetry enabled? I understand if there is a bluetooth device connected, it will have to be removed on a Promini first.

Can post code next week.
Yes with. Mega can even run telemetry and gui at same time now

Alexinparis · Post by **Alexinparis** » Sat Feb 23, 2013 1:20 am

Mystic3D wrote:Cannot Disable
#define AP_MODE 40 // Create a deadspan for GPS.

Fix:
Change this:
if (rcOptions[BOXGPSHOLD] && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE) {
To this:
if (rcOptions[BOXGPSHOLD]
#if defined(AP_MODE)
&& abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE
#endif
) {

This is not my code, thanks to nadrian

or just set it to a high value, the result is the same

Alexinparis · Post by **Alexinparis** » Sat Feb 23, 2013 1:24 am

Peter wrote:I'm repeating myself from: viewtopic.php?f=8&t=3099&start=10

Peter wrote:I tested 1342 and the previous dev versions on a plane and a quad x.
The plane has a drotek 10dof with a ms5611 and minim osd and the quad a modified wii gyro, bma180, bmp085, hmc5883, i2c-gps, oled display, bluetooth. Both Pro mini.
I fly with FrSky combined ppm. One at 27ms and the other default.

Both setups have the same problem. They can arm 50% of the time. The problem is that the cycle times go through the roof (negative values).
Looks like a cycle time of a couple of seconds. The plane can sometimes arm, but the controls almost do not work, one change of the servos per 2 seconds.
Power disconnect and reconnect and the problem is solved sometimes. Been flying with the quad for 2 years on 1.9,2.0 and 2.1 without problems.
But the oled display and i2c-gps are relatively new.

Is this a known problem?

Failsave is not compiled in. Yesterday I tested again and got the problem only briefly, after a couple of times arming it worked.

I don't think it's a known problem. I don't remember having such a problem with my setups. I will try to reproduce this arm issue.

Alexinparis · Post by **Alexinparis** » Sat Feb 23, 2013 1:26 am

Stars112 wrote:IS the SERIAL3W LCD in Work with the 32u4?
In one of the first DEVS (1317) it dosent work.

It should work, with serial signal on PIN 4 according to the code.

Alexinparis · Post by **Alexinparis** » Sat Feb 23, 2013 1:43 am

Hamburger wrote:Ok good.
I saw a factor 10 difference between mtk.binary16 and mtk.bi ary19 in eosbandi code.
Since you have ublox this exact reference does not apply but he also says to not trust documentation and applies factor 10 after looking at real data.
So chances are this same effect may be true for other gps devices and configs too.
What a nightmare! In the end we will end up with either multiple cases or we simply drop the decimal point alltogether.
Then I am for second alternative.

for mtk I don't know, but for NMEA and UBLOX the GPS coordinates are uniform in all cases: 1 unit = 1/10 000 000 deg

Hamburger · Post by **Hamburger** » Sat Feb 23, 2013 9:43 am

Ok. So I will just copy the code from mbrak. Thanks for confirmation.

rbirdie001 · Post by **rbirdie001** » Sat Feb 23, 2013 4:28 pm

Hi,
probably already reported, but for sure:
I can't make SERVO_MIX_TILT working on 2.2 pre.

I tried to comment //#define TILT_PITCH_AUX_CH AUX3 and //#define TILT_ROLL_AUX_CH AUX4 but still not work.
Pure 2.2 pre, no patches.
Additional question:
Is the MIXING of CAM stabilization with the AUX channel input available, or just overwrite?
Thanks!
Roman

Edit: I don't understand the code, but when part of Output.ino is replaced with the code from the post below, it works!
viewtopic.php?f=8&t=3079
Roman

Mystic3D · Post by **Mystic3D** » Sun Feb 24, 2013 3:27 pm

Mystic3D wrote:Cannot Disable
#define AP_MODE 40 // Create a deadspan for GPS.

Fix:
Change this:
if (rcOptions[BOXGPSHOLD] && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE) {
To this:
if (rcOptions[BOXGPSHOLD]
#if defined(AP_MODE)
&& abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE
#endif
) {

This is not my code, thanks to nadrian

No joy here?

If we just want pos hold to just lock, we should be able to disable..?

Deet · Post by **Deet** » Sun Feb 24, 2013 10:44 pm

Mystic3D wrote:
Mystic3D wrote:Cannot Disable
#define AP_MODE 40 // Create a deadspan for GPS.

Fix:
Change this:
if (rcOptions[BOXGPSHOLD] && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE) {
To this:
if (rcOptions[BOXGPSHOLD]
#if defined(AP_MODE)
&& abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE
#endif
) {

This is not my code, thanks to nadrian

No joy here?

If we just want pos hold to just lock, we should be able to disable..?

NO, that is a deadband for the radio, it means that if you bump the sticks, the baord wont try and move the airframe to keep up, this code makes it more locked in

PatrikE · Post by **PatrikE** » Mon Feb 25, 2013 12:01 pm

The function is...

When PosHold and AP_MODE is enabled.
And the Roll/Nick command is greater than AP_MODE.
Poshold is disabled temporarily.

When Roll/Nick command returns within AP_MODE range.
Poshold is reactivated and a NEW Pos to hold is taken.

In plain words...
With AP_MODE
Move the copter with TX to a new position that it should hold !

Without AP_MODE.
Move the copter with the TX and it should return to the original position.

Stars112 · Post by **Stars112** » Mon Feb 25, 2013 12:31 pm

Stars112 wrote:
IS the SERIAL3W LCD in Work with the 32u4?
In one of the first DEVS (1317) it dosent work.
It should work, with serial signal on PIN 4 according to the code.

Thanks Alex for your answer.
But... The Pin4 is the D+ Pin from USB (Serial0). And in most configuration connect with USB.
Can we use the Serial1 from the 32U4 at Pin 20-RX/21-TX?

Peter · Post by **Peter** » Mon Feb 25, 2013 7:22 pm

Alexinparis wrote:I don't think it's a known problem. I don't remember having such a problem with my setups. I will try to reproduce this arm issue.

I upgraded my quad to r1349 and I haven't seen the problem again. Will test further, trying endpoint adjustment and my plane.

Mystic3D · Post by **Mystic3D** » Mon Feb 25, 2013 7:44 pm

PatrikE wrote:The function is...

When PosHold and AP_MODE is enabled.
And the Roll/Nick command is greater than AP_MODE.
Poshold is disabled temporarily.

When Roll/Nick command returns within AP_MODE range.
Poshold is reactivated and a NEW Pos to hold is taken.

In plain words...
With AP_MODE
Move the copter with TX to a new position that it should hold !

Without AP_MODE.
Move the copter with the TX and it should return to the original position.

Thanks, I know what the function does, I use the code I posted to disable it.
Was advocating it be in 2.2, but that's not my decision..

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 2:30 am

There appears to be a bug in the MPU6050 code that introduces an error on the Pitch axis, details are posted here: viewtopic.php?f=17&t=2934&start=10

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 6:03 am

copterrichie wrote:There appears to be a bug in the MPU6050 code that introduces an error on the Pitch axis, details are posted here: viewtopic.php?f=17&t=2934&start=10

Here is the fix, 2's Complement.

Code: Select all

void ACC_getADC () {
  i2c_getSixRawADC(MPU6050_ADDRESS, 0x3B);
  ACC_ORIENTATION( ((int8_t(rawADC[0])<<8) | int8_t(rawADC[1]))/8 ,
                   ((int8_t(rawADC[2])<<8) | int8_t(rawADC[3]))/8 ,
                   ((int8_t(rawADC[4])<<8) | int8_t(rawADC[5]))/8 );
  ACC_Common();
}

Hamburger · Post by **Hamburger** » Tue Feb 26, 2013 1:50 pm

Is it about the casts or about replacing the '>>3' with '/8'?
Anyone to confirm this fix? I would like to copy this and other tidbits into the dev tree.
Would not the same have to be applied for the gyro?

rawADC is uint8_t; accADC from the ACC_ORIENTATION macro is int16_t. I do not understand why either the casts or the division should make a difference - but then I am not a bitbanging developer. Anyone care to explain, please?

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 1:56 pm

I have tried my hardest to explain this in the past without success, this is the best I can do: http://en.wikipedia.org/wiki/2%27s_complement

AndrejLV · Post by **AndrejLV** » Tue Feb 26, 2013 2:29 pm

What is a source of constant drift if the bare board are placed on a table with disconnected motors? Arm the "motors", add throttle and we can observe slow constant decreasing of output magnitude on Rear L motor in time. In one two minutes it diverse with another motors ~100 sometimes.

- motors not connected, so it not linked to vibration
- it not depends on board orientation, so it not the problem of earth rotation.
- it not depends on rc sticks centre shift, DEADBAND 100 not eliminate this problem
- stable temperature and enviroment ..
- it present in all my boards, Crius and Nanowii, all with mpu6050.

Is it native sensor drift or software processing?

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 4:46 pm

What I am discovering at this point here with the ACCs and Gryos that I own is, The Gyros report their data as unsigned where as the Accs are Two's Complement. The MWC reads both as the same in the I2C routine. Which is fine until the casing, the 8th bit is the sign in Two's Complement and is lost when casing.

Hamburger · Post by **Hamburger** » Tue Feb 26, 2013 4:52 pm

copterrichie wrote:I have tried my hardest to explain this in the past without success, this is the best I can do: http://en.wikipedia.org/wiki/2%27s_complement

so from your somewhat cryptic answer I take it that rawADC (raw value returned from sensor) is in two's complement?
Also, doing either the division by 8 or the shifting thing makes no difference?

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 4:55 pm

Hamburger wrote:so from your somewhat cryptic answer I take it that rawADC (raw value returned from sensor) is in two's complement?
Also, doing either the division by 8 or the shifting thing makes no difference?

I would suggest not confusing the divide by 8, that is just to reduce the value I suspect to limit the noise.

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 5:07 pm

Here are two segments from the datasheet on the MPU6050, note the Acc segment states Two's Complement where the Gyro segment does not. I have found this to be true with the BMA180 and the LSM303DLHC

Hamburger · Post by **Hamburger** » Tue Feb 26, 2013 5:08 pm

for playing around with some values for the two conflicting implementations:

Code: Select all

// experiment - try to find example values, for which the two implementations
// of acc codes would produce different results
void setup() {
   int n = 0;
   static int16_t r1, r2;
   Serial.begin(115200);
   for (uint8_t i=0; i< 255; i++) { // emulate rawADC[2]
      for (uint8_t j=0; j<255; j++) { // emulate rawADC[3]
         r1 = ((i<<8) | j)>>3 ;                  // ((rawADC[2]<<8) | rawADC[3])>>3 
         r2 =  ((int8_t(i)<<8) | int8_t(j))>>3;   // ((int8_t(rawADC[2])<<8) | int8_t(rawADC[3]))/8
         // or try this:
         //r1 = i<<8;
         //r2 = (int8_t(i)<<8); // no difference with these 
         // or try this:
         //r1 = (i<<8) | j;
         //r2 = ( (int8_t(i)<<8) | int8_t(j) );     // difference if highest bit of j is set
         if (r1 != r2) {
            Serial.print(i, DEC); Serial.print(' '); Serial.print(j, DEC); Serial.print(" : ");
            Serial.print(i, BIN); Serial.print(' '); Serial.print(j, BIN); Serial.print(" : ");
            Serial.print(r1, BIN); Serial.print(' '); Serial.print(r2, BIN); 
            Serial.print("\n");
            n++;
         }
      }
   }
   Serial.print("\n== end == count of different results : "); Serial.print(n);
   Serial.print("\n");
}

void loop() {
}

what this boils down to, we need someone with access and understanding of the documentation of mpu6050 and check with the description of what the returned bytes are supposed to be. C. - you just beat me by a mere seconds

Sebbi · Post by **Sebbi** » Tue Feb 26, 2013 6:01 pm

Whether it is 2-compliment or not doesn't matter in this case. Why? Because there is a bias calculated as the zero-value and subtracted from every acc measurement. The original problem (pitch moves when roll is greater than x degrees) comes from the atan functions calculating the actual degrees which do not work correctly .... which is a known bug, but nobody seems to care.

Code: Select all

  angle[ROLL]  =  _atan2(EstG.V.X , EstG.V.Z) ;
  angle[PITCH] =  _atan2(EstG.V.Y , EstG.V.Z) ;

This causes the problem ...

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 6:06 pm

Sebbi wrote:Whether it is 2-compliment or not doesn't matter in this case. Why? Because there is a bias calculated as the zero-value and subtracted from every acc measurement. The original problem (pitch moves when roll is greater than x degrees) comes from the atan functions calculating the actual degrees which do not work correctly .... which is a known bug, but nobody seems to care.
Code: Select all
  angle[ROLL]  =  _atan2(EstG.V.X , EstG.V.Z) ;
  angle[PITCH] =  _atan2(EstG.V.Y , EstG.V.Z) ;
This causes the problem ...

I think it is a compounded problem that has existed for sometime now.

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Tue Feb 26, 2013 6:40 pm

Hamburger wrote:Is it about the casts or about replacing the '>>3' with '/8'?
Anyone to confirm this fix? I would like to copy this and other tidbits into the dev tree.
Would not the same have to be applied for the gyro?

rawADC is uint8_t; accADC from the ACC_ORIENTATION macro is int16_t. I do not understand why either the casts or the division should make a difference - but then I am not a bitbanging developer. Anyone care to explain, please?

copterrichie wrote:I have tried my hardest to explain this in the past without success, this is the best I can do: http://en.wikipedia.org/wiki/2%27s_complement

Hi,

this is not a cast! 'x >> 3' is a simple bitshift-right operation. Here's a little example:

int i = 12;
The value i = 12 = 0b0000 1100

i >> 2;
The value i = 3 = 0b0000 0011

So, bitshift-right is a divison by a power of two --> bit-shift right by n equals a division by 2^n.

int i = 72;
i >> 3; // division by 8 (2*3) --> i = 9;

Bit-shift left equals a multiplication by a power of two:
int i = 3; // 0b0000 0011
i << 2; // i = 12 = 0b0000 1100

Bit-shift right or bit-shift left are much faster - when talking about total CPU clock cycles consumed to complete the operation - than a division/multiplication --> whenever you need to divide/multiply by a power of two one should use bit-shift operations!
Some MCUs have barrel-shifters for doing such tasks in one CPU clock cycle (when divide/multiply consumes some hundreds).

aBUGSworstnightmare

Sebbi · Post by **Sebbi** » Tue Feb 26, 2013 6:45 pm

http://invensense.com/mems/gyro/documen ... -6000A.pdf states that Gyro values are also 2-compliment ... (page 32 of 47). Which is expected, since it is also a signed value like the acc-values ;-)

btw: ">>3" wasn't in the code before ... the /8 should be enough to fix the signed/unsigned issue (but shifting should be the same as dividing for 2-complements hmm). Debusal introduced these changes as "small optimisations" in r1343 according to git-blame

copterrichie · Post by **copterrichie** » Tue Feb 26, 2013 6:47 pm

Here is the root of the problem, the bitwise shifting compounds the issue. 1111 1111 in Two's Complement is -1 where is in Unsigned, it is 255.