MultiWii dev1342 issues

[dramida]

Hi all, today i tried to setup the latest R1342 of multiwii and i observed that wen defined:

Code: Select all

#define LOG_PERMANENT 1023

we get the following compile error on Crius AIOP board:
"armed time not declared in this scope"

line 670 Multiwii.ino

Code: Select all

armedTime += (uint32_t)cycleTime;

And another pain in the neck is setting the corect Vbat and Powermetter. ( especially when you have a wireing fault)
It's incredibly paintful to re-erase the eprom each time you re-adjust VBATSCALE parameter.
Thing goes like this: Enable com, press start, check, disable com, upload eeprom erase,make changes, upload again multiwii, enable com, press start...etc...

How much would it take to set analog prescallers directly from the GUI in a consistent manner ?

(for voltage, current, RSSI ...etc)


Also it would be useful to write which analog ports are used for Vbat, Buzzer, Power, RSSI, right in config.h , in a comment near define statament

[PatrikE]

There's a #ifdef LOG_PERMANENT missing in that dev R1342 .

In my test dev it works.
http://multiwii.googlecode.com/svn/branches/PatrikE/Servotest.zip

Doe's this look intresting?
Still some space left in the Config TAB!...

[AndrejLV]

There's a #ifdef LOG_PERMANENT missing in that dev R1342 .

In my test dev it works.
http://multiwii.googlecode.com/svn/branches/PatrikE/Servotest.zip

Doe's this look intresting?
Still some space left in the Config TAB!...

MWii.jpg

MWiiG.jpg

How do you get this type of screens in MW conf ??

[PatrikE]

How do you get this type of screens in MW conf ??

I use a program called Winsnap who can take a snapshot of a region.

[AndrejLV]

Not how to get print, but how to go there ?

what shall I to do to see tabs DefaultMW Servo Config ?

[PatrikE]

It's a Dev i been working on for a while.
You can find the dev here.
http://multiwii.googlecode.com/svn/branches/PatrikE/Servotest.zip

It's not implemented in Official MWii yet.
But you can test it!
I need some testers to confirm all functions i added to gui.

[copterrichie]

I believe you left out the Bicopter Servo stuff, want to put it in? If so, you may have another willing soul to do some beta testing.

[PatrikE]

I believe you left out the Bicopter Servo stuff, want to put it in? If so, you may have another willing soul to do some beta testing.

I'll check whats needed and try to implement it.

There's not so many settings on the BI if i can remember right!

[copterrichie]

No, there is not. just Range, Center and direction.

[PatrikE]

No, there is not. just Range, Center and direction.

Is it needed to split the a setup per side like a flying wing or can it use a common center/range/direction?
The code is written with common settings for both sides original.

[copterrichie]

Person, I do not see a need to split the sides, both sides would have to be same to the best of my knowledge. However, the direction would have to be different.

[Alexinparis]

And another pain in the neck is setting the corect Vbat and Powermetter. ( especially when you have a wireing fault)
It's incredibly paintful to re-erase the eprom each time you re-adjust VBATSCALE parameter.
Thing goes like this: Enable com, press start, check, disable com, upload eeprom erase,make changes, upload again multiwii, enable com, press start...etc...

Hi,
I think you can use the RESET button instead of "upload eeprom erase".It's then a little bit easy:
Enable com, press start, check, RESET, disable com,make changes, upload again multiwii, enable com, press start...etc...
Do you adjust vbatscale a lot ?

How much would it take to set analog prescallers directly from the GUI in a consistent manner ?
(for voltage, current, RSSI ...etc)

there is no prescaler for rssi. It's just the raw read from an analog PIN [0-1024], and there is not a lot of "...etc"

Also it would be useful to write which analog ports are used for Vbat, Buzzer, Power, RSSI, right in config.h , in a comment near define statement

I think we should advice some PIN number per proc type in order to keep a good uniformity for board designers. (documented in deh.h)
with the ability to override some definition: already documented in config.h in the section /******** override default pin assignments ********************/
we can probably add some items here.

[Alexinparis]

It's a Dev i been working on for a while.
You can find the dev here.
http://multiwii.googlecode.com/svn/branches/PatrikE/Servotest.zip

It's not implemented in Official MWii yet.
But you can test it!
I need some testers to confirm all functions i added to gui.

There are some interesting things for global settings.
But the protocol should be de correlated from the multi type even for heli/flying wing or anything else, like it is currently with multi motor.

In fact we should settle what is a servo and use this model for every servo need.
I think something like this for each servo:
16bit: MIN
16bit: MAX
16bit: MIDDLE
8bit: RATE(and direction = RATE with 1 or -1)

The way to interpret servo should stay in the GUI.

[Hamburger]

we get the following compile error on Crius AIOP board:
"armed time not declared in this scope"

thanks, noted.
Quick fix is to enable ARMED.TIME.WARNING (beware speeling).

[Hamburger]

@Patrik et.al.
the unified servo handling pane in GUI (and MWC) is a fabulous idea.
+ With support in the GUI, more users will be able to easily tweak their servo settings.
+ with unified servo representation in MWC for all coptertypes with servos (BI,TRI, wings, helis) the mixer code could become easier to read - we just have to rewrite some (trivial) mixing/offset stuff.

[Peter]

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?

[Jonit]

same problem for me. Till official 2.1 everything was fine, but on newer versions i am having trouble with arming my copter. Sometimes it arms on the first try, but often i have to reconnect battery multiple times, or try to arm (THR 0, YAW all the way right) 20 or more times until it arm properly.

[Hamburger]

New version has improved failsafe detection. Check endpoints of channels.

[Peter]

Hamburger, would that explain the high cycle time?
And the communication with the GUI is also interrupted.

[Hamburger]

Not sure. It may have that effect when the failsfe handling gets triggered and defused again and again.

[Peter]

Failsave is not compiled in. And it does not go under 995. So I don't think that is the problem.
But I will check the channels when I cannot arm it.

[gompf-2]

Can you also check the I2C bus with an Oszi? Not arming can also be a symptom of "gyro not found" iirc. The original specs want 3mA pullup current on the I2C iirc, not implemented on any board I´ve seen so far and mostly not a problem if you keep close to the bus master. But if you added something to the I2C (increased capacitance/ground leakage current) it may be worth to search in this direction also (I just remember some issues I read her after update from 1.9 upwards, when the driver became more spec conform and picky about "bloddy wiring"). I didn´t read the code in detail, but have seen that the "force 400kHz" lines in the sensor drivers were gone, have you checked with busspeed 100? In principle this is paradox against my former explanation as some sensor readings were always 400kHz regardless to the busspeed in 2.1 but it´s also worth a check (If your setup works reproduceable at 100kHz it´s quite clear that´s a problem of pullups/risetime/better drivers). (and I´m not kidding about "better drivers", they should refuse in case of bus error, if they do not mask until total connection loss it´s better in my eyes).

Nice we,
gompf