MultiWii

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.

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

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

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

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

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.

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

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.

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

@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.

Yes I know. But he is no active any more.

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. :(:(

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

how can i add me on mappy communauty?
this apk is wonderful

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

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

@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.

Why don't you set navflag as int and make hold flag =-1? This way you can use any amount of waypoints

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.

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

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.

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

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.

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

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

it will be great if this apk support usb hsot for rctimer 433mhz module for long range

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

I understand that and you are right.
Despite this, you apk is Perfect.

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?!

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

i think it s not a necessary because we can connect bluethoot on 433mhz module,
before we need to tune baud rate

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.

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.

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

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

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
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

maybe we can make questions and answers topic in the forum, then sum it together after some time to one nice manual.

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 ?

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

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.

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

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

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)?

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.

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.

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?

Could everybody update the app to the newest version ?

Right now only 53% use latest version.
More than 10% uses very very old one.

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.

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.

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.