MultiWii

ezio wrote:I have added it too to the logs converter

It doesn't work on my Note 3
I can't open .mission file in the program (log converter), it sees .el1 files only.

NNagib wrote:

ezio wrote:I have added it too to the logs converter

It doesn't work on my Note 3
I can't open .mission file in the program (log converter), it sees .el1 files only.

I have added conversion to GPX format.
For the mission to KML you will have to wait few days.

I have the Multiwii pro 3.0 with version 2.3, when I connect to the ez-gui the mission planner disappears. Do I have to comment this out in the sketch file for the mission planner stuff to work. Or does mission planner just not work with 2.3?

dawagner wrote:I have the Multiwii pro 3.0 with version 2.3, when I connect to the ez-gui the mission planner disappears. Do I have to comment this out in the sketch file for the mission planner stuff to work. Or does mission planner just not work with 2.3?

You have to have this firmware
http://eosbandi.com/downloads/

That did the trick. Thanks!

Does this firmware disable gps hold and RTH? They no longer work even though I have them setup as aux positions.

dawagner wrote:Does this firmware disable gps hold and RTH? They no longer work even though I have them setup as aux positions.

Every function works like in normal 2.3 plus you have mission and autolanding.
Check config.h line by line because it is set completely different then standard config.h.

Is there a way to change the vertical speed between waypoints?
And what is crosstrack gain for ?

Did you ever get the POI working ezio? Mine seems to only look at the poi for the single way point that it was programmed by. The rest of the flight the copter faces the waypoint.

dawagner wrote:Did you ever get the POI working ezio? Mine seems to only look at the poi for the single way point that it was programmed by. The rest of the flight the copter faces the waypoint.

I have tested it few times without a success. I think POI has to be set after each waypoint (WP,POI,WP,POI ...) but I haven't tested this idea yet.

NNagib wrote:@ezio, I use full version of ez-gui and log converter. These are wonderful apps, indeed. I have a question for you:
is there a simple way to load a .mission file in google earth? I create .kml file manually sometimes, but that's boring.
I would like to compare mission and logged flight path in google earth. Tnx

Done

Congratulations!

Is there wnything that can be done to make the mission planner more like the APM new one with spline (arc) waypoints and a better functioning POI/ROI?

Hi Guys,

First of all I have to say that with std version of MWii 2.3 my AltHold, PosHold and RTH are working very well.

Now, step by step I want to try the Eosbandi enhanced version.
I've already installed "MultiWii2_3-navi-b7" and "WinGUI_2.3pre10b71" in order to test the Autoland function but seems not working (of course it's my issue).
It's possible try Autolanding without enabling or selecting any waipoint but only using an RC switch ?
What do I need to enable in GUI ?
I've already read all this thread, but I've not found detailed info.

Thanks
Carlo

carlonb wrote:Hi Guys,

It's possible try Autolanding without enabling or selecting any waipoint but only using an RC switch ?
What do I need to enable in GUI ?
I've already read all this thread, but I've not found detailed info.

Thanks
Carlo

You need to assign a TX switch to the land function. The following works for me (indeed I used it today). Beeper is optional, of course.

stronnag wrote:

carlonb wrote:Hi Guys,

It's possible try Autolanding without enabling or selecting any waipoint but only using an RC switch ?
What do I need to enable in GUI ?
I've already read all this thread, but I've not found detailed info.

Thanks
Carlo

You need to assign a TX switch to the land function. The following works for me (indeed I used it today). Beeper is optional, of course.

switchedit_196.png

Excuse me, what is this GUI you're using?

stronnag wrote:

carlonb wrote:Hi Guys,

It's possible try Autolanding without enabling or selecting any waipoint but only using an RC switch ?
What do I need to enable in GUI ?
I've already read all this thread, but I've not found detailed info.

Thanks
Carlo

You need to assign a TX switch to the land function. The following works for me (indeed I used it today). Beeper is optional, of course.

switchedit_196.png

Thanks stronnag,
Waiting for the wind here slow down Please tell me if i need to activate LAND keeping GPS HOLD/HOME on or no matter about it.
I mean, to activate LAND do I need BARO and MAG ?
Last question: During LAND do I need the throttle stick centered or down to zero ?
Thanks
Carlo

I usually LAND from POSHOLD, and put the throttle down as MW-nav is controlling it. It seems (or may be it's my imagination) to power off quicker that way.
Just my experience, not really sure what the rules are.

stronnag wrote:I usually LAND from POSHOLD, and put the throttle down as MW-nav is controlling it. It seems (or may be it's my imagination) to power off quicker that way.
Just my experience, not really sure what the rules are.

Thanks stronnag,
Just now completed some tests and Autoland seems working well, so here what I've understood looking also at the code:
1) Autoland only working if GPS HOLD/RTH are disabled as these have a priority over LAND.
2) Autoland when engaged (by RC switch) automatically enables GPS HOLD and BARO so no need to enable it by RC switch.
3) Autoland no need MAG, but if enabled the copter keep better the nose (as usual).
4) During Landing the throttle may stay at middle as the code take the control of it. When landed, if the stick is centered, the code wait for 5 sec more to disarm, if the throttle is all the way down, the disarm is more rapid.

NOTE of my test result:
Autolanding run almost well, but when landed, do not disarm, I've wait for more than 30sec but not disarm.
To verify the Landing speed I've tried 50, 100, 250 in Landing Speed param (in GUI), but the results are almost the same, I've not noted big difference, Always the copter land at about 0.5mt/sec (more or less).

Any help about these two issues?

Cheers
Carlo

I've waited 5min throttle set to minimum and also no disarm

Indeed, disarm appears to be somewhat random.

@Eosbandi
News about AUTOLAND function:
I saw that after land, the motors will never disable, so looking at the part of code that detect Landing and using debug() info in GUI I realized that in my tests the variable BaroPID never decrease over -180 as defined with BAROPIDMIN. The min value of BaroPID was -112. So I've changed BAROPIDMIN to -111 and tested again (starting at 5mt height) and then worked as espected.
The motors, after touch down, stops within 12-15sec if throttle stick is at minimum.
I don't know why I have BaroPID -112 as min, only Eosbandi (or other skilled coders) can understood it.
Tomorrow I will try at 20/30mts.

Part of code in GPS.cpp

After my HobbyKing red board started refusing to connect to WinGUI I returned it to HobbyKing, got a refund and changed to their Crius All-in-One clone. This worked fine for a while but now it has the same problem. I have been using "MultiWii 2.3naviB7" with "WinGUI_2.3 pre10 for naviB7". I found that the quad became unstable on take off although it had previously been OK. I could connect it to the GUI at that stage and the accelerometer showed level, but when tilted sideways it reacted as if tilted sideways and backwards. I recalibrated the accelerometer but still got the same result. So I cleared the EEPROM and reloaded B7. Now it won’t connect to the GUI at all, saying that I have selected the wrong port although I have not and the port appears to be working correctly. I have tried different USB cables, different versions of MultiWii and ArduCopter and different PCs with the same result. When I connect the USB cable, lights A,B and C flash. When I click connect A and C flash and the GUI freezes. I can’t see what I could be doing wrong but it seems odd that I could have got two dud boards from HobbyKing.

Your bootloader may have gotten corrupted for some reason.
You could try using an USB to serial cable (cp2102 or FTDI based) and connect that to the ftdi port to see if you get a connection this way, to make sure it's not the USB port or chipset that has been damaged.

I can.
Out of 4 guys at local club running MW or MP all have had unresolved issues with both the red MW & Crius clone HK Mega boards. They have all sent them back for refund & bought genuine Crius AIOP V2 boards, as I have & fly regularly without issue running MW2.3 Navi B7 provided you do the following-
1. Use a switching 5.5V UBec ( or 6V with series diode). Crius board has protection diode in series with supply to AtMega 2560 so you require more than 5V to ensure that
voltage does not run close to 4.5V minimum.
2. Onboard HMC5883 Mag chip can be badly affected by current flowing in DC distribution board or wiring to ESCs. This is not unique to this board & why APM for example removed Mag chip from latest APM 2.6 board.
AIOP V2 has jumper that can be cut (S3) so that I2C Ext Mag board can be connected & Mag located away from interference.

I think I must have been unlucky with dud HobbyKing flight controllers. I would be tearing my hair out if I had any to spare! I shall get a genuine Crius AIO. Hope the ones advertised by the likes of Good Luck Buy are the real McCoy and not some other dodgy offering.

DorsetFlyer wrote:I think I must have been unlucky with dud HobbyKing flight controllers. I would be tearing my hair out if I had any to spare! I shall get a genuine Crius AIO. Hope the ones advertised by the likes of Good Luck Buy are the real McCoy and not some other dodgy offering.

You sure are unlucky! You could do as Arakon suggests & reload the AtMega 2560 Bootloader https://learn.sparkfun.com/tutorials/in ... bootloader
This tutorial shows you the various ways this can be done.
If after reloading Bootloader & it still won't connect to a valid port then obviously something is faulty with FC.

Time for me to eat humble pie and restore the reputation of HobbyKing. The problem was that I had Serial 0 speed set as 115200. I have changed it to 57600 in the sketch and GUI and everything works now. I do not remember how I managed to change this or why I thought it was the correct value. I am very grateful to “v_max” for putting me right on this.

stronnag wrote:Indeed, disarm appears to be somewhat random.

Hi stronnag and @eosbandi,

Now I understood why the disarm appears random after autoland, this because of your own P term in alt hold PID.
I realized that #define BAROPIDMIN -180 (in GPS.cpp Land detection routine - see code in my previous post -) is strictly related to the P term of altitude hold PID (it was logical to get there before).
If P=6.4 as per default, BaroPID will decrease under -180, so the autoland can disarm the motors.
In my tests, my P was 2.3 so, my BaroPID stop to decrease at -112, so no disarm happened.

Will be a good solution, to make it working without changing #define BAROPIDMIN, to pre-calc (if possible) and then assign to BAROPIDMIN the min pre-calculated value with the P of users in order to avoid the issue where do not disarm if the P of altitude hold is changed from default or too low.
Is this an Eosbandi job ?

Cheers
Carlo

carlonb wrote:

stronnag wrote:Indeed, disarm appears to be somewhat random.

Hi stronnag and @eosbandi,

Now I understood why the disarm appears random after autoland, this because of your own P term in alt hold PID.
I realized that #define BAROPIDMIN -180 (in GPS.cpp Land detection routine - see code in my previous post -) is strictly related to the P term of altitude hold PID (it was logical to get there before).
If P=6.4 as per default, BaroPID will decrease under -180, so the autoland can disarm the motors.
In my tests, my P was 2.3 so, my BaroPID stop to decrease at -112, so no disarm happened.

Will be a good solution, to make it working without changing #define BAROPIDMIN, to pre-calc (if possible) and then assign to BAROPIDMIN the min pre-calculated value with the P of users in order to avoid the issue where do not disarm if the P of altitude hold is changed from default or too low.
Is this an Eosbandi job ?

Cheers
Carlo

Hi Carlo,
You are perfectly correct. I'll change the baropidmin into a configurable parameter.

Welcome back, András .... we missed you

-ralf- wrote:Welcome back, András .... we missed you

Thanks,
I'm slowly getting traction again... it was a rough couple of months...
Now, I'm catching up with the changes in the repo, and integrate them to the navi codebase... eventually i'll check in navi code to the main repo....

Andras

Excellent news. Very glad to see you back.

Welcome Back!!!

Bad to hear you've had some rough month!
Also great to hear Navi development will be continued!!!

EOSBandi wrote:Hi Carlo,
You are perfectly correct. I'll change the baropidmin into a configurable parameter.

Hi Andras how are you ? Finally you are back
Well, I've tried your Mwii navi b7 and all seems working well.

I've take a look at your navi code and i tried to add the Autoland after RTH in case of failsafe detection, and seems running well, but I prefer wait for your better solution .

I also tested the POI, well, the copter try to keep his front to the POI, but the yawing do not react quickly during waypoints, so the POI is not perfectly hooked.

Please, confirm me if your MultiWiiNaviSim is fully compatible with the last MultiWii2_3-navi-b7, I've already set the config.h with NMEA and uncommented GPS_SIMULATOR, but no GPS data are received in the FC with MultiWii2_3-navi-b7.
I'm sure the NaviSim throw out the NMEA strings as I've tested with an arduino test code.

Thanks for your great effort.
Carlo

EOSBandi wrote:

-ralf- wrote:Welcome back, András .... we missed you

Thanks,
I'm slowly getting traction again... it was a rough couple of months...
Now, I'm catching up with the changes in the repo, and integrate them to the navi codebase... eventually i'll check in navi code to the main repo....

Andras

Hi Andras,

I'm glad to see you again here
I begun some times ago to merge your nav code in the main repo, but no check in so far
what would you prefer ?
- you think it will be easier for you and I let you do it
- or I finish the most properly I can the integration based on the current nav code

Hi Andras,

Glad you are over rough patch & back on forum. Many of us believed that development had stopped.
Does this mean we will see V2.4 soon?
I have been running your fantastic MWV2.3 Navi b7 together with Esio's EZ-GUI since release & have mostly good experience. Would it be possible to integrate flight logging in V2.4 to make use of 16mb flash memory chip on Crius AIOP or ext data logger for boards without? This would be great to analyse when something does go wrong. Most times users blame the firmware, but there are many other causes that can result in a crash or flyaway.

What I & new users to MW would like to see is new WinGUI that allows easy APM style configuration of FC. The clunky Arduino IDE configuration is so difficult for new users to come to grips with unless they have previously experimented with Arduino as I had. At least 90% of requests for help are due to configuration issues as there is just too much in config.h (& def.h if adding ext sensors) for newbies to comprehend. Autodetection of microcontroller & sensors together with firmware update & config using WinGUI would make transition to MW so much easier for everyone.
Cheers..B

Alexinparis wrote:

EOSBandi wrote:

-ralf- wrote:Welcome back, András .... we missed you

Thanks,
I'm slowly getting traction again... it was a rough couple of months...
Now, I'm catching up with the changes in the repo, and integrate them to the navi codebase... eventually i'll check in navi code to the main repo....

Andras

Hi Andras,

I'm glad to see you again here
I begun some times ago to merge your nav code in the main repo, but no check in so far
what would you prefer ?
- you think it will be easier for you and I let you do it
- or I finish the most properly I can the integration based on the current nav code

Hi Alex,

Thanks, I am glad to be here again
I almost finished the integration.. (Just a flight test needed). So i'll check it in to the svn this weekend.
(I temporary removed the i2c_gps support, to make the code clear and readable, but will put it back, but it will be supported as a GPS... so gps nav on the 328p is out of the question )
Regards,
Andras

Hey Andras! Nice to have you back Wish you well!

-ralf- wrote:Welcome back, András .... we missed you

+1

Who said only bad things happen on 9.11?

OK, r1694 is online ......

-It doesn't run on 328er or 32u4 platforms
-there is no MultiWiiConf, it works with EZ-GUI and WinGUI-Navi-Beta

Right?

-ralf- wrote:OK, r1694 is online ......

-It doesn't run on 328er or 32u4 platforms
-there is no MultiWiiConf, it works with EZ-GUI and WinGUI-Navi-Beta

Right?

Yes.
GPS modes with 328 and 32u4 are not supported at the moment (due inadequate memory size).
Also it should work with MultiWiiConf but you can change GPS parameters only in the config.h (GPS PID's are works with MultiWiiConf)

You need WinGUI for changing GPS parameters (not the PID's) without recompille and for the extended AUX states.
However servo settings are implemented in WinGUI only for Tricopter. (I'm working on a full implementation)

EZ works too
Andras

Hi,

thank you for the integration.

some minor corrections:
2 box MISSION&LAND were always active because of this bug
#ifdef GPS → #if GPS

in multiwii.cpp:
if (GPS_Compute() != 0) break;
if (GPS_NewData() != 0) break;
the purpose is to disociate the 2 tasks:
1) not in the same loop to dissociate frame parsing from gps nav computation time
2) if no computation time taken, allows to continue other tasks in the scheduler

so GPS_NewData() must return 1 in case of data parsing, same for GPS_Compute() in case of GPS_Frame

if (GPS_update == 1) GPS_update = 0; else GPS_update = 1; must be executed only in one function, not both

Hi,
i have the eosbandi "MultiWii2_3-navi-b7" firmware on my quad.
Do you have a code repository for your latest (eosbandi) code changes?

Maik

The code checked in _shared is functionally identical to the B7 version. Only cosmetically changes and changes in the main code since around April.

Hi friends,
It's almost 2 or 3 weeks that I use navi b7 from Eosbandy and looking at the code I've not understood this:

GPS.cpp file

Why GPS_scaleLonDown is applied to lat ? I think it must be applied to Lon

Please explain me, thanks.

carlonb wrote:Hi friends,
It's almost 2 or 3 weeks that I use navi b7 from Eosbandy and looking at the code I've not understood this:

GPS.cpp file

Code: Select all

void GPS_bearing(int32_t* lat1, int32_t* lon1, int32_t* lat2, int32_t* lon2, int32_t* bearing) {

  int32_t off_x = *lon2 - *lon1;
  int32_t off_y = (*lat2 - *lat1) / GPS_scaleLonDown;

  *bearing = 9000 + atan2(-off_y, off_x) * 5729.57795f;      //Convert the output redians to 100xdeg
  if (*bearing < 0) *bearing += 36000;
  }

Why GPS_scaleLonDown is applied to lat ? I think it must be applied to Lon

in this case scaleLonDown is actually streches the latitude to match longitude and this converts the local area to a normal grid, so atan2 can be used...
It was Jason Short's original idea back in 2010.... (http://diydrones.com/forum/topics/getbe ... erstanding)

(originally it was int32_t off_y = (*lat2 - *lat1) * GPS_scaleLonUp; Where GPS_scaleLonUp was 1/scaleLonDown....

EOSBandi wrote:

carlonb wrote:Hi friends,
It's almost 2 or 3 weeks that I use navi b7 from Eosbandy and looking at the code I've not understood this:

GPS.cpp file

Code: Select all

void GPS_bearing(int32_t* lat1, int32_t* lon1, int32_t* lat2, int32_t* lon2, int32_t* bearing) {

  int32_t off_x = *lon2 - *lon1;
  int32_t off_y = (*lat2 - *lat1) / GPS_scaleLonDown;

  *bearing = 9000 + atan2(-off_y, off_x) * 5729.57795f;      //Convert the output redians to 100xdeg
  if (*bearing < 0) *bearing += 36000;
  }

Why GPS_scaleLonDown is applied to lat ? I think it must be applied to Lon

in this case scaleLonDown is actually streches the latitude to match longitude and this converts the local area to a normal grid, so atan2 can be used...
It was Jason Short's original idea back in 2010.... (http://diydrones.com/forum/topics/getbe ... erstanding)

(originally it was int32_t off_y = (*lat2 - *lat1) * GPS_scaleLonUp; Where GPS_scaleLonUp was 1/scaleLonDown....

OK, now I realized.
Tanks Andras

I'm trying this Nav version for the first time, but after hours, I cannot get it to work.

I had a fully working quad with multiwii 2.3, on a crius aiop board, and using the EZ Gui App to configure over bluetooth.

However after attempting to use this nav version, I am completely unable to connect to EZ Gui. I just get constant "No Data Recieved" Errors, even though I have nav protocol selected. I've tried the latest b7, as well as b5 baro fix. I cleared EEPROM multiple times, have compiled both nav versions multiple times, I made sure EZ Gui is updated, double checked all settings in config.h to match my working settings from version 2.3.

Anyone have any idea what the problem is?

carl1864 wrote:I'm trying this Nav version for the first time, but after hours, I cannot get it to work.

I had a fully working quad with multiwii 2.3, on a crius aiop board, and using the EZ Gui App to configure over bluetooth.

However after attempting to use this nav version, I am completely unable to connect to EZ Gui. I just get constant "No Data Recieved" Errors, even though I have nav protocol selected. I've tried the latest b7, as well as b5 baro fix. I cleared EEPROM multiple times, have compiled both nav versions multiple times, I made sure EZ Gui is updated, double checked all settings in config.h to match my working settings from version 2.3.

Anyone have any idea what the problem is?

I have same Crius AIOP (V2) & run MW 2.3 Navi B7. I also have BT module & EZ-GUI. I found that if BT connected when Lipo plugged in then FC locks up.
I you unplug BT until FC has initialised then plug it in OK. I overcame this with a small switch in +5V line to BT. There is another mod required to BT (which runs on 3.3V logic) to prevent possible damage from 5V logic of FC. viewtopic.php?f=6&t=5250
I was hoping that doing mod would also prevent the FC lockup but it didn't so switch is still installed.