MultiWii EZ-GUI
Re: MultiWii EZ-GUI
I was in bluetooth range when i set the distant WP. It dosen't bother me too much to lose BT connection after that, anyway i have RTH.
I need to experiment more.
One more thing: After gaining manual control over quad, PH didn't work anymore until i rebooted.
I need to experiment more.
One more thing: After gaining manual control over quad, PH didn't work anymore until i rebooted.
Re: MultiWii EZ-GUI
WesH wrote:Deet wrote:WesH wrote:Thank You. I am using a pro mini, and wii controller/ nunchuck combo. I assume connection are vcc, gnd, tx andrx
Yep, just remember Rx goes to Tx. Tx to Rx
Thanks for the reminder. There is a 50/50 chance I might have remembered on my own.
I carry a soldering iron in my laptop case because it is frightening how often I go to a job and its the other way around
Re: MultiWii EZ-GUI
dramida wrote:
On short distances, navigation goes smoothly but when i tried 500m or so, the gps hold went mad and started leaning in extreme angles.
I think it is because you use a Position Hold "waypoint". I maybe wrong (have't studied multiwii source code for very long) but Position Hold algorithm is different from Return To Home and it doesn't work good on longer distances. ( I can't test it because setting position hold doesn't work with I2C gps
![Sad :(](./images/smilies/icon_e_sad.gif)
And as I said earlier all waypoint staff has to be rethinked and change to match current needs.
Bart
Re: MultiWii EZ-GUI
ezio wrote:dramida wrote:
On short distances, navigation goes smoothly but when i tried 500m or so, the gps hold went mad and started leaning in extreme angles.
I think it is because you use a Position Hold "waypoint". I maybe wrong (have't studied multiwii source code for very long) but Position Hold algorithm is different from Return To Home and it doesn't work good on longer distances. ( I can't test it because setting position hold doesn't work with I2C gps)
And as I said earlier all waypoint staff has to be rethinked and change to match current needs.
Bart
The naw mode is changed to home mode when WP16 is inserted, so it uses the same code part as for the navigation code. Or at least it should.....
The evidence is that when I change the WP16, copter rotates towards to the new point and starts to move there.
BR
Adrian
Re: MultiWii EZ-GUI
Deet wrote:WesH wrote:Deet wrote:
Yep, just remember Rx goes to Tx. Tx to Rx
Thanks for the reminder. There is a 50/50 chance I might have remembered on my own.
I carry a soldering iron in my laptop case because it is frightening how often I go to a job and its the other way around
That's fantastic
![Laughing :lol:](./images/smilies/icon_lol.gif)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
nhadrian wrote:ezio wrote:dramida wrote:
On short distances, navigation goes smoothly but when i tried 500m or so, the gps hold went mad and started leaning in extreme angles.
I think it is because you use a Position Hold "waypoint". I maybe wrong (have't studied multiwii source code for very long) but Position Hold algorithm is different from Return To Home and it doesn't work good on longer distances. ( I can't test it because setting position hold doesn't work with I2C gps)
And as I said earlier all waypoint staff has to be rethinked and change to match current needs.
Bart
The naw mode is changed to home mode when WP16 is inserted, so it uses the same code part as for the navigation code. Or at least it should.....
The evidence is that when I change the WP16, copter rotates towards to the new point and starts to move there.
BR
Adrian
Yes, there should be no differences currently using the HOME WP or HOLD WP to navigate with EZ GUI.
And as I said earlier all waypoint staff has to be rethinked and change to match current needs.
I'm agree too.
At least for each WP: altitude should be in 32bit. I'm not sure we should add the a vario indication in a WP (or at least now)
A heading indication is probably good.
What was the purpose of nag flag ? I think EOS took this logic from arducopter.
Re: MultiWii EZ-GUI
I think WP should have
LAT, LON, HEAD, ALT, NAV FLAG(for extra features in the future like orbiting etc) and maybe TIME to stay at the position
LAT, LON, HEAD, ALT, NAV FLAG(for extra features in the future like orbiting etc) and maybe TIME to stay at the position
Odp: MultiWii EZ-GUI
I'm curious why there us no movement in MultiWii code in GPS navigation part. As we have working and very accurate alt hold, I think we can implement proper waypoint navigation.
Or I am wrong.
Or I am wrong.
Re: MultiWii EZ-GUI
Hi Bart,
I have working alt_hold_vario code and also a universal alt_to_target code, wich enables rising/descending to a defined altitude with defined vario. It can be used for WP navigation, my goal was to make as universal as it can be.
Alexinparis said it is hard to see the benefits/disadvantages in my code, because I have many modifications at a time. Unfortunatelly they can't be fully separated, although I tried to make 5 different sub-versions with separated parts. I can't do more. I'm happy with the working code (and with some brave-enough users...). I fully respect Alex's oppinion. It all depends on him and the others doing the official repository to decide wether use it or not. (possibly not...
)
About nav code, it should be improved a lot, both in MSP and in nav routine. It is not an impossible job, but will take long time.
Also EEPROM layout must be modified to be able of storing the WP parameters (16 is not enough I think...), maybe instead of permanent logging and other unnecessary logging stuff, along with many more user-defined parameters (as in servotest.zip in r1344....).
Nav mode must be able to follow WP after WP, controlled by an aux channel (3-point switch for example), but also be able to move to an updated WP (sent online via telemetry/android). So we are speaking about two different modes now.
And of course GUI must be modified according to changes!
BR
Adrian
I have working alt_hold_vario code and also a universal alt_to_target code, wich enables rising/descending to a defined altitude with defined vario. It can be used for WP navigation, my goal was to make as universal as it can be.
Alexinparis said it is hard to see the benefits/disadvantages in my code, because I have many modifications at a time. Unfortunatelly they can't be fully separated, although I tried to make 5 different sub-versions with separated parts. I can't do more. I'm happy with the working code (and with some brave-enough users...). I fully respect Alex's oppinion. It all depends on him and the others doing the official repository to decide wether use it or not. (possibly not...
![Sad :(](./images/smilies/icon_e_sad.gif)
About nav code, it should be improved a lot, both in MSP and in nav routine. It is not an impossible job, but will take long time.
Also EEPROM layout must be modified to be able of storing the WP parameters (16 is not enough I think...), maybe instead of permanent logging and other unnecessary logging stuff, along with many more user-defined parameters (as in servotest.zip in r1344....).
Nav mode must be able to follow WP after WP, controlled by an aux channel (3-point switch for example), but also be able to move to an updated WP (sent online via telemetry/android). So we are speaking about two different modes now.
And of course GUI must be modified according to changes!
BR
Adrian
Re: MultiWii EZ-GUI
@ezio:
Navigation and GPS PH was mainly the work of Andras aka Eos_bandi. He implemented some Arducopter libraries into multiwi and coded GPS PH and RTH.
Navigation and GPS PH was mainly the work of Andras aka Eos_bandi. He implemented some Arducopter libraries into multiwi and coded GPS PH and RTH.
Odp: MultiWii EZ-GUI
Yes I know. But he is no active any more. ![Sad :(](./images/smilies/icon_e_sad.gif)
![Sad :(](./images/smilies/icon_e_sad.gif)
Re: MultiWii EZ-GUI
I know him since he lives 20km far from me...
Unfortunatelly he is really busy at work nowadays, can't spend time on mwi development.
:(:(
Unfortunatelly he is really busy at work nowadays, can't spend time on mwi development.
![Sad :(](./images/smilies/icon_e_sad.gif)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
ezio wrote:I think WP should have
LAT, LON, HEAD, ALT, NAV FLAG(for extra features in the future like orbiting etc) and maybe TIME to stay at the position
Hi,
I think the navigation part is not so simple even on the paper.
It should take some time to have a proper solution.
My plan is to launch the 2.2 soon based +/- on the current code.
I think we can adapt the structure of a WP now quite easily to match future supposed features. (without guaranty it will stay like this)
But the code behind will not evolve for 2.2. (only restricted for WP0 & WP16 navigation, which is still a good improvement)
The current WP structure is : WP_number (uint8_t) / LAT (int32_t) / LON (int32_t) / ALT (int16_t) / navflag (uint8_t)
is is not adapted for ALT (16bit)
I suggest to adapt it now with your suggestion:
WP_number (uint8_t) / LAT (int32_t) / LON (int32_t) / ALT (int32_t) / HEAD (int16_t) / TIME_to_stay in millis (uint16_t) / navflag (uint8_t)
Here is some idea about a simple automatic navigation after 2.2:
WP_number 0 is HOME
WP_number 16 is HOLD
for the other:
nav_flag is used to indicate the next WP_number (if nav_flag <=16)
nav_flag could be used for other purpose if nav_flag>16
setting the WP_number 1 will begin the automatic navigation
so you could imagine this example: an automatic navigation with 4 WP to set in this order:
WP 4 : navflag -> 0 (HOME)
WP 3 : navflag -> 4
WP 2 : navflag -> 3
WP 1 : navflag -> 2 <- to set at the end: activate the navigation (navigate toward WP1 and then toward the WP indicated by navflag)
the result would be: current pos -> WP1 -> WP 2 -> WP 3 -> WP4 -> HOME
Re: MultiWii EZ-GUI
how can i add me on mappy communauty?
this apk is wonderful
this apk is wonderful
Re: MultiWii EZ-GUI
alexia wrote:how can i add me on mappy communauty?
this apk is wonderful
go to map, and do long press or short press (depends on the online or offline map) and there will be the button
Re: MultiWii EZ-GUI
Alexinparis wrote:ezio wrote:I think WP should have
LAT, LON, HEAD, ALT, NAV FLAG(for extra features in the future like orbiting etc) and maybe TIME to stay at the position
Hi,
I think the navigation part is not so simple even on the paper.
It should take some time to have a proper solution.
My plan is to launch the 2.2 soon based +/- on the current code.
I think we can adapt the structure of a WP now quite easily to match future supposed features. (without guaranty it will stay like this)
But the code behind will not evolve for 2.2. (only restricted for WP0 & WP16 navigation, which is still a good improvement)
The current WP structure is : WP_number (uint8_t) / LAT (int32_t) / LON (int32_t) / ALT (int16_t) / navflag (uint8_t)
is is not adapted for ALT (16bit)
I suggest to adapt it now with your suggestion:
WP_number (uint8_t) / LAT (int32_t) / LON (int32_t) / ALT (int32_t) / HEAD (int16_t) / TIME_to_stay in millis (uint16_t) / navflag (uint8_t)
Here is some idea about a simple automatic navigation after 2.2:
WP_number 0 is HOME
WP_number 16 is HOLD
for the other:
nav_flag is used to indicate the next WP_number (if nav_flag <=16)
nav_flag could be used for other purpose if nav_flag>16
setting the WP_number 1 will begin the automatic navigation
so you could imagine this example: an automatic navigation with 4 WP to set in this order:
WP 4 : navflag -> 0 (HOME)
WP 3 : navflag -> 4
WP 2 : navflag -> 3
WP 1 : navflag -> 2 <- to set at the end: activate the navigation (navigate toward WP1 and then toward the WP indicated by navflag)
the result would be: current pos -> WP1 -> WP 2 -> WP 3 -> WP4 -> HOME
You don't have to tell me that navigation is difficoult. I tried it once. I wrote a simple program to control a simulator http://www.youtube.com/watch?v=sLMnOVyAtKE
your proposition sounds good to me, it will require some more coding and smart interface but I think I can manage that.
16 wp points is more then enough in my opinion. (in future we can add more if we plan interstate flights
![Smile :)](./images/smilies/icon_e_smile.gif)
In the future we can add new features like orbiting etc and use navflag to set it.
Bart
Re: MultiWii EZ-GUI
@ezio:
Could you be so kind and check if you can port your wonderful app for Android to BlackBerry. I have BB Z10 and like I read there is minimum changes required for porting app from Android to BlackBerry.
Thanks for answer.
Could you be so kind and check if you can port your wonderful app for Android to BlackBerry. I have BB Z10 and like I read there is minimum changes required for porting app from Android to BlackBerry.
Thanks for answer.
AW: MultiWii EZ-GUI
Why don't you set navflag as int and make hold flag =-1? This way you can use any amount of waypoints ![Wink ;)](./images/smilies/icon_e_wink.gif)
![Wink ;)](./images/smilies/icon_e_wink.gif)
Re: MultiWii EZ-GUI
scrat wrote:@ezio:
Could you be so kind and check if you can port your wonderful app for Android to BlackBerry. I have BB Z10 and like I read there is minimum changes required for porting app from Android to BlackBerry.
Thanks for answer.
Yes normally for a simple app it is possible but I'm using sensors, bluetooth and google maps which are not compatible with BlackBerry.
Re: MultiWii EZ-GUI
my location after to test gps and communauty add is not good(wifi and gps activate)..
it will be great if we could add our location without to use automatic location
it will be great if we could add our location without to use automatic location
Re: MultiWii EZ-GUI
alexia wrote:my location after to test gps and communauty add is not good(wifi and gps activate)..
it will be great if we could add our location without to use automatic location
I have added it just for fun so please do not expect much from it.
But maybe someone can make it in proper way so we can add this ability to multiwii web site or forum.
Re: MultiWii EZ-GUI
ezio wrote:alexia wrote:my location after to test gps and communauty add is not good(wifi and gps activate)..
it will be great if we could add our location without to use automatic location
I have added it just for fun so please do not expect much from it.
But maybe someone can make it in proper way so we can add this ability to multiwii web site or forum.
i found it s a good idea to have the communauty location
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Re: MultiWii EZ-GUI
ezio wrote:scrat wrote:@ezio:
Could you be so kind and check if you can port your wonderful app for Android to BlackBerry. I have BB Z10 and like I read there is minimum changes required for porting app from Android to BlackBerry.
Thanks for answer.
Yes normally for a simple app it is possible but I'm using sensors, bluetooth and google maps which are not compatible with BlackBerry.
Yes you're right. Google maps doesn't work for now. But they're working on it.
Re: MultiWii EZ-GUI
Hi
There was a bug in version 3.11.62. Application crashes on startup if gps is enabled.
This should be ok after today's update.
Update should be available in next few hours.
Can someone confirm if it now works ?
also I added possibility to load PID configuration from file which can be produced in MultiWiiConf.
You have to copy saved settings to /sdcard/multiwiilogs folder. (remember to add *.mwi extension to the file)
Can also someone can confirm if this works on his phone/tablet.
Thanks
Bart
There was a bug in version 3.11.62. Application crashes on startup if gps is enabled.
This should be ok after today's update.
Update should be available in next few hours.
Can someone confirm if it now works ?
also I added possibility to load PID configuration from file which can be produced in MultiWiiConf.
You have to copy saved settings to /sdcard/multiwiilogs folder. (remember to add *.mwi extension to the file)
Can also someone can confirm if this works on his phone/tablet.
Thanks
Bart
- Gartenflieger
- Posts: 65
- Joined: Sat Oct 01, 2011 10:07 pm
- Location: Dortmund, Germany
Re: MultiWii EZ-GUI
I have moved a bluetooth module from a Promini to a Mega controller. The choice of the UART was easy for the Promini...
Can I connect the BT to any UART on the Mega? I'm on MW Version 1348.
Thanks
Christoph
Can I connect the BT to any UART on the Mega? I'm on MW Version 1348.
Thanks
Christoph
Re: MultiWii EZ-GUI
it will be great if this apk support usb hsot for rctimer 433mhz module for long range
Re: MultiWii EZ-GUI
alexia wrote:it will be great if this apk support usb hsot for rctimer 433mhz module for long range
yeah usb support will be cool but it is no that easy with Android.
Android in versions <3.0 doesn't support usb host and even in >3.0 there are not many phones that support it out of the box. right now 23% of users of my app are on Android 2.3.x.
I don't want to create an app which only works on small number of devices or require root because it is pointless. So for now I stick to Bluetooth only.
Bart
Re: MultiWii EZ-GUI
I understand that and you are right.
Despite this, you apk is Perfect.
Despite this, you apk is Perfect.
Re: MultiWii EZ-GUI
ezio, you can have that feature active for everyone with a compatible phone, but still have the app working on others phones too. However, it is not exactly easy to enable usb support for all kind of devices. There are a few libraries, but if those 433mhz modules use something different ... well ... good luck ![Wink ;-)](./images/smilies/icon_e_wink.gif)
If it is just serial, why not use a serial bluetooth bridge on those long range modules?!
![Wink ;-)](./images/smilies/icon_e_wink.gif)
If it is just serial, why not use a serial bluetooth bridge on those long range modules?!
Re: MultiWii EZ-GUI
Sebbi wrote:ezio, you can have that feature active for everyone with a compatible phone, but still have the app working on others phones too. However, it is not exactly easy to enable usb support for all kind of devices. There are a few libraries, but if those 433mhz modules use something different ... well ... good luck
If it is just serial, why not use a serial Bluetooth bridge on those long range modules?!
yes I know that I can activate the feature depends on the phone/tablet. But lets say this loud, usb on android is tricky and complicated, there is no easy way to install ie drivers. And I don't want to spent countless hours to develop something what will be used by 50 peoples around the world. Also I don't want to receive hundreds of emails with the question "why it does not for me?"
Right now I receive a lot of emails with questions like this: "There is a bug in your app because gps shows nothing, could you correct it?" and the answer was simple there was no gps in his phone.
When I started write this app every thing was simple. 90% of the market it was taken by Android 2.2. Devices have the same sensors the same orientation etc. Right now I spent most of the time to make my app work from Android 2.2 to Android 4.2.x. And people (and I) have a lot of problems with low end devices which I must say are strange (like they don't have google play, or google maps, or some API which I use, or they have strange memory management settings, etc).
But, hey, if you want to try usb host, source code of my app is waiting ...
Bart
Re: MultiWii EZ-GUI
i think it s not a necessary because we can connect bluethoot on 433mhz module,
before we need to tune baud rate
before we need to tune baud rate
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
Gartenflieger wrote:I have moved a bluetooth module from a Promini to a Mega controller. The choice of the UART was easy for the Promini...
Can I connect the BT to any UART on the Mega? I'm on MW Version 1348.
Thanks
Christoph
Yes, on the MEGA, any port can be used. They have exactly the same role can can be configured independently with a different baud setting.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
alexia wrote:it will be great if this apk support usb hsot for rctimer 433mhz module for long range
I think this topic is for you:
viewtopic.php?f=8&t=3101
You can already connect directly a bluetooth module with a 3DR module, or wait for the module I cook that could be used with a ppm input or independently.
Bluetooth works really fine on android phones. This is to my mind the only communication to support.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
ezio wrote:Alexinparis wrote:ezio wrote:I think WP should have
LAT, LON, HEAD, ALT, NAV FLAG(for extra features in the future like orbiting etc) and maybe TIME to stay at the position
Hi,
I think the navigation part is not so simple even on the paper.
It should take some time to have a proper solution.
My plan is to launch the 2.2 soon based +/- on the current code.
I think we can adapt the structure of a WP now quite easily to match future supposed features. (without guaranty it will stay like this)
But the code behind will not evolve for 2.2. (only restricted for WP0 & WP16 navigation, which is still a good improvement)
The current WP structure is : WP_number (uint8_t) / LAT (int32_t) / LON (int32_t) / ALT (int16_t) / navflag (uint8_t)
is is not adapted for ALT (16bit)
I suggest to adapt it now with your suggestion:
WP_number (uint8_t) / LAT (int32_t) / LON (int32_t) / ALT (int32_t) / HEAD (int16_t) / TIME_to_stay in millis (uint16_t) / navflag (uint8_t)
Here is some idea about a simple automatic navigation after 2.2:
WP_number 0 is HOME
WP_number 16 is HOLD
for the other:
nav_flag is used to indicate the next WP_number (if nav_flag <=16)
nav_flag could be used for other purpose if nav_flag>16
setting the WP_number 1 will begin the automatic navigation
so you could imagine this example: an automatic navigation with 4 WP to set in this order:
WP 4 : navflag -> 0 (HOME)
WP 3 : navflag -> 4
WP 2 : navflag -> 3
WP 1 : navflag -> 2 <- to set at the end: activate the navigation (navigate toward WP1 and then toward the WP indicated by navflag)
the result would be: current pos -> WP1 -> WP 2 -> WP 3 -> WP4 -> HOME
You don't have to tell me that navigation is difficoult. I tried it once. I wrote a simple program to control a simulator http://www.youtube.com/watch?v=sLMnOVyAtKE
your proposition sounds good to me, it will require some more coding and smart interface but I think I can manage that.
16 wp points is more then enough in my opinion. (in future we can add more if we plan interstate flights)
In the future we can add new features like orbiting etc and use navflag to set it.
Bart
I've just adapted the struct in the last dev.
No more code behind for the moment, except this one easy to implement for testing:
It you set an altitude different than 0, the target altitude (in cm) can now be controlled via WP0 & WP16
Re: MultiWii EZ-GUI
I saw it. I'll implement it soon.
btw
When I use position hold ( or something else where GPS is involved) do I have to enable MAG too ?
Maybe we can make some documentation about multiwii which will be easy to read and understand, where we can explain what are the PID option how to tune it etc. Right now I can tune pitch and roll pid but I have very little idea how set the others and terms like Pos, PosR, NavR etc are not self explanatory. Maybe when we have a better documentation (for beginers) more people will swtich to MultiWii. We can start this from 2.2. I wanted to add to my app small "legend" with function name and what it does and how we use it but there is many aspects which even I don't know. Sorry for OT.
Thanks
Bart
btw
When I use position hold ( or something else where GPS is involved) do I have to enable MAG too ?
Maybe we can make some documentation about multiwii which will be easy to read and understand, where we can explain what are the PID option how to tune it etc. Right now I can tune pitch and roll pid but I have very little idea how set the others and terms like Pos, PosR, NavR etc are not self explanatory. Maybe when we have a better documentation (for beginers) more people will swtich to MultiWii. We can start this from 2.2. I wanted to add to my app small "legend" with function name and what it does and how we use it but there is many aspects which even I don't know. Sorry for OT.
Thanks
Bart
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
ezio wrote:I saw it. I'll implement it soon.
btw
When I use position hold ( or something else where GPS is involved) do I have to enable MAG too ?
Maybe we can make some documentation about multiwii which will be easy to read and understand, where we can explain what are the PID option how to tune it etc. Right now I can tune pitch and roll pid but I have very little idea how set the others and terms like Pos, PosR, NavR etc are not self explanatory. Maybe when we have a better documentation (for beginers) more people will swtich to MultiWii. We can start this from 2.2. I wanted to add to my app small "legend" with function name and what it does and how we use it but there is many aspects which even I don't know. Sorry for OT.
Thanks
Bart
Yes I know there is not enough doc for the moment
![Wink ;)](./images/smilies/icon_e_wink.gif)
It's something that we should clearly do to avoid configuration confusion.
For your specific question:
MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
Re: MultiWii EZ-GUI
maybe we can make questions and answers topic in the forum, then sum it together after some time to one nice manual.
Re: MultiWii EZ-GUI
Alexinparis wrote:For your specific question:
MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
So if I enable GPS navigation MAG will be "automagically" turn on too ? And I don't have to set it in BOXEs ?
Re: MultiWii EZ-GUI
Alexinparis wrote:MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
GPS navigation for planes _should_ be possible without a mag, because they are always moving and GPS can provide the direction they are moving towards. In 2.3 then
![Wink ;-)](./images/smilies/icon_e_wink.gif)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
ezio wrote:Alexinparis wrote:For your specific question:
MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
So if I enable GPS navigation MAG will be "automagically" turn on too ? And I don't have to set it in BOXEs ?
In fact the BOX MAG should not be called MAG, but HEADLOCK instead or something like this.
When activated, the multicopter will tend to follow exactly the heading orientation.
So it can be:
- considered as a standalone solution for a perfect HEADLOCK gyro
- or use via you apps to set a specific heading (with or without GPS)
But it is not mandatory for the GPS navigation, as the GPS function will automatically adjust the inclination taking account the orientation of the multicopter.
Re: MultiWii EZ-GUI
Alexinparis wrote:alexia wrote:it will be great if this apk support usb hsot for rctimer 433mhz module for long range
I think this topic is for you:
viewtopic.php?f=8&t=3101
You can already connect directly a bluetooth module with a 3DR module, or wait for the module I cook that could be used with a ppm input or independently.
Bluetooth works really fine on android phones. This is to my mind the only communication to support.
you are going to sell a module?if it s the case i prefer to wait
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Re: MultiWii EZ-GUI
I have tested follow Heading function and it seems to work. by the way it is buggy in current version of EZ-GUI ( it sends only 8bits insted of 16bits)
I don't know why there is a small angular offset. Maybe I'm sending something wrong. When I check the compass reading in MultiWii and the phone offset is there. No idea what cause it.
but I must say alt hold works perfectly this time![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
here is a video:
http://www.youtube.com/watch?v=psjvfKHpuSI
Alex could you verify if it is correct ?
public void SendRequestMSP_SET_HEAD(int heading) {
payload = new ArrayList<Character>();
payload.add((char) (heading & 0xFF));
payload.add((char) ((heading >> 8) & 0xFF));
sendRequestMSP(requestMSP(MSP_SET_HEAD, payload.toArray(new Character[payload.size()])));
}
Bart
I don't know why there is a small angular offset. Maybe I'm sending something wrong. When I check the compass reading in MultiWii and the phone offset is there. No idea what cause it.
but I must say alt hold works perfectly this time
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
here is a video:
http://www.youtube.com/watch?v=psjvfKHpuSI
Alex could you verify if it is correct ?
public void SendRequestMSP_SET_HEAD(int heading) {
payload = new ArrayList<Character>();
payload.add((char) (heading & 0xFF));
payload.add((char) ((heading >> 8) & 0xFF));
sendRequestMSP(requestMSP(MSP_SET_HEAD, payload.toArray(new Character[payload.size()])));
}
Bart
Re: MultiWii EZ-GUI
Offset could come from the really strong magnets in the motors which the phone is not calibrated for? Or do both (phone & copter) show the correct heading, but the copter wont match it exactly (like in the video)?
Re: MultiWii EZ-GUI
Sebbi wrote:Offset could come from the really strong magnets in the motors which the phone is not calibrated for? Or do both (phone & copter) show the correct heading, but the copter wont match it exactly (like in the video)?
well no
I verified it. and for example heading of phone was 90, value send to copter should be also 90, but the copter sets it self to ie 70. No idea why.
Maybe I'm sending something wrong.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii EZ-GUI
ezio wrote:I have tested follow Heading function and it seems to work. by the way it is buggy in current version of EZ-GUI ( it sends only 8bits insted of 16bits)
I don't know why there is a small angular offset. Maybe I'm sending something wrong. When I check the compass reading in MultiWii and the phone offset is there. No idea what cause it.
but I must say alt hold works perfectly this time
here is a video:
http://www.youtube.com/watch?v=psjvfKHpuSI
Alex could you verify if it is correct ?
public void SendRequestMSP_SET_HEAD(int heading) {
payload = new ArrayList<Character>();
payload.add((char) (heading & 0xFF));
payload.add((char) ((heading >> 8) & 0xFF));
sendRequestMSP(requestMSP(MSP_SET_HEAD, payload.toArray(new Character[payload.size()])));
}
Bart
Hi,
There is apparently a bug regarding the transmission of a signed 16 bit integer.
When angle is positive, it's ok.
When angle is negative, there is an offset.
I checked the 2 bytes sent.
And at least something seems to be wrong is the apps: range of angle is 360 units.
It can't fit inside 8 bits, and the second bytes is always 0 <- it shouldn't
A simple hack would consist in adding +360 when angle is negative, but it's not clean, we should find out why there is this bug.
Re: MultiWii EZ-GUI
Alexinparis wrote:ezio wrote:Alexinparis wrote:For your specific question:
MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
So if I enable GPS navigation MAG will be "automagically" turn on too ? And I don't have to set it in BOXEs ?
In fact the BOX MAG should not be called MAG, but HEADLOCK instead or something like this.
When activated, the multicopter will tend to follow exactly the heading orientation.
So it can be:
- considered as a standalone solution for a perfect HEADLOCK gyro
- or use via you apps to set a specific heading (with or without GPS)
But it is not mandatory for the GPS navigation, as the GPS function will automatically adjust the inclination taking account the orientation of the multicopter.
so maybe we could change the name of BOX MAG in version 2.2? to something like MAGHEADLOCK
what do you think?
Re: MultiWii EZ-GUI
Could everybody update the app to the newest version ?
Right now only 53% use latest version.
More than 10% uses very very old one.
Right now only 53% use latest version.
More than 10% uses very very old one.
-
- Posts: 20
- Joined: Tue Mar 20, 2012 1:56 am
Re: MultiWii EZ-GUI
Just tested latest version of EZ GUI and MW version 1349. Follow me, new home/hold position worked well although there were some issues;
1. In maps, home position doesn't appear anymore went selecting a new hold/home position
2. Followheading doesn't work in flight. It caused the copter to oscillate uncontrollably causing it to descend. To get out was to turn off the followheading, which is hard since attention is fixed on the copter OR turn off GPS hold.
Please also consider I was testing my hobbyking 915MHz 3DR setup (which may have affected followheading performance). 3DR also worked well. I just hacked the RX/TX of the bluetooth module to the 3DR board (in between the FTDI chip and rx/tx inductor ). Using 115k baud and 250k airspeed. Didn't do long range test since I was flying LOS. But is was a lot farther than using bluetooth with quarter wave antenna. I also used an OTG usb cable from my phone to power the ground module and bluetooth module.
Also, when I ground tested the 3DR setup few days ago, prior to the latest update, new home position (H) was appearing on the maps screen. I was a handy feature since I can confirm the two way communication between the 3DR modules. Now, even with just bluetooth, it doesn't appear anymore.
1. In maps, home position doesn't appear anymore went selecting a new hold/home position
2. Followheading doesn't work in flight. It caused the copter to oscillate uncontrollably causing it to descend. To get out was to turn off the followheading, which is hard since attention is fixed on the copter OR turn off GPS hold.
Please also consider I was testing my hobbyking 915MHz 3DR setup (which may have affected followheading performance). 3DR also worked well. I just hacked the RX/TX of the bluetooth module to the 3DR board (in between the FTDI chip and rx/tx inductor ). Using 115k baud and 250k airspeed. Didn't do long range test since I was flying LOS. But is was a lot farther than using bluetooth with quarter wave antenna. I also used an OTG usb cable from my phone to power the ground module and bluetooth module.
Also, when I ground tested the 3DR setup few days ago, prior to the latest update, new home position (H) was appearing on the maps screen. I was a handy feature since I can confirm the two way communication between the 3DR modules. Now, even with just bluetooth, it doesn't appear anymore.
Re: MultiWii EZ-GUI
MicroRaptor wrote:2. Followheading doesn't work in flight. It caused the copter to oscillate uncontrollably causing it to descend. To get out was to turn off the followheading, which is hard since attention is fixed on the copter OR turn off GPS hold.
This is buggy in current version because it sends only first 8bits of 16bit integer. It will be corrected in next release.
-
- Posts: 20
- Joined: Tue Mar 20, 2012 1:56 am
Re: MultiWii EZ-GUI
That was a quick reply Ezio.
Its still a great app BTW. It is so because you keep on improving it.
One more thing, with the extended range of the 3DR modules, it is hard to choose new home/hold position in the maps screen since it keeps on centering on the phone position. It also defaults to short range zoom setting.
Again, thanks for a marvelous app.
Its still a great app BTW. It is so because you keep on improving it.
One more thing, with the extended range of the 3DR modules, it is hard to choose new home/hold position in the maps screen since it keeps on centering on the phone position. It also defaults to short range zoom setting.
Again, thanks for a marvelous app.