MultiWii EZ-GUI

ezio · Post by **ezio** » Fri May 03, 2013 5:14 pm

flyrobot wrote:Hi Ezio,

How to make change the map into satelite map at dashboard 3 ?

Thanks,

John

At the moment you can't. I haven't implemented it.

fallenangel3k · Post by **fallenangel3k** » Tue May 07, 2013 1:33 am

hi there!

i didnt follow the development for a while because of some personal issues... now I am totally confused by the new features, especially because I own a FrSky telemetry rx/tx and want to use the telemetry and gps features. I have a crius multiwii se board. (no i2c gps yet, only serial ublox NL-550ERS)

how do I connect it?

as I understand the FrSky rx in the copter replaces the bt module from before, all communication now happens over airborne frsky rx which transmits it to ground and from there the frsky tx in the transmitter it is wired to the bt module (with level shifters) which talks to my smartphone/ez-gui? so both rx and tx from mw crius se board are wired to the frsky module and same on ground, from the frsky module to the bt module? or do I still need an other/2nd bt module, so I can configure the other and pid parameters and send gps waypoints to the copter? I ask because bt has only very small range but the frsky module has a very great range, compared. that way i could send/change waypoints, even if the copter is out of the bt-range because of 2-way use of the Frsky telemetry modules which sends data from the ground to the copter and visa versa, effectively replacing the FTDI or standard bt connection completely.
sorry for my dumb questions, I'm german and dont understand everything 100%. So better I ask in simple words again: is it correct that the only bt-module is located in the handheld transmitter on the ground, linking the frsky-tx to my smartphone and I dont need a 2nd bt-module on the multiwii?

are there any how-to's or wiring-diagrams to get me started again? this really would help me very much! if not, maybe one can explain the WHOLE wireing to me, what is connected where

best greets,

marcus

QuadBow · Post by **QuadBow** » Tue May 07, 2013 3:26 am

Hi Marcus,

the Frsky telemetry has been discussed here: viewtopic.php?f=7&t=1929&start=120

In conclusion: you need a second serial port for Frsky telemetry since the protocol is totally different from the multiwiiconf protocol used by bluetooth/FTDI.
Unfortunately, your Crius SE board is based upon an Atmega328 which has only one serial port. Actually, you need an Atmega2560 based board like this one http://flyduino.net/Multicopter-FC or the Crius All-iIn-One.

At page 6 of the mentioned thread a workaround has been discussed using the softwareserial library due to the missing hardware serial.
But, I don't know whether that can be implemented without issues because it requires more time, thus cycletime will be impacted.
Maybe, there are other impacts or issues.

The wiring stuff has been explained at page 8 of the mentioned thread.

ssatorugm · Post by **ssatorugm** » Tue May 07, 2013 2:24 pm

I am using 328p Crius SE board for Frsky connection with Icwind's trick to switch to FrSky transmission when armed.

EZ GUI requires slightly different FrSkyTelemtry.ino than actual Frsky hub packet discussed in that thread. Bart ezio placed it on his github page.

To summarize the connection,
[MultiWii with FrSkyTelemtry.ino] --- level shifter -- [Frsky Rx] >>>> [Frsky Tx] --- level shifter --- BT adapter@9600 >>> [Android phone running EZ GUI]

For short range communication up to around 100-200m, BT module antenna mod would be better. It can extend range of BT module.

Satoru

ezio · Post by **ezio** » Tue May 07, 2013 11:50 pm

ezio wrote:Hi
Could you check this version https://dl.dropboxusercontent.com/u/805 ... iEZGUI.apk
If it works correctly I will publish it next week.

Bart

everyone who has installed the version from this link please uninstall it and reinstall updated version from google play store.

zidlov · Post by **zidlov** » Tue May 14, 2013 9:12 pm

ezio wrote:Today when I was flying I noticed strange thing.
Distance to home in my app was always equals 0
I have I2C GPS and the MultiWii version was r1411.
I'm pretty sure that it worked before.
Also when I set the Home position, it was displayed on the map correctly (it is pulled from MultiWii) but quad returns to its original Home position.
Can anybody confirm this ?
Bart

Hm, isn't it like that it's not possible to use the SetHome functions as well as the FollowMe with an I2C Gps? At least, that's why I ordered a MW AIO now, because I found out by accident that follow me didn't work and then read somewhere that it didn't work with an i2c gps. Would be great if I'm wrong, but I thought that's the way it is....

Alexinparis · Post by **Alexinparis** » Tue May 14, 2013 9:19 pm

zidlov wrote:
ezio wrote:Today when I was flying I noticed strange thing.
Distance to home in my app was always equals 0
I have I2C GPS and the MultiWii version was r1411.
I'm pretty sure that it worked before.
Also when I set the Home position, it was displayed on the map correctly (it is pulled from MultiWii) but quad returns to its original Home position.
Can anybody confirm this ?
Bart

Hm, isn't it like that it's not possible to use the SetHome functions as well as the FollowMe with an I2C Gps? At least, that's why I ordered a MW AIO now, because I found out by accident that follow me didn't work and then read somewhere that it didn't work with an i2c gps. Would be great if I'm wrong, but I thought that's the way it is....

Yes, you're right,
it is not possible with the current code to send GPS coordinates to I2C device.
GPS POS HOLD works, but it's based on the internal GPS coordinates of I2C device.
GPS HOME works, but it's based on the internal GPS coordinates HOME of I2C device.

fryefryefrye · Post by **fryefryefrye** » Wed May 15, 2013 7:30 am

Hello Ezio

For a long range communication, I'm using the following solution.

Android device+BT <==air==> BT module<-->uart<-->3DR modem <==air==> 3DR modem<-->uart<-->copter

Because the 3DR modem is not reliable communication channel.
Also the android device is just beside the BT module.

So, EZ-GUI will never know the copter is out of range. And the data on screen is stop updating.

Actually, when the copter is out of range, EZ-GUI is still sending request, but there is no response will be received.

Can you add some sound to indicate this situation is happened, or a time counter on the screen show how many second has been passed since last response from copter.

Thank you very much for your genius work.

ezio · Post by **ezio** » Thu May 16, 2013 12:02 am

fryefryefrye wrote:Hello Ezio

For a long range communication, I'm using the following solution.

Android device+BT <==air==> BT module<-->uart<-->3DR modem <==air==> 3DR modem<-->uart<-->copter

Because the 3DR modem is not reliable communication channel.
Also the android device is just beside the BT module.

So, EZ-GUI will never know the copter is out of range. And the data on screen is stop updating.

Actually, when the copter is out of range, EZ-GUI is still sending request, but there is no response will be received.

Can you add some sound to indicate this situation is happened, or a time counter on the screen show how many second has been passed since last response from copter.

Thank you very much for your genius work.

I will add it soon.
I had similar problems.
So just wait

fryefryefrye · Post by **fryefryefrye** » Thu May 16, 2013 4:27 am

Hello Ezio

A small bug, when the heading in Dashboard 2 = 0, it will disappear.

hexjump · Post by **hexjump** » Thu May 16, 2013 9:54 pm

fryefryefrye wrote:Hello Ezio

A small bug, when the heading in Dashboard 2 = 0, it will disappear.

Yes.

ezio · Post by **ezio** » Thu May 16, 2013 10:36 pm

hexjump wrote:
fryefryefrye wrote:Hello Ezio

A small bug, when the heading in Dashboard 2 = 0, it will disappear.

Yes.

yes I know it.
I will correct it but it is not on the top of my "ToDo" list

Bart

fryefryefrye · Post by **fryefryefrye** » Fri May 17, 2013 4:22 am

ezio wrote:
fryefryefrye wrote:Hello Ezio

For a long range communication, I'm using the following solution.

Android device+BT <==air==> BT module<-->uart<-->3DR modem <==air==> 3DR modem<-->uart<-->copter

.

I will add it soon.
I had similar problems.
So just wait

Hello Ezio

What kind of long range communication system you are using? Is it running on full duplex or half-duplex?

I’m using a half-duplex industry wireless Uart running on 9600bps. Distance can be over 500m with small antenna.

I have tried running on 38400bps, only 100m can be reached.

Because the half-duplex and low baud rate, collision will happen. So I have to low down the refresh rate to 1Hz.

I’m thinking if you can have a “dynamic refresh rate”. It means send the next read command after receive last response. It will increase the refresh rate as fast as possible without cause any collision.

What do you think about it?

hpcre · Post by **hpcre** » Fri May 17, 2013 11:35 am

Hello. Ezio,

I have a request. Currently, when editing PID values in-flight. It takes a few steps to do it. Like write the new value, click on menu, choose save to eeprom, then confirm choice in the confirmation box.

Can you please decrease these steps to just a click on a dedicated write button.

Thanks

ezio · Post by **ezio** » Fri May 17, 2013 9:08 pm

hpcre wrote:Hello. Ezio,

I have a request. Currently, when editing PID values in-flight. It takes a few steps to do it. Like write the new value, click on menu, choose save to eeprom, then confirm choice in the confirmation box.

Can you please decrease these steps to just a click on a dedicated write button.

Thanks

Ok
I'll add a button below PID settings

ezio · Post by **ezio** » Fri May 17, 2013 9:43 pm

fryefryefrye wrote:
ezio wrote:
fryefryefrye wrote:Hello Ezio

For a long range communication, I'm using the following solution.

Android device+BT <==air==> BT module<-->uart<-->3DR modem <==air==> 3DR modem<-->uart<-->copter

.

I will add it soon.
I had similar problems.
So just wait

Hello Ezio

What kind of long range communication system you are using? Is it running on full duplex or half-duplex?

I’m using a half-duplex industry wireless Uart running on 9600bps. Distance can be over 500m with small antenna.

I have tried running on 38400bps, only 100m can be reached.

Because the half-duplex and low baud rate, collision will happen. So I have to low down the refresh rate to 1Hz.

I’m thinking if you can have a “dynamic refresh rate”. It means send the next read command after receive last response. It will increase the refresh rate as fast as possible without cause any collision.

What do you think about it?

Hi
I don't have long range system, I don't even have fpv stuff

I was testing just for fun simple short range 433mhz trascivers.
"dynamic refresh rate" will be the best. But at the moment I have no idea how to implement it.

hpcre · Post by **hpcre** » Sun May 19, 2013 12:04 am

ezio wrote:
hpcre wrote:Hello. Ezio,

I have a request. Currently, when editing PID values in-flight. It takes a few steps to do it. Like write the new value, click on menu, choose save to eeprom, then confirm choice in the confirmation box.

Can you please decrease these steps to just a click on a dedicated write button.

Thanks

Ok
I'll add a button below PID settings

Thank you, the app is really wonderful. I had to donate!

fryefryefrye · Post by **fryefryefrye** » Mon May 20, 2013 7:31 am

ezio wrote:
Hi
I don't have long range system, I don't even have fpv stuff I was testing just for fun simple short range 433mhz trascivers.
"dynamic refresh rate" will be the best. But at the moment I have no idea how to implement it.

All half-duplex com system will have collision problem when you use the fixed time interval to send the request.

Especially when EZ-GUI wants to send position to copter. I have to click “set as position hold” button 2-3 times in the map, then the copter will start to move to the new hold position.

I have some idea about how to fix it. Just start to send the command just after received a reply from copter.

I’m a C++ developer, and had little experience in Android develop, and no experiences in open source software develop.

Maybe I can start my first open source software develop with your software on github.

Is that OK for you?

scrat · Post by **scrat** » Mon May 20, 2013 8:06 am

I have MWii v2.2 on AIO Pro V1.1. And I'm using latest ezio app. When I click Other on the second screen I see there is an option for Magnetic Declination. Is this working with MWii 2.2 or I need to have some of the latest dev versions?

ezio · Post by **ezio** » Mon May 20, 2013 3:13 pm

scrat wrote:I have MWii v2.2 on AIO Pro V1.1. And I'm using latest ezio app. When I click Other on the second screen I see there is an option for Magnetic Declination. Is this working with MWii 2.2 or I need to have some of the latest dev versions?

Magnetic declination and other settings there are probably doesn't work at all. It was designed for dev version after 2.2 but multiwii developpers are changing protocol all the time and I don't have a time to update my app that fast.
So from now my app will support only oficial versions of multiwii. Dev versions will be not supported.
Bart

albertoLG · Post by **albertoLG** » Tue May 21, 2013 7:20 am

Ezio, your software is great, thank you for your work, but I have a small problem or maybe a suggestion. When I try to set a new position hold on the map, seems difficult to click, map keep returning to the center of home position, and it's very difficult to click on it, need to try alot of times before I get the popup window, maybe I do something wrong? thanks again

scrat · Post by **scrat** » Tue May 21, 2013 9:02 am

Thanks for answer.

Leon11t · Post by **Leon11t** » Tue May 21, 2013 2:09 pm

Hi Ezio. Your app uses integrated into Android voice synthesizer. He supports a limited number of languages. Ann example of Ukrainian language, synthesizer speaks only a numbers. It is very annoying! Could you able attach to the functions that are speaks a sound files. For example, when enabled GPS Hold, played file GPS_Hold.wav, Enabled Horizont mode played Horizont.wav or mp3 sound file. Anyone able to record their own personal sound files. Not necessari include these audio files in to the Play Market release. Additional files can be found in your GIT Hub repository. Is it possible implement this idea?

ezio · Post by **ezio** » Tue May 21, 2013 11:26 pm

albertoLG wrote:Ezio, your software is great, thank you for your work, but I have a small problem or maybe a suggestion. When I try to set a new position hold on the map, seems difficult to click, map keep returning to the center of home position, and it's very difficult to click on it, need to try alot of times before I get the popup window, maybe I do something wrong? thanks again

well you are right.
There is a way around. In the config you can find "Map center period" you can set there a refresh rate of centering the map in seconds. So you can set it to high number and it will be easier to set home position.
Hope this helps
Bart

ezio · Post by **ezio** » Tue May 21, 2013 11:42 pm

Leon11t wrote:Hi Ezio. Your app uses integrated into Android voice synthesizer. He supports a limited number of languages. Ann example of Ukrainian language, synthesizer speaks only a numbers. It is very annoying! Could you able attach to the functions that are speaks a sound files. For example, when enabled GPS Hold, played file GPS_Hold.wav, Enabled Horizont mode played Horizont.wav or mp3 sound file. Anyone able to record their own personal sound files. Not necessari include these audio files in to the Play Market release. Additional files can be found in your GIT Hub repository. Is it possible implement this idea?

Well it is possible but I don't know if I will implement it, well not right now. Maybe you can find a text to speech engine that's supporting Ukrainian language. There are many of them: SVOX, IVONA to name just a few.

Bart

ezio · Post by **ezio** » Wed May 22, 2013 12:08 am

fryefryefrye wrote:
ezio wrote:
Hi
I don't have long range system, I don't even have fpv stuff I was testing just for fun simple short range 433mhz trascivers.
"dynamic refresh rate" will be the best. But at the moment I have no idea how to implement it.

All half-duplex com system will have collision problem when you use the fixed time interval to send the request.

Especially when EZ-GUI wants to send position to copter. I have to click “set as position hold” button 2-3 times in the map, then the copter will start to move to the new hold position.

I have some idea about how to fix it. Just start to send the command just after received a reply from copter.

I’m a C++ developer, and had little experience in Android develop, and no experiences in open source software develop.

Maybe I can start my first open source software develop with your software on github.

Is that OK for you?

Well it is OK if your app will be worse then mine!
just kidding

the problem is that the app never was designed to work with half duplex devices. Even if it is not that hard to do it from scratch, I will have to find some clever way to implement it in my app without rewriting it. I'm sure I can do it as soon as I find some free time.

In my app it is not a truly fixed time interval send the request.
It works like this:
1 received data are processed
2 UI is updated, tts, etc...
3 standard requests are sent
4 app waits for the period set in config
6 go to 1

so I think that it is ok for half duplex system BUT each time button is clicked (set PID, AUX, home position etc) the command is sent straight away and this is where the problem lies. I will try to implement some kind of queue for the requests so they can be send all together.

Bart

Alexinparis · Post by **Alexinparis** » Wed May 22, 2013 12:23 am

Hi,

I think waiting for ack for the next message is not a good solution.
It would just waste some free bandwidth waiting for messages.

A solution to avoid congestion could be a theoric bandwidth measurement based on MSP length
so that requests can't overflow the baud capacity.
+ a reasonable buffer to absorb spike.

ezio · Post by **ezio** » Wed May 22, 2013 12:38 am

Alexinparis wrote:Hi,

I think waiting for ack for the next message is not a good solution.
It would just waste some free bandwidth waiting for messages.

A solution to avoid congestion could be a theoric bandwidth measurement based on MSP length
so that requests can't overflow the baud capacity.
+ a reasonable buffer to absorb spike.

so I'm waiting for this implementation in MultiWiiConf so I can mimic it

Bart

fryefryefrye · Post by **fryefryefrye** » Wed May 22, 2013 3:29 am

ezio wrote:Well it is OK if your app will be worse then mine!
just kidding

I do not mean to start a new App, I was saying join you to update some mechanism in your APP. As you have fully understood my problem, I think it’s best to let you do it.

But I’m still struggling to make your source code working in my developer environment 

ezio wrote:In my app it is not a truly fixed time interval send the request.
It works like this:
1 received data are processed
2 UI is updated, tts, etc...
3 standard requests are sent
4 app waits for the period set in config
6 go to 1

I have understood that after review your code.

But there still a problem when the APP start and want to get all the BOXNAME.

In Unreliable com-systme, the first attempt to get BOXNAME may be failed. But you will not try it again. So the state in DashBoard 2 will not be show. Restart the App can solve it.

ezio wrote:BUT each time button is clicked (set PID, AUX, home position etc) the command is sent straight away and this is where the problem lies.

That’s biggest problem I have. When I want to set new GPS-Hold Position, I must do it 2-3 times until it work. I’m gland you have known it. But the problem caused by Unreliable com-systme are still there. Check the GPS-Hold Position come back from copter is best .

fryefryefrye · Post by **fryefryefrye** » Wed May 22, 2013 4:04 am

Alexinparis wrote:Hi,

I think waiting for ack for the next message is not a good solution.
It would just waste some free bandwidth waiting for messages.

A solution to avoid congestion could be a theoric bandwidth measurement based on MSP length
so that requests can't overflow the baud capacity.
+ a reasonable buffer to absorb spike.

That’s the best way to calculate the time out for every request. A baud rate setting can be added in EZ-GUI, it’s not used for communication, only used to calculate the time out.

Talking about the free bandwidth wasted, I’m using a 433Mhz wireless Uart running on 9600bps. I must set refresh rate to 1000ms in EZ-GUI setting, otherwise all BOXNAME can not be get (may be caused by collision). Also some bandwidth was wasted in transfer needless data like Moto, Radio when in DashBoard2.

EZ-GUI is great software that the Bluetooth is absolutely not a good stage for his showing.

He needs a long range wireless communication system.

But long range is always half-duplex, unreliable and low-speed.

Optimize for it is a reasonable.

Alexinparis · Post by **Alexinparis** » Wed May 22, 2013 10:14 pm

fryefryefrye wrote:Talking about the free bandwidth wasted, I’m using a 433Mhz wireless Uart running on 9600bps. I must set refresh rate to 1000ms in EZ-GUI setting, otherwise all BOXNAME can not be get (may be caused by collision). Also some bandwidth was wasted in transfer needless data like Moto, Radio when in DashBoard2.

But long range is always half-duplex, unreliable and low-speed.

I think 9600bps is too low for current GUI.
57600k is not too high to still have a good range and is enough to use fluently any GUI.

I think another confusion comes from the use of 3DR 433Mhz modules: the stock soft they use is not very good to handle a transparent UART

fryefryefrye · Post by **fryefryefrye** » Thu May 23, 2013 3:41 am

Alexinparis wrote:
I think 9600bps is too low for current GUI.
57600k is not too high to still have a good range and is enough to use fluently any GUI.

I think another confusion comes from the use of 3DR 433Mhz modules: the stock soft they use is not very good to handle a transparent UART

I’m amazing that you can have OLSR running on 57.6k speed with long distance.

I’m using a pair of industry wireless Uart also based on Si4432 which is same with OLSR. A pair of them only cost 25$ in my country. It’s 100mw transmit power version.

Do you know how much transmit power your OLSR is?

My on field test show 9600bps can reach 500m, 38400bps can only reach 100m. The vendor says it can reach 1200m when you use 1200bps. (All tests was use small simple antenna)

Maybe my wireless Uart were bad. So, I’m suffering 1Hz refresh rate on EZ-GUI with 9600bps.

I do not except running the MultiWiiConf on a PC in the field. Transfer all sensor data to ground station is not need for most of people when you flying on the field. High data refresh rate is needed when you flying out of sight or FPV. Transfer selected data only can help that.

ezio · Post by **ezio** » Thu May 23, 2013 6:55 am

fryefryefrye wrote:
ezio wrote:Well it is OK if your app will be worse then mine!
just kidding

I do not mean to start a new App, I was saying join you to update some mechanism in your APP. As you have fully understood my problem, I think it’s best to let you do it.

But I’m still struggling to make your source code working in my developer environment 

ezio wrote:In my app it is not a truly fixed time interval send the request.
It works like this:
1 received data are processed
2 UI is updated, tts, etc...
3 standard requests are sent
4 app waits for the period set in config
6 go to 1

I have understood that after review your code.

But there still a problem when the APP start and want to get all the BOXNAME.

In Unreliable com-systme, the first attempt to get BOXNAME may be failed. But you will not try it again. So the state in DashBoard 2 will not be show. Restart the App can solve it.

ezio wrote:BUT each time button is clicked (set PID, AUX, home position etc) the command is sent straight away and this is where the problem lies.

That’s biggest problem I have. When I want to set new GPS-Hold Position, I must do it 2-3 times until it work. I’m gland you have known it. But the problem caused by Unreliable com-systme are still there. Check the GPS-Hold Position come back from copter is best .

If you want to help me in the developement you are welcome.

I will do what I can to improve transmition. But right now I have another project going (gui for brushless camera stabilisation) so I have to share my time.

Bart

ezio · Post by **ezio** » Thu May 23, 2013 10:47 pm

I'm thinking about the improvement of the communication for slow, half duplex systems.
And I have a questions:
Lets assume that we use half duplex communication
When GUI sends packet of requests, MultiWii starts to send a replies as soon as it gets first request. So MultiWii can start sending when others requests are still coming.

Am I right ?
How we can cope with this situation ?

Bart

scrat · Post by **scrat** » Fri May 24, 2013 6:59 am

@ezio: Could you be so kind and post a link to the latest ez-gui (apk file) like is now on google play store. Thanks.

fryefryefrye · Post by **fryefryefrye** » Fri May 24, 2013 9:43 am

ezio wrote:I'm thinking about the improvement of the communication for slow, half duplex systems.
And I have a questions:
Lets assume that we use half duplex communication
When GUI sends packet of requests, MultiWii starts to send a replies as soon as it gets first request. So MultiWii can start sending when others requests are still coming.

Am I right ?
How we can cope with this situation ?

Bart

As Alex have said:

Alexinparis wrote:
The current implementation is ask and answer but the answer is not needed to ask again, so you don't need to wait between several asks.
you can even group them is a single packet.

And you have done like it:

Code: Select all


requests = new int[] { MSP_STATUS, MSP_RAW_IMU, MSP_SERVO, MSP_MOTOR, MSP_RC, MSP_RAW_GPS, MSP_COMP_GPS, MSP_ALTITUDE, MSP_ATTITUDE, MSP_DEBUG };
sendRequestMSP(requestMSP(requests));

After a group of request sent out by GUI, MultiWii starts to send a group of replies. When MultiWii is finished and stop sending, the line is free and GUI can send the next group of request or a command like set Hold_postion.

You can not start sending while the line is busy when you are using half duplex systems.

If GUI can send the next group of request immediately after the line is free, we will get the maximal refresh rate at a given baud rate.

But we still need to think about if some data was lost in the air, what we should do.

WalkOver · Post by **WalkOver** » Fri May 24, 2013 2:51 pm

Hello,

I don't know where to post my question so, I'm sorry if it is not the right place.

I designed my flight controller myself for the fun based on the multiwiimega board : http://www.diymulticopter.org/

So I have exactly the same chip orientation.
But In the GUI, the roll inclination goes on the good way but the artificial hozizon goes in the opposite way.
Is it normal operation ?

Thank you for your help

linuxslate · Post by **linuxslate** » Fri May 24, 2013 6:37 pm

WalkOver;

Yes, the attitude indicator (artificial horizon) is backwards (vertically) in both Dashboard 2 and Dashboard 3.

I mentioned this to ezio in an email, and he wrote a bug report on github.

For casual readers Please Note:

We are not talking about the confusion some people have of left to right roll. This is a vertical (pitch) issue.

The attitude indicator in MultiWiiConf is correct. If pitching your aircraft (board) up/down, causes the correct reaction in MultiiWiiConf, you are OK to fly (in that respect).

WalkOver · Post by **WalkOver** » Fri May 24, 2013 8:05 pm

Ok thank you for your answer.

The roll and pitch seems to have the correct reaction as it is for the motor throtle

.

Im almost ready to fly. I just need to fix the motor pin assignment on my home made board and that's all

Thank you again

ezio · Post by **ezio** » Fri May 24, 2013 9:58 pm

fryefryefrye wrote:
ezio wrote:I'm thinking about the improvement of the communication for slow, half duplex systems.
And I have a questions:
Lets assume that we use half duplex communication
When GUI sends packet of requests, MultiWii starts to send a replies as soon as it gets first request. So MultiWii can start sending when others requests are still coming.

Am I right ?
How we can cope with this situation ?

Bart

As Alex have said:

Alexinparis wrote:
The current implementation is ask and answer but the answer is not needed to ask again, so you don't need to wait between several asks.
you can even group them is a single packet.

And you have done like it:
Code: Select all
requests = new int[] { MSP_STATUS, MSP_RAW_IMU, MSP_SERVO, MSP_MOTOR, MSP_RC, MSP_RAW_GPS, MSP_COMP_GPS, MSP_ALTITUDE, MSP_ATTITUDE, MSP_DEBUG };
sendRequestMSP(requestMSP(requests));
After a group of request sent out by GUI, MultiWii starts to send a group of replies. When MultiWii is finished and stop sending, the line is free and GUI can send the next group of request or a command like set Hold_postion.

You can not start sending while the line is busy when you are using half duplex systems.

If GUI can send the next group of request immediately after the line is free, we will get the maximal refresh rate at a given baud rate.

But we still need to think about if some data was lost in the air, what we should do.

Yes I know that
But when this is sent:

Code: Select all

requests = new int[] { MSP_STATUS, MSP_RAW_IMU, MSP_SERVO, MSP_MOTOR, MSP_RC, MSP_RAW_GPS, MSP_COMP_GPS, MSP_ALTITUDE, MSP_ATTITUDE, MSP_DEBUG };
sendRequestMSP(requestMSP(requests));

multiwii doesn't wait for all requests be received. It starts to send reply as soon as it receives ie. MSP_STATUS request. So the line is busy because more requests are coming and at the same time multiwii starts to respond to already received requests.

ezio · Post by **ezio** » Fri May 24, 2013 10:49 pm

linuxslate wrote:WalkOver;

Yes, the attitude indicator (artificial horizon) is backwards (vertically) in both Dashboard 2 and Dashboard 3.

I mentioned this to ezio in an email, and he wrote a bug report on github.

For casual readers Please Note:

We are not talking about the confusion some people have of left to right roll. This is a vertical (pitch) issue.

The attitude indicator in MultiWiiConf is correct. If pitching your aircraft (board) up/down, causes the correct reaction in MultiiWiiConf, you are OK to fly (in that respect).

Corrected
Thanks

ezio · Post by **ezio** » Sat May 25, 2013 2:34 am

scrat wrote:@ezio: Could you be so kind and post a link to the latest ez-gui (apk file) like is now on google play store. Thanks.

https://dl.dropboxusercontent.com/u/805 ... iEZGUI.apk

linuxslate · Post by **linuxslate** » Sat May 25, 2013 4:54 am

I updated from Google Play.

The artifical horizon is now correct in Dashboard 2 and 3 !!

Yay !! Thanks ezio !!

ezio · Post by **ezio** » Sun May 26, 2013 2:25 am

Hi
Today I added something very experimental. I will try to describe it here.
This feature allows to use any android map application to display a copter position. MultiWii EZ-GUI emulates Android's GPS.
This is how it works:
first make sure that you have enable MOCK location in android settings (this may be not required when android is rooted):

then start EZ-GUI, connect as always and then go to "GPS". Mock location is hidden by now so to unhide it press yellow title bar.

then press "Start MOCK location service". EZ-GUI disappears. You can now run any map app like Google Maps, My Tracks(https://play.google.com/store/apps/deta ... wsMSwyLDNd) or any other

and the copter's position should be displayed. Heading may not work in every app.

To come back to the MultiWii EZ-GUI press the icon in the notification bar. Also remember to stop the MOCK location service as soon as you come back to EZ-GUI.

Let me know if it works.
Bart

ezio · Post by **ezio** » Sun May 26, 2013 2:34 am

fryefryefrye wrote:But there still a problem when the APP start and want to get all the BOXNAME.

In Unreliable com-systme, the first attempt to get BOXNAME may be failed. But you will not try it again. So the state in DashBoard 2 will not be show. Restart the App can solve it.

From now the app should try to get BOXNAMEs until the operation is successful.

fryefryefrye · Post by **fryefryefrye** » Sun May 26, 2013 8:44 am

ezio wrote:
Yes I know that
But when this is sent:
Code: Select all
requests = new int[] { MSP_STATUS, MSP_RAW_IMU, MSP_SERVO, MSP_MOTOR, MSP_RC, MSP_RAW_GPS, MSP_COMP_GPS, MSP_ALTITUDE, MSP_ATTITUDE, MSP_DEBUG };
sendRequestMSP(requestMSP(requests));
multiwii doesn't wait for all requests be received. It starts to send reply as soon as it receives ie. MSP_STATUS request. So the line is busy because more requests are coming and at the same time multiwii starts to respond to already received requests.

My Wireless Uart have two LEDs to indicator the sending and receiving.

With 1000ms setting in EZ-GUI and 9600bps, I can see clearly sending LED flash about 0.1s then receiving LED flash about 0.4s in 1s.cycle.

And every 10s, there is a short receiving LED ON about 0.2s. It should be the request for battery volts and something.

So I’m thinking they are ask/answer in groups.

There is a 200bytes buffer to cache all the data coming from Uart but not send out over air. If you are right, the buffer is taking a important role while the communication.

But buffer on the Wireless Uart may be not big enough to caching all the bytes multiwii send out.

Maybe I need Oscilloscope to see what happened on the line. But this equipment I can not get easily.

fryefryefrye · Post by **fryefryefrye** » Sun May 26, 2013 8:55 am

ezio wrote:Hi
Today I added something very experimental. I will try to describe it here.
This feature allows to use any android map application to display a copter position. MultiWii EZ-GUI emulates Android's GPS.

copter's position should be displayed. Heading may not work in every app.

Let me know if it works.

My only Android develop experience is creat a TCP/IP connection and get a position from a server, then set it to Mock location. Haha. With this experience, I still can not make your source code working in my computer. :-(

Good to hear you are also use the Mock location to show MultiWii track in all kind of map software.

I have question, is the “following me” working while Mock location was set to android location service?

For heading , if the gps_speed = 0, the google map will use the head from phone-mag instead of the gps-heading.

Which heading you inject into android location service? Heading from mag? Or haeding from GPS?

I will try yours new function when I have time.

Steve_In_Brussels · Post by **Steve_In_Brussels** » Mon May 27, 2013 6:02 pm

I wondered if anybody else was getting this and what to do about it. I am running MW 2.1. EZ-GUI is truly great - well worth the Dashboard 3 too!!!

However, when I go into config and tick the "alt correction" box ("alt set to zero when arming"). First the alt stays at zero, lift off -- two metres, three metres happy happy. Then I start to get horrid wrong values, 4500 metres, minus 196 metres. When I look at dashboard 1, the alt is all over the place. Other parameters seem sensible.

Without all correct, I have nice steady altitudes, even if they are offset with respect to the ground.

Thoughts, comments or is this an odd bug (I have the latest version)? Nobody else seems to have the problem.

ezio · Post by **ezio** » Mon May 27, 2013 11:11 pm

Steve_In_Brussels wrote:I wondered if anybody else was getting this and what to do about it. I am running MW 2.1. EZ-GUI is truly great - well worth the Dashboard 3 too!!!

However, when I go into config and tick the "alt correction" box ("alt set to zero when arming"). First the alt stays at zero, lift off -- two metres, three metres happy happy. Then I start to get horrid wrong values, 4500 metres, minus 196 metres. When I look at dashboard 1, the alt is all over the place. Other parameters seem sensible.

Without all correct, I have nice steady altitudes, even if they are offset with respect to the ground.

Thoughts, comments or is this an odd bug (I have the latest version)? Nobody else seems to have the problem.

I will check it.
Btw this function was created for the old MultiWii versions. In MW 2.2 there is no need to use it anymore.

Steve_In_Brussels · Post by **Steve_In_Brussels** » Tue May 28, 2013 9:20 am

Thanks Ezio. I tried on two Android devices just to be sure, the problem was the same on both.
GREAT WORK -- I am amazed just how useful and easy your APP is.
The only unusual (?) thing I am doing is using an APC220 module on the Quad to an "APC220 to Bluetooth bridge" that retransmits to the Android devices. All data apart from the adjusted altitude seems perfect.