MultiWii 1.9

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

MultiWii 1.9

Post by Alexinparis »

Hi

Finally, it's here ;)
http://code.google.com/p/multiwii/downloads/list

changes:

Code: Select all

1.8 -> 1.9
    - some factorizations between PPM sum receiver code & standard receiver code
    - EXPERIMENTAL: integration of direct SBUS receiver thanks to the contribution of Captain IxI & Zaggo
      For this, you must use:
         - a MEGA board
         - the RX1 of the Serial 1 port
         - have a way to invert the input signal.
      more info here: http://www.multiwii.com/forum/viewtopic.php?f=7&t=289
    - EXPERIMENTAL: integration of SPEKTRUM satellite receiver thanks to the contribution of Danal Estes
      For this, you must use:
         - a MEGA board
         - the RX1 of the Serial 1 port
      It could be used also on ProMini board with some restrictions (exclusive GUI or Spektrum use)
      more info here: http://www.rcgroups.com/forums/showthread.php?t=1504116
    - EXPERIMENTAL: integration of direct Serial RX, to command the multi from a Bluetooth+phone Signal for instance.
      thanks to Luis
    - many optimizations to reduce loop cycle
    - GPS main function integration
        The code to connect and recognize a GPS with NMEA sentences is here.
        currently calculated:
          - number of sat
          - distance to home
          - direction to home
   The is currently to control code except a nice working GUI
   => there is no code behind GPS HOME and GPS HOLD, in progress
    - PIN A0 and A1 instead of PIN D5 & D6 for 6 motors config and promini config
      This mod allow the use of a standard receiver on a pro mini
      (no need to use a PPM sum receiver)
      #define A0_A1_PIN_HEX
    - possibility to use PIN8 or PIN12 as the AUX2 RC input
      it deactivates in this case the POWER PIN (pin 12) or the BUZZER PIN (pin 8)
      #define RCAUXPIN8 or #define RCAUXPIN12
    - thanks to Danal, integration of the Eagle Tree Power Panel LCD for configuration
      it's an I2C LCD that should be very convenient for the ProMini because it doesn't require the unique Serial Port
    - all in one FC:
      QUADRINO_ZOOM board integration
      MINIWII : Jussi's MiniWii Flight Controller
    - sensor boards:
      SIRIUS600       // Sirius Navigator IMU  using the WMP for the gyro
      CITRUSv1_0      // CITRUSv1 from qcrc.ca
      DROTEK_IMU10DOF
    - ATAVRSBIN1 mag direction correction (http://www.multiwii.com/forum/viewtopic.php?f=8&t=506&start=60#p4950)
    - no need to define anymore PROMINI or MEGA in the sketch:
      this information is grabed form the board selection in Arduino IDE
    - LEVEL drift problem:
      the root of this problem was identify (at least partly).
      Several options to try to solve it:
      - adding a #define TRUSTED_ACCZ for those who have huge ACC Z variations when some throttle is applied
        (it's a test you should do before tructing ACCZ)
   //#define TRUSTED_ACCZ  -> ACCZ is not taken into account in calculation for small angles
   #define TRUSTED_ACCZ    -> ACCZ is taken into account in calculation for small angles
      - BMA180 init changes to another mode: should help to filter noisy setups
      - adding a #define STAB_OLD_17 for those who still encounter problem with the stable code,
        as the old 1.7 LEVEL code (less elaborated) doesn't seem to cause drift.
     - some flying wing code upgrade (thanks to the suggestion of Hamburger)
     - ACC added: LSM303DLx_ACC


I hope there are not a lot of remaining bugs.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 1.9

Post by timecop »

let's see what the diff between 20111029 and this looks like :)
hopefully most of my work is already done.

User avatar
LuisFCorreia
Posts: 32
Joined: Sat Oct 01, 2011 7:04 pm
Location: Portugal
Contact:

Re: MultiWii 1.9

Post by LuisFCorreia »

Strange...

I see that now, for some strange reason, the LED keeps blinking and nothing shows up in the GUI.

I've got an Arduino Mini with an Atmel 328 (requires a special setup in the boards.txt file).
Did you by any chance mixed up the I2C pin assignments?

Will check back tomorrow for answers.

Great job, and thanks for inclunig my preliminary code ;)

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 1.9

Post by timecop »

Code: Select all


  //PITCH & ROLL only dynamic PID adjustemnt,  depending on throttle value
  if      (rcData[THROTTLE]<1500) prop2 = 100;
  else if (rcData[THROTTLE]<2000) prop2 = 100 - (uint16_t)dynThrPID*(rcData[THROTTLE]-1500)/500;
  else                            prop2 = 100 - dynThrPID;


I'm just being style police here, but this is really confusing.
depending on what you want to happen it might actually be incorrect.

my understanding is:

Code: Select all

    if (rcData[THROTTLE] < 1500) {
   prop2 = 100;
    } else {
   if (rcData[THROTTLE] < 2000) {
       prop2 = 100 - (uint16_t) dynThrPID *(rcData[THROTTLE] - 1500) / 500;
   } else {
       prop2 = 100 - dynThrPID;
   }
    }

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

A big thank you to Alex and all the contributors for V1.9. Much appreciated!

I installed it and everything appeared to be dead (model did not arm, GUI inactive, etc.). I searched around and found a couple new posts on RCGroups that reported identical symptoms on V1.9 upgrades. I did some debugging and discovered that the issue was caused by waitTransmissionI2C() in sensors.pde.

I found that the while{} does not have a hard exit and so it becomes an endless loop. I added a break statement to force an exit if the timeout occurs. I also found that the timeout time was much too long and adversely affected the GUI cycle time (whenever a timeout was detected).

Here is the work-around code I am using that prevents the "dead" board symptom (not fully tested: model works on the bench, too dark to fly tonight):

Code: Select all

void waitTransmissionI2C() {
  uint16_t count = 100;           // Timeout time. This value may need to be much larger on some installations.
  while (!(TWCR & (1<<TWINT))) {
    count--;
    if (count==0) {               //we are in a blocking state => we don't insist
      TWCR = 0;                   //and we force a reset on TWINT register
      neutralizeTime = micros();  //we take a timestamp here to neutralize the value during a short delay after the hard reset
      break;                      // Timeout, Abort!
    }
  }
}


I recognize that the real problem is that an I2C transmission is not sensing a device response (typically not a good thing). When I have more free time this week I will find which I2C device is involved in the timeout. In case you want to check the code for possible trouble spots, here is a list of my I2C sensors:
ITG3200
BMA180
BMP085
HMC5883

BTW, I know its not the BMP085 because I've already commented it out. So its one of the other fellows. :)

whowe
Posts: 12
Joined: Thu Oct 20, 2011 4:04 am

Re: MultiWii 1.9

Post by whowe »

dongs wrote:

Code: Select all


  //PITCH & ROLL only dynamic PID adjustemnt,  depending on throttle value
  if      (rcData[THROTTLE]<1500) prop2 = 100;
  else if (rcData[THROTTLE]<2000) prop2 = 100 - (uint16_t)dynThrPID*(rcData[THROTTLE]-1500)/500;
  else                            prop2 = 100 - dynThrPID;


I'm just being style police here, but this is really confusing.
depending on what you want to happen it might actually be incorrect.

my understanding is:

Code: Select all

    if (rcData[THROTTLE] < 1500) {
   prop2 = 100;
    } else {
   if (rcData[THROTTLE] < 2000) {
       prop2 = 100 - (uint16_t) dynThrPID *(rcData[THROTTLE] - 1500) / 500;
   } else {
       prop2 = 100 - dynThrPID;
   }
    }



"else if" is very classic one to make things like this simpler. It's not confusing. In some other languages even there is keyword named "elseif".

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 1.9

Post by timecop »

It's the lack of { }'s that is confusing, especially considering the 2nd case is all inside the 1st if.
And you just proved my point of it being confusing.

1.9 is flying great on default settings, just doubled pitch/roll P (so its at 8)
http://www.youtube.com/watch?v=uRR74gfMIJA

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: MultiWii 1.9

Post by ziss_dm »

Hi timecop,

And what is ESC32? ;)

Regards,
ziss_dm

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

Re: MultiWii 1.9

Post by Alexinparis »

mr.rc-cam wrote:A big thank you to Alex and all the contributors for V1.9. Much appreciated!

I installed it and everything appeared to be dead (model did not arm, GUI inactive, etc.). I searched around and found a couple new posts on RCGroups that reported identical symptoms on V1.9 upgrades. I did some debugging and discovered that the issue was caused by waitTransmissionI2C() in sensors.pde.

I found that the while{} does not have a hard exit and so it becomes an endless loop. I added a break statement to force an exit if the timeout occurs. I also found that the timeout time was much too long and adversely affected the GUI cycle time (whenever a timeout was detected).

Here is the work-around code I am using that prevents the "dead" board symptom (not fully tested: model works on the bench, too dark to fly tonight):

Code: Select all

void waitTransmissionI2C() {
  uint16_t count = 100;           // Timeout time. This value may need to be much larger on some installations.
  while (!(TWCR & (1<<TWINT))) {
    count--;
    if (count==0) {               //we are in a blocking state => we don't insist
      TWCR = 0;                   //and we force a reset on TWINT register
      neutralizeTime = micros();  //we take a timestamp here to neutralize the value during a short delay after the hard reset
      break;                      // Timeout, Abort!
    }
  }
}


I recognize that the real problem is that an I2C transmission is not sensing a device response (typically not a good thing). When I have more free time this week I will find which I2C device is involved in the timeout. In case you want to check the code for possible trouble spots, here is a list of my I2C sensors:
ITG3200
BMA180
BMP085
HMC5883

BTW, I know its not the BMP085 because I've already commented it out. So its one of the other fellows. :)


Hi I think you get it.
I've just re uploaded the 1.9 with the right correction.
Sorry for the confusion.
I knew I shouldn't have changed something that worked ;)

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: MultiWii 1.9

Post by ziss_dm »

Hi Alex,

Maybe we should have pre-releases? Worked well with 1.7. ;)

regards,
ziss_dm

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

Re: MultiWii 1.9

Post by Alexinparis »

ziss_dm wrote:Hi Alex,

Maybe we should have pre-releases? Worked well with 1.7. ;)

regards,
ziss_dm


Hi,
I was maybe a little bit impatient ;)
With pre releases, there was some confusion between the final 1.7 and some pre, that's why I tried the approach:
dev -> official release -> patchs.

drotek
Posts: 4
Joined: Thu Nov 03, 2011 7:27 pm

Re: MultiWii 1.9

Post by drotek »

Thank you Alex for the integration of our code of imu 10DOF. ;)

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 1.9

Post by timecop »

ziss_dm wrote:Hi timecop,

And what is ESC32? ;)

Regards,
ziss_dm

Its a 32-bit esc. :)
high speed refresh and 16/20khz PWM freq.
There is a brief mention of it in my rcgroups blogue.

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

Re: MultiWii 1.9

Post by tovrin »

Image

after uploading 1.9, this is what i get when i turn on stable mode with motors off sitting on a level surface, turn it off and it goes flat.

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

Re: MultiWii 1.9

Post by copterrichie »

tovrin wrote:
after uploading 1.9, this is what i get when i turn on stable mode with motors off sitting on a level surface, turn it off and it goes flat.


What does it look like if you enable the following?

Code: Select all

/* This option is here if you want to use the old level code from the verison 1.7
   It's just to have some feedback. This will be removed in the future */
//#define STAB_OLD_17

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

Re: MultiWii 1.9

Post by tovrin »

will check it out when i get home from work tonight.

oterpoter
Posts: 61
Joined: Sat Nov 05, 2011 2:11 am

Re: MultiWii 1.9

Post by oterpoter »

Possibly a VERY dumb post but how do one install this? Ihave been googling and scouting around this forum to find out HOW i can upload modified configs, and now upgrade my 1.7 version board to this 1.9..

I have downloaded ardinuo, and processing..
I have downloaded the multiwii gui..
Using thebmultiwii gui for ver 1.7 works when I hook my quad to the usb..
Bøut I need to alter the MINTHROTTLE value..
And here my knowledge stops..
I can open the multiwii 1.7 file in Ardinuo..
I can change the value.. But then what?
I find no explanation on how I should upload this new settings to the card.
I have "compiled" the edited version in ardunio, and it appears to do so without problems..
But what exactly dows it do when it has compiled?
A new .pde file? Should this replace the old one, and GUI started with the usb connected?
Should usb be connected while I compile?
I have NO clue, and hopefullynsome of you brighter fellas would like to explain it to me like I am A 12 year old!
Also I would like to try the 1.9 version, but my guess is that the procesure for uploading/installing this version to my board is somewhat the same.
I am no programmer so please be a bit "multiwii for dummies!" here
I am most certainnalot of people like me would like to be able to take part in this quadro/multicopter wonderworld, but lack the knowledge to do so without a proper guidance!
Thanx!
Best regards

Mathias

zviratko
Posts: 50
Joined: Sat Oct 15, 2011 4:49 pm

Re: MultiWii 1.9

Post by zviratko »

oterpoter: in the arduino ide (arduino 22...), you open the .pde (in case of 1.7 the single .pde there is), make the changes and then there is a button at the top that says "Upload" (second from the right). You need to quit GUI for upload to work, the sketch will be compiled (and validated), uploaded, arduino will reset and all is done. After that you need to re-tune your PIDs and check that everything works.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: MultiWii 1.9

Post by jevermeister »

tovrin wrote:Image

after uploading 1.9, this is what i get when i turn on stable mode with motors off sitting on a level surface, turn it off and it goes flat.


Hi Alex, hi guys,

first off: Thank you for your work, I was very looking forward to the release and jsut tested it in the basement. So there might be some ground effect spoiling the result.

My setup was as follows: A very stable copter with the latest 20111029 dev version flying perfectly.
QuadX, Flyduino V2.1, BMA020, Genuine WM+, BMP085, HMC5883L, Quektel GPS, 2,4GHz HK T6a , HK SS18A ESC, eMax CF2822

1. I did a short test with the latest 20111029 dev before installing the new firmware: Everything works finde
2. New Firmware, same parameter setup, same hardware setup, just minutes after the last flight, same lipo: the copter twichtes in stable mode, every now and then there is a twitch and I have to make a manual recover move.
3. Reinstalled the 20111029 dev version and everything si normal again.

Here is a short video of the twitching, with a very noticeable hickup at 0:23 (I hope it helps):

http://www.youtube.com/watch?v=Z3Sa03zDnok
I used the fixed version you uploaded later today.

Nils

zviratko
Posts: 50
Joined: Sat Oct 15, 2011 4:49 pm

Re: MultiWii 1.9

Post by zviratko »

jevermeister: does your GUI "freeze" when you have the battery connected and receiver on? I did a quick test with 1.9 and saw something similiar, almost looked like something reset while armed (no spike on ACC, just a quick freeze) - cycle time also varies more with 1.9 than with the dev version (2500-3700 from what I can see), this may be the cause of your problem. Shot in the dark - if you have 400kHz I2C, try lowering it to 100kHz...
My setup is similiar is almost the same as yours when it comes to sensors (BMA180 here).

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

Re: MultiWii 1.9

Post by Alexinparis »

jevermeister wrote:
tovrin wrote:Image

after uploading 1.9, this is what i get when i turn on stable mode with motors off sitting on a level surface, turn it off and it goes flat.


Hi Alex, hi guys,

first off: Thank you for your work, I was very looking forward to the release and jsut tested it in the basement. So there might be some ground effect spoiling the result.

My setup was as follows: A very stable copter with the latest 20111029 dev version flying perfectly.
QuadX, Flyduino V2.1, BMA020, Genuine WM+, BMP085, HMC5883L, Quektel GPS, 2,4GHz HK T6a , HK SS18A ESC, eMax CF2822

1. I did a short test with the latest 20111029 dev before installing the new firmware: Everything works finde
2. New Firmware, same parameter setup, same hardware setup, just minutes after the last flight, same lipo: the copter twichtes in stable mode, every now and then there is a twitch and I have to make a manual recover move.
3. Reinstalled the 20111029 dev version and everything si normal again.

Here is a short video of the twitching, with a very noticeable hickup at 0:23 (I hope it helps):

http://www.youtube.com/watch?v=Z3Sa03zDnok
I used the fixed version you uploaded later today.

Nils


Hi,
another wrong change on my side...
in IMU.pde

Code: Select all

  uint32_t timeInterleave = 0;

= >

Code: Select all

  static uint32_t timeInterleave = 0;


And this should work.
the reason: timeInterleave must be declared as static in order to memorize the right time for interleaving reading WMP/NK/WMP/NK/....
without this, the interleaving delay is wrong and too short.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: MultiWii 1.9

Post by jevermeister »

I tested that but I am afraid that does not work, stillt twitches, might be even worse.

Sorry...

Nils

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

Re: MultiWii 1.9

Post by mahowik »

jevermeister wrote:I tested that but I am afraid that does not work, stillt twitches, might be even worse.


I see the changes in I2C driver there. Probably it's a reason of this issue...

from MultiWii_1_9:

Code: Select all

void waitTransmissionI2C() {
  uint16_t count = 255;
  while (!(TWCR & (1<<TWINT))) {
    count--;
    if (count==0) { //we are in a blocking state => we don't insist
      TWCR = 0;  //and we force a reset on TWINT register
      neutralizeTime = micros(); //we take a timestamp here to neutralize the value during a short delay after the hard reset
      break;
    }
  }
}


from MultiWii_dev_20111029:

Code: Select all

void waitTransmissionI2C() {
  uint8_t count = 255;
  while (count-->0 && !(TWCR & (1<<TWINT)) );
  if (count<2) { //we are in a blocking state => we don't insist
    TWCR = 0;  //and we force a reset on TWINT register
    neutralizeTime = micros(); //we take a timestamp here to neutralize the value during a short delay after the hard reset
  }
}


you can try to use the waitTransmissionI2C() from MultiWii_dev_20111029...

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

Re: MultiWii 1.9

Post by tovrin »

I tried the old stab, with no difference, i then added the static remark and my 'noise' went away. thanks Alex

Tifani
Posts: 63
Joined: Sun Nov 06, 2011 5:15 pm

Re: MultiWii 1.9

Post by Tifani »

Hi !
I have similar spikes (dev.20111029 and dev.20111008 also) on my Tri with ProMini 16Mhz5v with genuine WM+ & Nunchuk but I tested v.1.9 with Arduino Uno with the same sensors (other set) no RX no ESC+Motors and .... NO SPIKES ???
Tom

whowe
Posts: 12
Joined: Thu Oct 20, 2011 4:04 am

Re: MultiWii 1.9

Post by whowe »

Alexinparis wrote:
jevermeister wrote:
tovrin wrote:Image

after uploading 1.9, this is what i get when i turn on stable mode with motors off sitting on a level surface, turn it off and it goes flat.


Hi Alex, hi guys,

first off: Thank you for your work, I was very looking forward to the release and jsut tested it in the basement. So there might be some ground effect spoiling the result.

My setup was as follows: A very stable copter with the latest 20111029 dev version flying perfectly.
QuadX, Flyduino V2.1, BMA020, Genuine WM+, BMP085, HMC5883L, Quektel GPS, 2,4GHz HK T6a , HK SS18A ESC, eMax CF2822

1. I did a short test with the latest 20111029 dev before installing the new firmware: Everything works finde
2. New Firmware, same parameter setup, same hardware setup, just minutes after the last flight, same lipo: the copter twichtes in stable mode, every now and then there is a twitch and I have to make a manual recover move.
3. Reinstalled the 20111029 dev version and everything si normal again.

Here is a short video of the twitching, with a very noticeable hickup at 0:23 (I hope it helps):

http://www.youtube.com/watch?v=Z3Sa03zDnok
I used the fixed version you uploaded later today.

Nils


Hi,
another wrong change on my side...
in IMU.pde

Code: Select all

  uint32_t timeInterleave = 0;

= >

Code: Select all

  static uint32_t timeInterleave = 0;


And this should work.
the reason: timeInterleave must be declared as static in order to memorize the right time for interleaving reading WMP/NK/WMP/NK/....
without this, the interleaving delay is wrong and too short.



Hi Alex, does this mean if I always fly with Level turned on it will drift when taking off?
Actually that is what I got from dev 20111029 and this 1.9: drift a lot and even not possible to control when taking off.
I'm using a 500mm frame and 9DOF+baro (#define QUADUINO) which was very stable with 1.8p2.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

mr.rc-cam wrote:Here is the work-around code I am using that prevents the "dead" board symptom (not fully tested: model works on the bench, too dark to fly tonight):

Code: Select all

void waitTransmissionI2C() {
  uint16_t count = 100;           // Timeout time. This value may need to be much larger on some installations.
  while (!(TWCR & (1<<TWINT))) {
    count--;
    if (count==0) {               //we are in a blocking state => we don't insist
      TWCR = 0;                   //and we force a reset on TWINT register
      neutralizeTime = micros();  //we take a timestamp here to neutralize the value during a short delay after the hard reset
      break;                      // Timeout, Abort!
    }
  }
}


I recognize that the real problem is that an I2C transmission is not sensing a device response (typically not a good thing). When I have more free time this week I will find which I2C device is involved in the timeout.


Updates:

(1) Early this morning I flew with the modified code I posted yesterday and everything worked fine. So far V1.9 is working for me now. ACC Level mode felt different than V1.8P2, but not in a bad way. So no complaints.

(2) This evening I found the source of my I2C device response problem that caused the "dead" model condition. I commented out all the sensors except for the ITG3200 gyro (to make it easier to debug). It turned out that I2C was intermittently failing the TWINT flag test in waitTransmissionI2C(). So with the early V1.9 code this kind of event (regardless of sensor involved) would put waitTransmissionI2C() into an endless loop, which made everything appear dead. In my case it was a hardware fault; an o-scope showed that the I2c clock's (SCL) slope and amplitude were marginal. To solve this I modified the I2C's logic level shifter circuit (LLC) to obtain a more robust waveform (the SCL 5V logic side pullup was reduced from 10K to 2.2K ohms).

So the good news is that the software bug in waitTransmissionI2C() found my hardware problem, so thanks for writing the special code. :)

JussiH
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Re: MultiWii 1.9

Post by JussiH »

Alex: Thanks for your continued dedication to MultiWii development. I really appreciate that you already integrated MiniWii as a define. I will make sure you get one from the next batch...

Jussi

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

Re: MultiWii 1.9

Post by tovrin »

I'm not sure what i did, but i cant arm my motors now. I switch back to 1.82 and they arm fine.

Just to be clear, they have not armed in 1.9 at all. I adjusted my min/max to match my TX, and moved my RX pins the same as I did in 1.82.

User avatar
mgros
Posts: 90
Joined: Thu Jan 20, 2011 12:32 am

Re: MultiWii 1.9

Post by mgros »

tovrin wrote:I'm not sure what i did, but i cant arm my motors now. I switch back to 1.82 and they arm fine.

Just to be clear, they have not armed in 1.9 at all. I adjusted my min/max to match my TX, and moved my RX pins the same as I did in 1.82.


Have you calibrate ACC just after install 1.9?

cardboard
Posts: 183
Joined: Tue Mar 15, 2011 9:40 am

Re: MultiWii 1.9

Post by cardboard »

nor can i arm my copter, the status light on my promini blinks rapidly and that is it. I can trim acc mode still though if that is any consolation.
she still arms in 1.8 though

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

Re: MultiWii 1.9

Post by tovrin »

i thought acc calibrates at power on? but yes, i clicked the calibrate button, the wmp and nnchk are responding properly, as expected. my TX values are where they should be on the gui. it just wont arm

i swap out my def and config files, then load 1.82 and it arms fine.

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

Re: MultiWii 1.9

Post by Hamburger »

same here - motor of flying wing does not arm with v1.9, works ok with r336 (very short prior to release of v1.9).
it is not a pin out problem; in gui I can see there never is a motor out signal.
I think in future the GUI should provide feedback of armed/unarmed state - maybe using one of the preserved debug variables?

Tifani
Posts: 63
Joined: Sun Nov 06, 2011 5:15 pm

Re: MultiWii 1.9

Post by Tifani »

Looks like arming can be done only by aux switch (GUI white boxes) so how we can do this if aux1 is taken by level mode and we can not use aux 2 ?
Tom

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

Re: MultiWii 1.9

Post by tovrin »

cant test this till i get home, but i suppose i could use the aux1 knob and set motor armed at mid, and motors armed and acc at high, right? this still kind of sucks though.

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

Re: MultiWii 1.9

Post by shikra »

I put 1.9 on my Tricopter last night.
Not flown, hovered in my hand only.
It armed/disarmed OK....

User avatar
mgros
Posts: 90
Joined: Thu Jan 20, 2011 12:32 am

Re: MultiWii 1.9

Post by mgros »

tovrin wrote:i thought acc calibrates at power on? but yes, i clicked the calibrate button, the wmp and nnchk are responding properly, as expected. my TX values are where they should be on the gui. it just wont arm

i swap out my def and config files, then load 1.82 and it arms fine.


Gyros calibrated at startup, ACC only calibrate when you request.
Normaly it's a good practice calibrate ACC in GUI after the instalation of a new release.

How is the status led? blinking?

Remember if the quad it's not flat motors not arm, a bad value of ACC could indicate to de program that the quad it's not leveled.

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

Re: MultiWii 1.9

Post by tovrin »

i did calibrate my acc after updating the version each time, i am not certain i checked my level, but it was on the floor, per normal so it should have read level, i will double check after work tonight.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

tovrin wrote:i did calibrate my acc after updating the version each time, i am not certain i checked my level, but it was on the floor, per normal so it should have read level, i will double check after work tonight.


(1) Is your LED off, on, or blinking after calibration (on a reasonably level floor)?
(2) Are the ACC GUI values on the various pitch/roll attitudes similar to a recent working firmware release?
(3) What ACC sensor chip are you using?

General advice to anyone having V1.9 arming problems: If after calibrating the ACC on a level surface, if you are unable to arm and have a blinking LED, then please report the ACC chip being used. This will help determine which part of the code needs review.

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

Re: MultiWii 1.9

Post by shikra »

OK so my Kanchana ADXL345 board works fine,
But my WMP/NK board doesn't arm from sticks
Lights flashing constatntly. Recalibrated, restarted - same. Controls lok good in gui

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

Re: MultiWii 1.9

Post by shikra »

+ it arms OK from the aux control ..... if it helps

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

shikra wrote:But my WMP/NK board doesn't arm from sticks
Lights flashing constantly. Recalibrated, restarted - same. Controls look good in gui


If you don't mind, open the V1.9's serial.pde file. Find this code sequence:

Code: Select all

serialize16(BaroAlt/10); // 4 variables are here for general monitoring purpose
serialize16(0);              // debug2
serialize16(0);              // debug3
serialize16(0);              // debug4


And replace those four lines with this:

Code: Select all

serialize16(BaroAlt/10);      // 4 variables are here for general monitoring purpose
serialize16(acc_25deg);      // debug2
serialize16(acc_1G);         // debug3
serialize16(smallAngle25); // debug4


Get a GUI screen shot while the model is on a flat surface; post it here for review. The GUI's debug windows will have some new data that might help indicate what is going on.

+ it arms OK from the aux control ..... if it helps

All the little details help. :)

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

Re: MultiWii 1.9

Post by tovrin »

ok, mine also arms properly using the aux control, which i also managed to use to turn on stable mode by turning the knob up and down, but it does not arm at all using the RC.




the screenshot shows my RC is on and in position to arm motors, the debug settings requested are also there, as shown by debug 3
Image

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

Re: MultiWii 1.9

Post by shikra »

Yep - same debug settings as tovrin.

Interstingly tonight I found something on my other controller whichI don't understand relating to autolevel. And then replicated to my other controller using completely different sensors
- A scenario where acc are calibrated, and looks perfect in the gui but when autolevel activated the tri shoots off to the side. I have a feeling it may help another issue.
Put another way - what the copter thinks is level is not what is shown in the GUI ....
Or maybe that is this issue too!

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

the screenshot shows my RC is on and in position to arm motors, the debug settings requested are also there, as shown by debug 3

The debug2 value shows that the ACC's calibration-level test value is uninitialized. There's been a lot of re-writes in the V1.9 release involving it, so the best fix will be up to Alex. But in the meantime, let's see if a cheap temporary fix can be arranged.

In the sensors.pde file, search for this text line: void WMP_init(uint8_t d) {

Find this code sequence about 15 lines below that text:

// If we got at least 25 Nunchuck reads, we assume the Nunchuk is present
if (numberAccRead>25)
nunchuk = 1;
delay(10);


Replace that code with:
// If we got at least 25 Nunchuck reads, we assume the Nunchuk is present
if (numberAccRead>25) {
nunchuk = 1;
acc_25deg = acc_1G * 0.423;
}
delay(10);


Upload the patched code to the model and then post a screenshot from the GUI. If the GUI shows that the debug2 value is about 84 then the patched code is now working and the model should accept stick arming. If not, then we can do some more rock throwing at the problem.

BTW, is a ACC Z value of 200 normal for your model when it is level? That is to say, what Z value is shown in a recent *working* software release?
Last edited by mr.rc-cam on Wed Nov 09, 2011 12:29 am, edited 1 time in total.

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

Re: MultiWii 1.9

Post by Alexinparis »

mr.rc-cam wrote:
the screenshot shows my RC is on and in position to arm motors, the debug settings requested are also there, as shown by debug 3

The debug2 value shows that the ACC's calibration-level test value is uninitialized. There's been a lot of re-writes in this release involving this, so the best fix will be up to Alex. But in the meantime, let's see if a cheap temporary fix can be arranged.

In the sensors.pde file, search for this text line: void WMP_init(uint8_t d) {

Find this code below that text:

// If we got at least 25 Nunchuck reads, we assume the Nunchuk is present
if (numberAccRead>25)
nunchuk = 1;
delay(10);


Replace that code with:
// If we got at least 25 Nunchuck reads, we assume the Nunchuk is present
if (numberAccRead>25) {
nunchuk = 1;
acc_25deg = acc_1G * 0.423;
}
delay(10);


Upload the patched code to the model and then post a screenshot from the GUI. If the GUI shows that the debug2 value is about 84 then the patched code is now working and the model should accept stick arming. If not, then we can do some more stick poking at the problem.


Hi,
I came to the same conclusion with this code:

Code: Select all

void WMP_init(uint8_t d) {
  delay(d);
  i2c_writeReg(0xA6, 0xF0, 0x55); // Initialize Extension
  delay(d);
  i2c_writeReg(0xA6, 0xFE, 0x05); // Activate Nunchuck pass-through mode
  delay(d);
  if (d>0) {
    // We need to set acc_1G for the Nunchuk beforehand; It's used in WMP_getRawADC() and ACC_Common()
    // If a different accelerometer is used, it will be overwritten by its ACC_init() later.
    acc_1G = 200;
    acc_25deg = acc_1G * 0.423;
    uint8_t numberAccRead = 0;
    // Read from WMP 100 times, this should return alternating WMP and Nunchuk data
    for(uint8_t i=0;i<100;i++) {
      delay(4);
      if (WMP_getRawADC() == 0) numberAccRead++; // Count number of times we read from the Nunchuk extension
    }
    // If we got at least 25 Nunchuck reads, we assume the Nunchuk is present
    if (numberAccRead>25)
      nunchuk = 1;
    delay(10);
  }
}


thank you all to help debugging

explanation: WMP+NK problem only
Without initializing acc_25deg, small_angle condition is always false and it's impossible to arm via stick command.
It was possible to arm with the ARM box, but due to the acc_25deg condition, the ACC was never taken into account causing a cumulative drift.
A new version is online.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: MultiWii 1.9

Post by mr.rc-cam »

A new version is online.

Thanks for posting an updated file set.

User avatar
UndCon
Posts: 293
Joined: Mon Feb 21, 2011 2:10 pm

Re: MultiWii 1.9

Post by UndCon »

Thank you all for your hard work!

//UndCon

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

Re: MultiWii 1.9

Post by shikra »

+1

The development and improvement rate is just fantastic - especially considering the very wide range of sensors and configurations supported.
Really good to see an open project working so well. Contributions from many of the guys such as ziss_dm really help.

And such a friendly forum here and RCG that hasn't changed unlike some of the other open source developments which seem to loose direction.

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

Re: MultiWii 1.9

Post by shikra »

Running 1.9 (downloaded just prior to the arming fix)
Seeing this on two Tri's - one using WMP/NK and the other ITG3200 and ADXL345

This may be same with other versions too, but I noticed it yesterday because I used GUI to set up rather than LCD and tx sticks like usual.

So calibrate with the Tri level. Looks good in the gui. pitch/roll indicators appear perfect.
These days I set up my Tri by hand feel now before flying. Can get it nearly right.

So hold it up in the air and turn motors on until it reaches hover point then I start to adjust gyro PID until it feels about right.

Now I move to acc autolevel.
Again holding the tri get it to about hover point, then engage autolevel.
It levels out at about 20-25 deg tilt. Seems a little far out as calibrated with it perfect level on bench. mmmmm
Tried a few times - same result. Calibrating from sticks or GUI

At this point I notice first odd thing. When it's hovering and gets to level, the GUI pitch/ roll is indicating perfectly the angle of the copter. Which is nowhere near level... 20- 25 degrees
So the copter thinks its level - but the gui indicates it's true angle very well.

And then the second odd thing I did not expect...
So I looked at my settings and my Autolevel I value was very low compared to default.
I changed I value - and the angle at which the copter stayed for level changed. By changing it I could get it to near level......
I was not expecting that.


Is this related to the fix last night or normal??
I wouldn't normally notice because I usually use LCD and the fine tx calibration to set up..... My feeling is I have experienced with previous versions too, but just trimmed it out with sticks until it was Level like I wanted.

Post Reply