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.
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.
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
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
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
And as I said earlier all waypoint staff has to be rethinked and change to match current needs.
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
alexia wrote:how can i add me on mappy communauty?
this apk is wonderful
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
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.
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
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.
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.
alexia wrote:it will be great if this apk support usb hsot for rctimer 433mhz module for long range
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?!
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
alexia wrote:it will be great if this apk support usb hsot for rctimer 433mhz module for long range
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
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
Alexinparis wrote:For your specific question:
MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
Alexinparis wrote:MAG sensor is mandatory for GPS navigation
but MAG activation is not mandatory for GPS navigation
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 ?
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.
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)?
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
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.
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.
Return to Software development
Users browsing this forum: No registered users and 1 guest