GPS integration
Re: GPS integration
Ive got a flyduino mega v1.1 with 1280 chip and a fmp-04 gps module on serial 2, the gps works with the latest multiwii dev, my gps works on the NMEA protocol and the baud set to 38400bps
cheers
Gazza
cheers
Gazza
Re: GPS integration
I've got GPS working on Blackvortex board with Atmel 2560. It is a NEO-6Q Ublox GPS receiver.
I just configured like this in config.h MWII 1.8 by MichalM_sk:
So i get the GPS values displaying nicely on the GUI
I just configured like this in config.h MWII 1.8 by MichalM_sk:
Code: Select all
/* Serial GPS
only available on MEGA boards
if enabled, define here the Arduino Serial port number and the UART speed
note: only the RX PIN is used, the GPS is not configured by multiwii
the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices)
*/
#define GPS_SER
#define GPS_SERIAL Serial2 // should be Serial2 for flyduino v2 ... and it is for Blackvortex
#define GPS_BAUD 38400
So i get the GPS values displaying nicely on the GUI
- aBUGSworstnightmare
- Posts: 115
- Joined: Mon Jun 27, 2011 8:31 pm
- Location: Munich, Germany
Re: GPS integration
Hi there,
is there a version were I can configure my GPS with? The current gps.pde does not allow to send configuration messages to the GPS, so were to find one which can do this?
I'm working on a GPS BOB which I want to test with the MultiWii software. The module runs on 4800baud, sending NMEA messages. I want to increase the baud rate by sending the appropriate command.
Thanks for answering.
aBUGSworstnightmare
P.S. Here's a picture of my current dev (in progress). Sry, no details on the module at the moment
is there a version were I can configure my GPS with? The current gps.pde does not allow to send configuration messages to the GPS, so were to find one which can do this?
I'm working on a GPS BOB which I want to test with the MultiWii software. The module runs on 4800baud, sending NMEA messages. I want to increase the baud rate by sending the appropriate command.
Thanks for answering.
aBUGSworstnightmare
P.S. Here's a picture of my current dev (in progress). Sry, no details on the module at the moment
Re: GPS integration
I am ready to test GPS HOLD function with my multiwii octocopter, when it will be available?
-
- Posts: 38
- Joined: Tue Oct 11, 2011 1:42 pm
Re: GPS integration
any news about gps integration ?
HK gps with OSD have a good resolution ?
HK gps with OSD have a good resolution ?
Re: GPS integration
I don't like the idea of soft serial. I believe it takes too much CPU resource to do the UART simulation.
When flying, serial 0 is not in use. So I think sharing serial 0 with PC is a good idea.
When flying, serial 0 is not in use. So I think sharing serial 0 with PC is a good idea.
Re: GPS integration
Hi
And what about i2c modules, like this one:
http://www.dealextreme.com/p/eb-365-gps ... pset-80045
http://www.chinesegps.com/downloads/EB- ... 010719.pdf
regards,
ziss_dm
And what about i2c modules, like this one:
http://www.dealextreme.com/p/eb-365-gps ... pset-80045
http://www.chinesegps.com/downloads/EB- ... 010719.pdf
regards,
ziss_dm
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Hi,
Paul from Flyduino sent me a GPS bob to test with but I have some startup problems.
I use a FLyduino v2.1 and I am unsure which serial I have to use with the 20111029 DEV version,
I need to use the serial Port with RX3 TX3 written on it, because the bob does not have the smal gps connector yet.
Which serial port is that? Serial3?
Nils
ps.: GPS TX to Flyduino RX?
Paul from Flyduino sent me a GPS bob to test with but I have some startup problems.
I use a FLyduino v2.1 and I am unsure which serial I have to use with the 20111029 DEV version,
I need to use the serial Port with RX3 TX3 written on it, because the bob does not have the smal gps connector yet.
Which serial port is that? Serial3?
Nils
ps.: GPS TX to Flyduino RX?
- aBUGSworstnightmare
- Posts: 115
- Joined: Mon Jun 27, 2011 8:31 pm
- Location: Munich, Germany
Re: GPS integration
Hi there,
Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.
Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you choose
with def.h redefines this to
But, were in the code is GPSPRESENT and GPS_BAUD used so far???
MultiWii.pde only has
but were is GPS_SERIAL assigned?
Rgds
aBUGSworstnightmare
Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.
Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you choose
Code: Select all
/* GPS only available on MEGA boards (this might be possible on 328 based boards in the future) if enabled, define here the Arduino Serial port number and the UART speed note: only the RX PIN is used, the GPS is not configured by multiwii the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices) */ //#define GPS //#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2 //#define GPS_BAUD 4800 //#define GPS_BAUD 9600
with def.h redefines this to
Code: Select all
Def.h only gives
[code]#if defined(GPS) #define GPSPRESENT 1 #else #define GPSPRESENT 0 #endif [/code]
But, were in the code is GPSPRESENT and GPS_BAUD used so far???
MultiWii.pde only has
Code: Select all
#if defined(GPS) GPS_SERIAL.begin(GPS_BAUD); #endif
but were is GPS_SERIAL assigned?
Rgds
aBUGSworstnightmare
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi,
GPSPRESENT is used to set a bit in a variable (GUI communication) to indicate the presence of the GPS.
GPS_BAUD and GPS_SERIAL are defined in config.h and used in multiwii.pde
GPSPRESENT is used to set a bit in a variable (GUI communication) to indicate the presence of the GPS.
GPS_BAUD and GPS_SERIAL are defined in config.h and used in multiwii.pde
aBUGSworstnightmare wrote:Hi there,
Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.
Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you chooseCode: Select all
/* GPS only available on MEGA boards (this might be possible on 328 based boards in the future) if enabled, define here the Arduino Serial port number and the UART speed note: only the RX PIN is used, the GPS is not configured by multiwii the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices) */ //#define GPS //#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2 //#define GPS_BAUD 4800 //#define GPS_BAUD 9600
with def.h redefines this toCode: Select all
Def.h only gives
[code]#if defined(GPS) #define GPSPRESENT 1 #else #define GPSPRESENT 0 #endif [/code]
But, were in the code is GPSPRESENT and GPS_BAUD used so far???
MultiWii.pde only hasCode: Select all
#if defined(GPS) GPS_SERIAL.begin(GPS_BAUD); #endif
but were is GPS_SERIAL assigned?
Rgds
aBUGSworstnightmare
- aBUGSworstnightmare
- Posts: 115
- Joined: Mon Jun 27, 2011 8:31 pm
- Location: Munich, Germany
Re: GPS integration
Hi Alex,
yes, that's clear! But were can I see which hardware UART is associated to/with GPS_SERIAL label?
Rgds
aBUGSworstnightmare
yes, that's clear! But were can I see which hardware UART is associated to/with GPS_SERIAL label?
Rgds
aBUGSworstnightmare
Alexinparis wrote:Hi,
GPSPRESENT is used to set a bit in a variable (GUI communication) to indicate the presence of the GPS.
GPS_BAUD and GPS_SERIAL are defined in config.h and used in multiwii.pdeaBUGSworstnightmare wrote:Hi there,
Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.
Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you chooseCode: Select all
/* GPS only available on MEGA boards (this might be possible on 328 based boards in the future) if enabled, define here the Arduino Serial port number and the UART speed note: only the RX PIN is used, the GPS is not configured by multiwii the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices) */ //#define GPS //#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2 //#define GPS_BAUD 4800 //#define GPS_BAUD 9600
with def.h redefines this toCode: Select all
Def.h only gives
[code]#if defined(GPS) #define GPSPRESENT 1 #else #define GPSPRESENT 0 #endif [/code]
But, were in the code is GPSPRESENT and GPS_BAUD used so far???
MultiWii.pde only hasCode: Select all
#if defined(GPS) GPS_SERIAL.begin(GPS_BAUD); #endif
but were is GPS_SERIAL assigned?
Rgds
aBUGSworstnightmare
Re: GPS integration
Did you guy see any problem working the gps at 115200 on mega board?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
I tested it with 115200 on my flyduino, the data looked good, but I have not flown it yet...
Nils
Nils
Re: GPS integration
What about piping the NMEA-Frame delivered by I2C GOS Devices with UART-mimic?
Maybe the Fastrax IT 430 ?
something like :
&
roundabout...not tested..waiting for module but will have to switch with a I2C PCA.. least problem i think...
Maybe the Fastrax IT 430 ?
something like :
Code: Select all
const int WANTED_NUMBER = 67; // A usual GPGGA NMEA frame, 67 bytes including $;<CR>;<LF>
static uint8_t datastring [WANTED_NUMBER];
static uint32_t gpscycle;
Code: Select all
#if defined (SOME_GPS_I2C)
getData();
while (Wire.available()) {
if (GPS_newFrame(datastring [WANTED_NUMBER])){
if (GPS_update == 1) GPS_update = 0;
else GPS_update = 1;
if (GPS_fix == 1) {
if (GPS_fix_home == 0) {
GPS_fix_home = 1;
GPS_latitude_home = GPS_latitude;
GPS_longitude_home = GPS_longitude;
}
GPS_distance(GPS_latitude_home,GPS_longitude_home,GPS_latitude,GPS_longitude, &GPS_distanceToHome, &GPS_directionToHome);
}
}
}
&
Code: Select all
float getData ()
{
TWBR = ((16000000L / 400000L) - 16) / 2;
i2c_rep_start(0x60); //GPS sample I2c address
for (byte i = 0; i < WANTED_NUMBER; i++)
datastring [i] = i2c_readAck();
datastring [WANTED_NUMBER]= i2c_readNak();
return datastring[WANTED_NUMBER]; // maybe here we will need a terminating null
if ( (micros()-gpscycle ) < 250000 );
gpscycle = micros(); //250ms = 4Hz refresh;
getData();
}
roundabout...not tested..waiting for module but will have to switch with a I2C PCA.. least problem i think...
Re: GPS integration
Hi All,
I have hook a GPS to my Mega board yesterday.
Activate the code in config.h
The GPS look to work since the GUI tell me that i have setellites...
Picture of GUI
http://static.rcgroups.net/forums/attachments/1/7/6/6/8/9/a4427740-182-MultiWii%20-%20Arduino%20Mega%201280%20-%20GPS.png
I wonder how do i know if it work.. or if i have position data ?
I have hook a GPS to my Mega board yesterday.
Activate the code in config.h
Code: Select all
#define GPS
#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2
#define GPS_BAUD 4800
The GPS look to work since the GUI tell me that i have setellites...
Picture of GUI
http://static.rcgroups.net/forums/attachments/1/7/6/6/8/9/a4427740-182-MultiWii%20-%20Arduino%20Mega%201280%20-%20GPS.png
I wonder how do i know if it work.. or if i have position data ?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
If you have satellites: It works.
-
- Posts: 702
- Joined: Sun Aug 28, 2011 8:14 pm
- Contact:
Re: GPS integration
Hi, is there any news about promini integration? I would like to have one on my Paris v4 board!
Re: GPS integration
Hi guys, I need GPS Position hold for making aerial panoramas. Here you can see my albums.
http://caseta.ro/html/fotografie_aeriana.html
http://caseta.ro/html/fotografie_aeriana.html
Re: GPS integration
I need a Ferrari...!
-
- Posts: 702
- Joined: Sun Aug 28, 2011 8:14 pm
- Contact:
Re: GPS integration
dialfonzo wrote:I need a Ferrari...!
First the position hold then the Ferrari, one thing at a time!
Re: GPS integration
kataventos wrote:dialfonzo wrote:I need a Ferrari...!
First the position hold then the Ferrari, one thing at a time!
LOL..
Re: GPS integration
I started dreaming at GPS position hold for a while. Please Santa, upload the CODE!
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi,
I uploaded yesterday a dev snapshot with some GPS dev.
The GPS return to home function is coded.
Not yet tested, but in progress.
I uploaded yesterday a dev snapshot with some GPS dev.
The GPS return to home function is coded.
Not yet tested, but in progress.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
I like!!
Will test it asap
Will test it asap
Re: GPS integration
AHRG!
Great! Are there any wiring howtos for gps modules around? Am i limited to some special hardware?
greetings
Noctaro
Great! Are there any wiring howtos for gps modules around? Am i limited to some special hardware?
greetings
Noctaro
-
- Posts: 702
- Joined: Sun Aug 28, 2011 8:14 pm
- Contact:
Re: GPS integration
Hi Alex,
great! Any news on promini? I think that exist some kind of "breakout" board that is able to convert serial to i2C! is that it? where can I find this and does it realy work?
Cheers,
Henrique
great! Any news on promini? I think that exist some kind of "breakout" board that is able to convert serial to i2C! is that it? where can I find this and does it realy work?
Cheers,
Henrique
Re: GPS integration
Found a little Typo
Could not get it to work with serialport 3
Should be if you want to switch port in config.
Now it's running smooth on the table.
Will test when it's not snowing so much..
/Patrik
Could not get it to work with serialport 3
Code: Select all
while (SerialAvailable(2)) {
if (GPS_newFrame(SerialRead(2))) {
Should be if you want to switch port in config.
Code: Select all
while (SerialAvailable(GPS_SERIAL)) {
if (GPS_newFrame(SerialRead(GPS_SERIAL))) {
Now it's running smooth on the table.
Will test when it's not snowing so much..
/Patrik
Re: GPS integration
hi
a small question
is it possible to assign an output-pin if having a gps-link?
i think it is not bad to have a led when there are enough satelites.
a small question
is it possible to assign an output-pin if having a gps-link?
i think it is not bad to have a led when there are enough satelites.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi,
Currently, there is a change of the status LED when a fix is obtained
When the motors are not armed, the status LED should stay off.
Once the fix is ok, there is a specific blink pattern.
Currently, there is a change of the status LED when a fix is obtained
When the motors are not armed, the status LED should stay off.
Once the fix is ok, there is a specific blink pattern.
Re: GPS integration
Today I just crushed my octo and it will take me some time to fix it, i am sorry that i can't do the tests.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi,
Just some precisions about the current GPS dev code:
1) hardware setup:
An arduino mega (might change in the future for a promini, but not yet) with the GPS connected on serial port 2 (customizable, but with the typo correction just mentionned by PatrikE). I'm currently using the flyduino MEGA.
You must configure the right baud speed of the GPS port according to your GPS device. (#define GPS + #define GPS_SERIAL 2 + #define GPS_BAUD 115200)
You need a NMEA GPS compatible (most serial GPS are compatible). Currently multiwii does not configure the GPS device (will change in the future). So your GPS device must be already configured to output these frames. A 5 or 10Hz is preferable. This update rate is not configurable inside multiwii, multiwii takes what it receives. I'm now using the 10Hz FMP04 GPS with the GPS BOB from flyduino.
All the sensors GYRO+ACC+MAG are mandatory. Your multi must be perfectly tuned in level and heading (mag) mode. Your mag direction should not be altered by running motors (this point is very important). Your MAG arrow must point the north direction.
Baro is not mandatory, but a working baro config in preferable.
2) visualization
If the GPS is correctly connected and configured. You should see the GPS blinking in the GUI (around the grey rosace N/S/E/W in the GUI) according to its update rate.
A specific Status LED blink pattern occurs when motors are disarmed and once a fix is ok.
Once a fix is ok, you should see the number of satellites and the distance to the first fix position (home) in the GUI.
3) activating the GPS
The GPS must be activated (via checkbox and AUX configuration) only if a fix is ok. The home will be set with the first fix.
The GPS can be only activated if level mode if also activated. (MAG mode activation or BARO mode activation are not mandatory)
The current implementation only supports Return To Home function (PH will be easy to add)
Once activated, the GPS will rely on 3 parameters to work
distance to the target point (calculation obtained from GPS device)
absolute direction to the target point (calculation obtained from GPS device)
heading direction (calculation obtained from MAG+ACC device)
The target point distance is used to determine an angle inclination.
A PID has been added to the GUI, but it's not currently a real PID.
P is used to tune the proportion of inclination regarding the distance to the target point.
I is not used
D is used to limit the max inclination
The combination of direction to the target point+heading direction is used to apply a mix on the motors to follow the right direction.
Just some precisions about the current GPS dev code:
1) hardware setup:
An arduino mega (might change in the future for a promini, but not yet) with the GPS connected on serial port 2 (customizable, but with the typo correction just mentionned by PatrikE). I'm currently using the flyduino MEGA.
You must configure the right baud speed of the GPS port according to your GPS device. (#define GPS + #define GPS_SERIAL 2 + #define GPS_BAUD 115200)
You need a NMEA GPS compatible (most serial GPS are compatible). Currently multiwii does not configure the GPS device (will change in the future). So your GPS device must be already configured to output these frames. A 5 or 10Hz is preferable. This update rate is not configurable inside multiwii, multiwii takes what it receives. I'm now using the 10Hz FMP04 GPS with the GPS BOB from flyduino.
All the sensors GYRO+ACC+MAG are mandatory. Your multi must be perfectly tuned in level and heading (mag) mode. Your mag direction should not be altered by running motors (this point is very important). Your MAG arrow must point the north direction.
Baro is not mandatory, but a working baro config in preferable.
2) visualization
If the GPS is correctly connected and configured. You should see the GPS blinking in the GUI (around the grey rosace N/S/E/W in the GUI) according to its update rate.
A specific Status LED blink pattern occurs when motors are disarmed and once a fix is ok.
Once a fix is ok, you should see the number of satellites and the distance to the first fix position (home) in the GUI.
3) activating the GPS
The GPS must be activated (via checkbox and AUX configuration) only if a fix is ok. The home will be set with the first fix.
The GPS can be only activated if level mode if also activated. (MAG mode activation or BARO mode activation are not mandatory)
The current implementation only supports Return To Home function (PH will be easy to add)
Once activated, the GPS will rely on 3 parameters to work
distance to the target point (calculation obtained from GPS device)
absolute direction to the target point (calculation obtained from GPS device)
heading direction (calculation obtained from MAG+ACC device)
The target point distance is used to determine an angle inclination.
A PID has been added to the GUI, but it's not currently a real PID.
P is used to tune the proportion of inclination regarding the distance to the target point.
I is not used
D is used to limit the max inclination
The combination of direction to the target point+heading direction is used to apply a mix on the motors to follow the right direction.
Re: GPS integration
Thanks Alex for this masterpice of software!
My copter has GPS now and it seems to work fine. (flyduino Mega with FMP04 GPS from Paul)
Will it be possible in future to reset the home-point an set a new one without power down the copter?
My copter has GPS now and it seems to work fine. (flyduino Mega with FMP04 GPS from Paul)
Will it be possible in future to reset the home-point an set a new one without power down the copter?
Re: GPS integration
mbrak wrote:Will it be possible in future to reset the home-point an set a new one without power down the copter?
It should be easy to do it now to..
Code: Select all
#if defined(GPS)
if ( (GPSModeHome == 1) && ( GPS_fix_home == 1)) {
float radDiff = (GPS_directionToHome-heading) * 0.0174533f;
GPS_angle[ROLL] = constrain(P8[PIDGPS] * sin(radDiff) * GPS_distanceToHome / 10,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // with P=5, 1 meter = 0.5deg inclination
GPS_angle[PITCH] = constrain(P8[PIDGPS] * cos(radDiff) * GPS_distanceToHome / 10,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // max inclination = D deg
} else {
GPS_angle[ROLL] = 0;
GPS_angle[PITCH] = 0;
GPS_fix_home =0
}
#endif
If you set GPS_fix_home =0 when GPSModeHome isn't active it vill take a new position and use it as home when GPSModeHome is Reactivated.
Re: GPS integration
I tested R426 software with GPS return to home.
http://www.youtube.com/watch?v=CpmluiZ_044
Mag was calibrated and checked in GUI, level mode working and GPS fix available because status led was blinking fast.
When activated GPS return to home, i programmed to activate the buzzer .
The results are not conclusive, i think something gone wrong because the quad is not going in right direction, but also CF mode was not working. Strange because i calibrated and checked the mag and on previous version, one day before, the CF mode was working well.
Also i observed short bursts of yaw when mag was active in Head hold.
http://www.youtube.com/watch?v=CpmluiZ_044
Mag was calibrated and checked in GUI, level mode working and GPS fix available because status led was blinking fast.
When activated GPS return to home, i programmed to activate the buzzer .
The results are not conclusive, i think something gone wrong because the quad is not going in right direction, but also CF mode was not working. Strange because i calibrated and checked the mag and on previous version, one day before, the CF mode was working well.
Also i observed short bursts of yaw when mag was active in Head hold.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi dramida,
The CF (HeadFree) mode should work perfectly before testing the GPS, because the GPS will rely on the magnetic orientation.
Your mag is working well on the bench, but could you confirm it works also when the motors are running ?
I suspect some magnetic noise coming from ESCs or motors, and leading to a wrong heading information.
The CF (HeadFree) mode should work perfectly before testing the GPS, because the GPS will rely on the magnetic orientation.
Your mag is working well on the bench, but could you confirm it works also when the motors are running ?
I suspect some magnetic noise coming from ESCs or motors, and leading to a wrong heading information.
Re: GPS integration
hi
i tested the dev 20111220 today. the mag was well calibrated and the gui values good. the hf-mode was not working correctly! at yaw angles<90 degrees it worked fine but >90 degrees to the start orientation the copter was flying in other directions but not in that, i would like to have him.
after that i did not test gps.
what can we do in case of magnetic interference? any solutions?
i tested the dev 20111220 today. the mag was well calibrated and the gui values good. the hf-mode was not working correctly! at yaw angles<90 degrees it worked fine but >90 degrees to the start orientation the copter was flying in other directions but not in that, i would like to have him.
after that i did not test gps.
what can we do in case of magnetic interference? any solutions?
Re: GPS integration
My tests were faulty because magnetometer goes crazy when motors are over 50% or more. I saw this behaviour on GUI wile holding in my hand with engines powered. So until the mag stays on position at any power, i cannot conclude about soft.
Re: GPS integration
Hi
my tests have the same result as that of dramida. MAG is going crazy over all 3 axis as soon as more like hover-throttle(aprox. 40%) is present.
motors : T-Motor2216/KV900 10x4.7 CF with robbe roxxy bl820 ESC
i increased the space between IMU (10 DOF AllinOne / Ebay from CSG_EU) and frame with powerlines (flyduino quadframe) up to 15mm. next test will show the result.
After increasing space the MAG is now more softly! much better than before!
Will do some testing tomorrow if there is no rain.....
my tests have the same result as that of dramida. MAG is going crazy over all 3 axis as soon as more like hover-throttle(aprox. 40%) is present.
motors : T-Motor2216/KV900 10x4.7 CF with robbe roxxy bl820 ESC
i increased the space between IMU (10 DOF AllinOne / Ebay from CSG_EU) and frame with powerlines (flyduino quadframe) up to 15mm. next test will show the result.
After increasing space the MAG is now more softly! much better than before!
Will do some testing tomorrow if there is no rain.....
Re: GPS integration
Can you try shielding things to verify it is the motors and mot ESC's that causes MAG errors?
//UndCon
//UndCon
Re: GPS integration
UndCon wrote:Can you try shielding things to verify it is the motors and mot ESC's that causes MAG errors?
//UndCon
Magnetic shielding you mean? what exactly do you think?
I should try to shield the electromagnetic compatibility of the ESC? how?
Re: GPS integration
Today i repeated the tests with magnetometer elevated from its board position at about 10 cm.
The results you see here: http://www.youtube.com/watch?v=N38oGaBj7Xs
The results you see here: http://www.youtube.com/watch?v=N38oGaBj7Xs
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi dramida,
We can see in your video that Headfree mode does not work as expected. (sometime yes, sometime no)
I think we should work on this issue before trying to activate the GPS.
Does the mag arrow indicate the north ?
Headfree was reporting to work on some setup, it's maybe a version problem ?
If you want to test the GPS without solving this issue, I can maybe make a specific version assuming you activate the GPS only when the nose of your quad points the north.
We can see in your video that Headfree mode does not work as expected. (sometime yes, sometime no)
I think we should work on this issue before trying to activate the GPS.
Does the mag arrow indicate the north ?
Headfree was reporting to work on some setup, it's maybe a version problem ?
If you want to test the GPS without solving this issue, I can maybe make a specific version assuming you activate the GPS only when the nose of your quad points the north.
Re: GPS integration
Hi Alex, now i can fly in care free mode with R426 code, same code i used in previous two tests. All i did was to elevate the mag 5883L at about 17 Cm above power distribution conductors. This is the advantage of individual sensors and a DIY TTH board.
Curiously, i tried to activate gps return to home last flight but i couldn't get the GPS FIX light. In the GUI the mag circle is flashing as it receives data from gps. I have to investigate further. I'll keep you updated.
Happy new year!
/Mihai
Curiously, i tried to activate gps return to home last flight but i couldn't get the GPS FIX light. In the GUI the mag circle is flashing as it receives data from gps. I have to investigate further. I'll keep you updated.
Happy new year!
/Mihai
Re: GPS integration
hi
that sounds good dramida. but i don't think it is a practicable solution to elevate the mag for about 17cm. i have the same problems with my mag and i can't elevate the sensor because i have all sensors on the imu board.
the microcopter has the same function called headfree. and they solved it without evelate the mag i think! the microcopter board would produce the same amount of magnetic interference as the multiwii board. or not?
#alex could we filter the inputs of the mag to make it more smooth? maybe the same procedure as with the gyro?
that sounds good dramida. but i don't think it is a practicable solution to elevate the mag for about 17cm. i have the same problems with my mag and i can't elevate the sensor because i have all sensors on the imu board.
the microcopter has the same function called headfree. and they solved it without evelate the mag i think! the microcopter board would produce the same amount of magnetic interference as the multiwii board. or not?
#alex could we filter the inputs of the mag to make it more smooth? maybe the same procedure as with the gyro?
Re: GPS integration - Working
Hi !
Today I tested the GPS RTH mode. And I can confirm that it's working...
There is one bug in the code which must be corrected.. the orientation of the Pitch and Roll corrections are wrong, but changing the following line fixes it...
In MultiWii.ino change this
to this
The GPS I used is a MTK chipset LS20033 set for 5Hz update rate at 115200 bps.
Gyro : ITG3205, Acc: BMA150 with 8G setting, Mag: HMC5883L, Baro: BMP085
(Just to note, RTH tests were done in Alt hold mode.... which is working perfectly...)
Things to improve :
1. DO not trust the position when GPS is got its fix, move home position setting to an aux switch or store home position when arming. (The received position could change significantly after the first fix)
(for a quick fix I added AUX4 high position to store home position.)
change this line
to this
2. Add magnetic inclination to the mag hold calculations, this will reduce the diameter of the circles around home position. (will do that)
3. Add a PID contoller to the gps calculations, so it will not overshoot when coming home from long distances with max RTH speed. (will try but, perhaps a little help needed)
4. Just for showing off, turn the copter's head towards the home position when RTH (will do that)
Here is the video of the test...http://www.youtube.com/watch?v=pJJKG6uWqv4
Today I tested the GPS RTH mode. And I can confirm that it's working...
There is one bug in the code which must be corrected.. the orientation of the Pitch and Roll corrections are wrong, but changing the following line fixes it...
In MultiWii.ino change this
Code: Select all
errorAngle = constrain(2*rcCommand[axis] + GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
to this
Code: Select all
errorAngle = constrain(2*rcCommand[axis] - GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
The GPS I used is a MTK chipset LS20033 set for 5Hz update rate at 115200 bps.
Gyro : ITG3205, Acc: BMA150 with 8G setting, Mag: HMC5883L, Baro: BMP085
(Just to note, RTH tests were done in Alt hold mode.... which is working perfectly...)
Things to improve :
1. DO not trust the position when GPS is got its fix, move home position setting to an aux switch or store home position when arming. (The received position could change significantly after the first fix)
(for a quick fix I added AUX4 high position to store home position.)
change this line
Code: Select all
if (GPS_fix_home == 0) {
to this
Code: Select all
if (rcData[AUX4]>1800) {
2. Add magnetic inclination to the mag hold calculations, this will reduce the diameter of the circles around home position. (will do that)
3. Add a PID contoller to the gps calculations, so it will not overshoot when coming home from long distances with max RTH speed. (will try but, perhaps a little help needed)
4. Just for showing off, turn the copter's head towards the home position when RTH (will do that)
Here is the video of the test...http://www.youtube.com/watch?v=pJJKG6uWqv4
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
waouh !
Thank you so much for this feedback
It's a nice way to begin the year.
1) I think a small timer once the first fix is ok should be added, or maybe some averaging on 10 or 20 positions.
2) and 3) To you think the circle are caused by heading inaccuracy ? I would say it's more due to the GPS correction which is currently very simple.
Once the target GPS position is achieved, the multi will continue to drift a little with the current implementation.
A full PID could maybe do the job.
4) for inflight visual debugging purpose ?
Thank you so much for this feedback
It's a nice way to begin the year.
1) I think a small timer once the first fix is ok should be added, or maybe some averaging on 10 or 20 positions.
2) and 3) To you think the circle are caused by heading inaccuracy ? I would say it's more due to the GPS correction which is currently very simple.
Once the target GPS position is achieved, the multi will continue to drift a little with the current implementation.
A full PID could maybe do the job.
4) for inflight visual debugging purpose ?
Re: GPS integration
Alexinparis wrote:waouh !
Thank you so much for this feedback
It's a nice way to begin the year.
1) I think a small timer once the first fix is ok should be added, or maybe some averaging on 10 or 20 positions.
2) and 3) To you think the circle are caused by heading inaccuracy ? I would say it's more due to the GPS correction which is currently very simple.
Once the target GPS position is achieved, the multi will continue to drift a little with the current implementation.
A full PID could maybe do the job.
4) for inflight visual debugging purpose ?
Hi Alex,
First, Happy New Year to You !
1. Timer is OK, I just got the idea from the arducopter, which sets the home position when copter is armed..., but a timer will also do the trick. Averaging is not a good idea, perhaps it's worth to wait for 3D fix and not for 2D fix. (Checking GSA sentences from gps)
2,3. I checked the heading inaccuracy and it definitely there, again experiences from arducopter, without accurate mag orientation you will got circles in pos hold... will try to implement it and post the results... I think the current gps pos correction is simple but very elegant. A PID loop could improve it, but don't overengineer it..
4. Visual debugging, and for coolness factor.. it's cool and frightening when you flip a switch and the copter turns to a new direction and starts fly there. (This will be a perfect function for waypoint navigation, which is the next logical step.)
Regards,
Andras
Re: GPS integration
hi Andras
what imu or mag sensor do you use?
do you have flat mag-lines in gui when power on motors >30%
what esc and motors do you use?
thx michael
what imu or mag sensor do you use?
do you have flat mag-lines in gui when power on motors >30%
what esc and motors do you use?
thx michael
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Hi all,
good to hear about the gps solutions taking shape .
I am stuck with my shitty bma020 and my mag.
I have the z problem so I ordered a bma180 and hopefully this will fix the problem with AccZ.
The more serious problem in my opinion is the faulty behavior of my mag (HMC5883) I monted it next to the Gyro beneath the Flyduino board ontop of my centerplate.
Beneath the centerplate I mounted the escs the lipo and beneath the lipo there is the power distribution.
I have exactly the same problem dramida mentioned.
I first noticed that when I tried some altitude hold and direction hold, when I throttle up the copter yaws like crazy.
I am still not sure what is causing this EMV from the wires LIPO->ESC or ESC->Motor or is there a frequency in the whole system that influences the mag?
I will try to shield the mag with a faraday cage.
I agree, that it is very annoying to place the mag way above the copter (think of crashing) How do the guys at mikrokopter do it??
Nils
good to hear about the gps solutions taking shape .
I am stuck with my shitty bma020 and my mag.
I have the z problem so I ordered a bma180 and hopefully this will fix the problem with AccZ.
The more serious problem in my opinion is the faulty behavior of my mag (HMC5883) I monted it next to the Gyro beneath the Flyduino board ontop of my centerplate.
Beneath the centerplate I mounted the escs the lipo and beneath the lipo there is the power distribution.
I have exactly the same problem dramida mentioned.
I first noticed that when I tried some altitude hold and direction hold, when I throttle up the copter yaws like crazy.
I am still not sure what is causing this EMV from the wires LIPO->ESC or ESC->Motor or is there a frequency in the whole system that influences the mag?
I will try to shield the mag with a faraday cage.
I agree, that it is very annoying to place the mag way above the copter (think of crashing) How do the guys at mikrokopter do it??
Nils
Re: GPS integration
Hi !
It's a bunch of self made blobs... as I wrote. ITG3205 from a WMP clone (Wired directly) BMA150 salvaged from a broken smartphone. (It's basically the same as the BMA020), a BMP085 baro and a HMC5883L wired on a selfmade test board. FC is a selfmade ATMega2560 board, which is nothing more than a ArduinoMega but on a 10x10 board. Mag-lines are flat even at full throttle.
ESC's are Hobbyking Blue Series 20A, flashed with ziss_dm magnificant firmware (200step-normal pwm) motors are Dt750 with replaced high quality bearings. Prpps are GWS 3 blade 10x6.
Frame is based on the tricopter v2.5 from rcexplorer.se http://rcexplorer.se/projects/tricopter ... erv25.html the only significant difference, that I did not remove the copper foil from the PCB materials used for the frame. Since all power wires are routed between the two base plates, this provide a good shiled from emf interference. ESC's are attached to the arms, in a safe distance from magnetometer.
The GPS is enclosed in a plastic blob, and elevated about 15cm on a carbon fiber rod, and connected to the FC via a shielded cable).
Regards,
Bandi
It's a bunch of self made blobs... as I wrote. ITG3205 from a WMP clone (Wired directly) BMA150 salvaged from a broken smartphone. (It's basically the same as the BMA020), a BMP085 baro and a HMC5883L wired on a selfmade test board. FC is a selfmade ATMega2560 board, which is nothing more than a ArduinoMega but on a 10x10 board. Mag-lines are flat even at full throttle.
ESC's are Hobbyking Blue Series 20A, flashed with ziss_dm magnificant firmware (200step-normal pwm) motors are Dt750 with replaced high quality bearings. Prpps are GWS 3 blade 10x6.
Frame is based on the tricopter v2.5 from rcexplorer.se http://rcexplorer.se/projects/tricopter ... erv25.html the only significant difference, that I did not remove the copper foil from the PCB materials used for the frame. Since all power wires are routed between the two base plates, this provide a good shiled from emf interference. ESC's are attached to the arms, in a safe distance from magnetometer.
The GPS is enclosed in a plastic blob, and elevated about 15cm on a carbon fiber rod, and connected to the FC via a shielded cable).
Regards,
Bandi