GPS integration
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi,
It think it's important to proceed step by step
Before working on other combos than MEGA+serial GPS, my aim is to bring a working GPS code.
according to EOSBandi video, we are not too far form this aim.
We can still have many ideas besides :
- a 328p is definitively powerful enough (speed and ram size) to handle GPS data + 10DOF sensors
- I2C GPS is a good solution:
* either in a transparent way (where the slave device does nothing more than translating serial to I2C data)
* or in a offload way (where the slave device could compute some GPS things)
* this should allow to see very cheap GPS FC solutions
It think it's important to proceed step by step
Before working on other combos than MEGA+serial GPS, my aim is to bring a working GPS code.
according to EOSBandi video, we are not too far form this aim.
We can still have many ideas besides :
- a 328p is definitively powerful enough (speed and ram size) to handle GPS data + 10DOF sensors
- I2C GPS is a good solution:
* either in a transparent way (where the slave device does nothing more than translating serial to I2C data)
* or in a offload way (where the slave device could compute some GPS things)
* this should allow to see very cheap GPS FC solutions
- NikTheGreek
- Posts: 348
- Joined: Thu Dec 08, 2011 4:17 pm
- Location: Greece
- Contact:
Re: GPS integration
I know that probably i ' m the last one that i sould speak about this since i'm totaly new and unexperienced .
On the other hand i think it wont harm iff i say my opinion.
So far you have done exelent job with the Multiwii code.
Seems that working perfectly without significant problems(pls correct me if i'm wrong)
NOW you want to "add" some new features like GPS guidance - data recordings..etc...right ?
From my point of view i think that is much better to keep the two "projects" separate. but at the same time working together.
How can be done ?
By adding a new board that will take signals from the RC receiver - calculate the GPS readings and waypoints - and then produce encoded signals ( one pin) in order to feed the second board exactly the same way you are doing now.
The first board...lets say it GPS Guidance Module ... needs only additionaly a magnetometer in order to produce the correct signnals....right ?
This way the user..like me .. will be able to fly his "plane" with the basic features using the basic module and whenever he likes to advance by adding the second GGM module.
The additional cost is insignificant since with 10-20$ you can build a simple arduino .
I hope that you ll forgive me if i said something wrong.. and i hope to understand what i'm trying to say.
On the other hand i think it wont harm iff i say my opinion.
So far you have done exelent job with the Multiwii code.
Seems that working perfectly without significant problems(pls correct me if i'm wrong)
NOW you want to "add" some new features like GPS guidance - data recordings..etc...right ?
From my point of view i think that is much better to keep the two "projects" separate. but at the same time working together.
How can be done ?
By adding a new board that will take signals from the RC receiver - calculate the GPS readings and waypoints - and then produce encoded signals ( one pin) in order to feed the second board exactly the same way you are doing now.
The first board...lets say it GPS Guidance Module ... needs only additionaly a magnetometer in order to produce the correct signnals....right ?
This way the user..like me .. will be able to fly his "plane" with the basic features using the basic module and whenever he likes to advance by adding the second GGM module.
The additional cost is insignificant since with 10-20$ you can build a simple arduino .
I hope that you ll forgive me if i said something wrong.. and i hope to understand what i'm trying to say.
-
- Posts: 178
- Joined: Fri Apr 01, 2011 10:32 pm
- Location: Czech Republic, Prague
Re: GPS integration
Alexinparis wrote:Hi,
It think it's important to proceed step by step
Before working on other combos than MEGA+serial GPS, my aim is to bring a working GPS code.
according to EOSBandi video, we are not too far form this aim.
We can still have many ideas besides :
- a 328p is definitively powerful enough (speed and ram size) to handle GPS data + 10DOF sensors
- I2C GPS is a good solution:
* either in a transparent way (where the slave device does nothing more than translating serial to I2C data)
* or in a offload way (where the slave device could compute some GPS things)
* this should allow to see very cheap GPS FC solutions
Sorry for maybe stupid questions but I want to completely understand alex's post.
-What is ment 10DOF sensors, does it mean ONLY 10DOF or any supported set of gyro, acc, mag and baro + GPS wil work?
-What means GPS FC solution? (I can't find what is it).
-Additionally - is it expeted to support even faster GPS modules (like "to listen" GPS NMEA parallel at input of Remzibi OSD 38400bps, 5Hz)? Will there be enough processing time?
Thanks!
Roman
Re: GPS integration
Ok Guys,
It was a long weekend but finally it’s working (at least on the desk with GPS simulator).
It’s a standalone I2C GPS and NAV module which can offload navigational calculations from the main FC. After a waypoint is set and activated, the Multiwii FC only needs to read the distance and direction from the I2CGPS. Navigation can be suspended for holding current position and resumed later, by a simple command. The module can store up to 15 waypoints, and it’s also can give back gps speed, altitude and time if requested by the FC. Since calculation speed is not a real issue, I increased the precision for position calculation it’s 1/10 000 000 instead of 1/100 000. According to my test, the lower precision caused +/-5M errors in distance calculations in short ranges. Future plans are to add cross track error calculations and wind estimation, and eventually a pid controller for pos hold and waypoint nav.
The attached zip file contains the arduino sketch for the module. You can use a normal arduino nano or mini, GPS connected to the serial port, I2c connected to the 5V i2c bus on the FC. GPS must be configured for NMEA protocol at 115200 baud. GPGGA, GPGSA and GPRMC frames are decoded, but It’s easy to extend the decoder part. You can also find a TWI part of the Wire library in the zip file, this must be placed into the libraries/wire/utilities folder because the actual version of the Wire library does not handle repeated start in Slave mode. (this one does)
In Multiwii I implemented only the basic gps functionality. Home position is set when a 3d fix is reached, and when RTH is activated it comes back to the home position. If it works then I will go after the fancy parts.
Code now lives at http://code.google.com/p/i2c-gps-nav/ please go there and use the latest
It was a long weekend but finally it’s working (at least on the desk with GPS simulator).
It’s a standalone I2C GPS and NAV module which can offload navigational calculations from the main FC. After a waypoint is set and activated, the Multiwii FC only needs to read the distance and direction from the I2CGPS. Navigation can be suspended for holding current position and resumed later, by a simple command. The module can store up to 15 waypoints, and it’s also can give back gps speed, altitude and time if requested by the FC. Since calculation speed is not a real issue, I increased the precision for position calculation it’s 1/10 000 000 instead of 1/100 000. According to my test, the lower precision caused +/-5M errors in distance calculations in short ranges. Future plans are to add cross track error calculations and wind estimation, and eventually a pid controller for pos hold and waypoint nav.
The attached zip file contains the arduino sketch for the module. You can use a normal arduino nano or mini, GPS connected to the serial port, I2c connected to the 5V i2c bus on the FC. GPS must be configured for NMEA protocol at 115200 baud. GPGGA, GPGSA and GPRMC frames are decoded, but It’s easy to extend the decoder part. You can also find a TWI part of the Wire library in the zip file, this must be placed into the libraries/wire/utilities folder because the actual version of the Wire library does not handle repeated start in Slave mode. (this one does)
In Multiwii I implemented only the basic gps functionality. Home position is set when a 3d fix is reached, and when RTH is activated it comes back to the home position. If it works then I will go after the fancy parts.
Code now lives at http://code.google.com/p/i2c-gps-nav/ please go there and use the latest
Last edited by EOSBandi on Sun Feb 05, 2012 1:20 am, edited 6 times in total.
Test on Pro mini.
Hi,
Today I run first test on my custom board with Atmega 328.
my sensor setup is:
- L3G4200D
- ADXL345
- HMC5883
-BMP085
- and Mediatek GPS Gms‐u1LP - 10Hz + 115200 baud with custom firmware from GlobalTop.
http://download.maritex.com.pl/pdfs/wi/GPS-GMS-U1LP.pdf
First I've made some changes to get it work on Atmegs328. I decide to create detecting procedure at startup. If MWC receive NMEA frames in first two seconds I set flag GPSdetected, then use this flag to dissable qui and enable GPS transmition. If I don't miss anything here are all changes:
Then I setup PID's for GPS: P=5 and D=5
Then I go outside. First I test head free mode and it works fine. Compass was tested using classic compass before and it show North correctly. then I fly forward me so about 20m and enable RTH. My quad start to fly right Second test my quad start to fly left.
Conclusion:
GPS should works fine on arduino pro mini without any problems. My tests fails but the source of problems may be my setup. I try to isolate my MAG and GPS form other electronics, or I will try to test GPS when motors are running. Will try to read values on the PC.
Idea:
My module and many others have binary protocol too. I write function to parse binary frames and it is relay worth to switch to this frames. Code use less internal memory and ram works faster etc. But to be sure I've run this tests on NMEA protocol.
I also disable all frames except GPGGA it is correct ?
I will try to run more tests soon but today start snowing here (Poland) so it is to cold - maybe this is source of problem??? (all electronics are covered of course). I need to add MAG calibration patch from another post.
Marcin.
Today I run first test on my custom board with Atmega 328.
my sensor setup is:
- L3G4200D
- ADXL345
- HMC5883
-BMP085
- and Mediatek GPS Gms‐u1LP - 10Hz + 115200 baud with custom firmware from GlobalTop.
http://download.maritex.com.pl/pdfs/wi/GPS-GMS-U1LP.pdf
First I've made some changes to get it work on Atmegs328. I decide to create detecting procedure at startup. If MWC receive NMEA frames in first two seconds I set flag GPSdetected, then use this flag to dissable qui and enable GPS transmition. If I don't miss anything here are all changes:
Code: Select all
global declaration
...
static uint8_t GPSDetected = 0;
//--------------------------------------
annexCode()
...
if (!GPSDetected)
serialCom();
//--------------------------------------
setup() function
...
#if defined(GPS)
if (GPS_SERIAL != 0)
SerialOpen(GPS_SERIAL,GPS_BAUD);
//init GPS and detect GPS
GPS_init();
currentTime = micros();
while(1)
{
if (SerialAvailable(GPS_SERIAL))
//-----------------------------------
loop() function
...
if (rcData[YAW] < MINCHECK && rcData[PITCH] < MINCHECK && armed == 0) {
if (rcDelayCommand == 20) calibratingG=400;
GPS_fix_home = 0; //save home position again if gyro calibration occurs
...
#if defined(GPS)
if (GPSDetected)
while (SerialAvailable(GPS_SERIAL)) {
if (GPS_newFrame(SerialRead(GPS_SERIAL))) {
if (GPS_update == 1)
{
GPS_update = 0;
STABLEPIN_ON; //toggle led to see NMEA frames
}
else
{
GPS_update = 1;
STABLEPIN_OFF;
}
if (GPS_fix == 1 && GPS_numSat > 4) {
if (GPS_newFrame(SerialRead(GPS_SERIAL)))
{
GPSDetected = 1;
break;
}
if (micros() - currentTime > 2000000)
break;
}
...
in GPS file:
void GPS_init()
{
char init1[] = "$PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n"; //disable all messages except GPGGA
//char init2[] = "$PGCMD,21,1*6F\r\n"; <-binary mode
int i;
delay (50);
for (i = 0; i < sizeof(init1); i++)
SerialWrite(GPS_SERIAL,init1[i]);
}
Then I setup PID's for GPS: P=5 and D=5
Then I go outside. First I test head free mode and it works fine. Compass was tested using classic compass before and it show North correctly. then I fly forward me so about 20m and enable RTH. My quad start to fly right Second test my quad start to fly left.
Conclusion:
GPS should works fine on arduino pro mini without any problems. My tests fails but the source of problems may be my setup. I try to isolate my MAG and GPS form other electronics, or I will try to test GPS when motors are running. Will try to read values on the PC.
Idea:
My module and many others have binary protocol too. I write function to parse binary frames and it is relay worth to switch to this frames. Code use less internal memory and ram works faster etc. But to be sure I've run this tests on NMEA protocol.
I also disable all frames except GPGGA it is correct ?
I will try to run more tests soon but today start snowing here (Poland) so it is to cold - maybe this is source of problem??? (all electronics are covered of course). I need to add MAG calibration patch from another post.
Marcin.
Re: GPS integration
Did you added the fix which described here? viewtopic.php?f=8&t=649&start=90#p7261
Re: GPS integration
EOSBandi wrote:Did you added the fix which described here? viewtopic.php?f=8&t=649&start=90#p7261
No. Just fixed and go to test outside. See you soon.
Re: GPS integration
Ok, now it works like on EOSBandi video. Overshot position, etc but work on Atmega328 I saw that when I read frames in binary format i have bigger precision so I need to modify code to work with higher resolution.
Marcin.
Marcin.
Re: GPS integration
Welcome to the club !
You can get the higher precision routines from the i2c code. I made same test and the position resolution of the current calculation is ~80cm, and it's not the low resolution of the gps data but the parsing and converting to degrees code limitation. Perhaps it's worth to try increasing the resolution from 1/100 000 to 1/10 000 000 as I did in i2c.
You can get the higher precision routines from the i2c code. I made same test and the position resolution of the current calculation is ~80cm, and it's not the low resolution of the gps data but the parsing and converting to degrees code limitation. Perhaps it's worth to try increasing the resolution from 1/100 000 to 1/10 000 000 as I did in i2c.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Hi,
I badly want to test the GPS feature but I am a little afraid of a runaway copter. So I want to test position hold first, can I test it by saving home position and stay above this position and active "return to home"?
To compile the multiwii.ino I need the new Arduino version right? Can I run them both on the same computer?
Thanks Nils
I badly want to test the GPS feature but I am a little afraid of a runaway copter. So I want to test position hold first, can I test it by saving home position and stay above this position and active "return to home"?
To compile the multiwii.ino I need the new Arduino version right? Can I run them both on the same computer?
Thanks Nils
Re: GPS integration
jevermeister wrote:Hi,
I badly want to test the GPS feature but I am a little afraid of a runaway copter. So I want to test position hold first, can I test it by saving home position and stay above this position and active "return to home"?
To compile the multiwii.ino I need the new Arduino version right? Can I run them both on the same computer?
Thanks Nils
You can, but if gps is not workin you will have a runaway copter anyway. So test it first with around 10 meter distance from home position and keep your finger on the rth disable switch. Also limit the max angle in gui to keep things under control.
Re: GPS integration
Don't worry about copter. If you see that it start to fly in wrong direction you can always disable RTH function and you can control your quad. BTW you can use your sticks when RTH is enabled. GPS only insert correction. I will try to make i2c_gps_nav module today like described above and will give you more feedback.
@EOSBandi - What PID's are you using to test GPS?
Regards,
Marcin.
@EOSBandi - What PID's are you using to test GPS?
Regards,
Marcin.
Re: GPS integration
marbalon wrote:@EOSBandi - What PID's are you using to test GPS?
My PID's are here viewtopic.php?f=9&t=1002#p7304
Re: GPS integration
Hi again,
I can say only wow. I just fallow EOSBandi instruction for i2c_gps_nav and everything works without any problems! So it is time to create separate small PCB for Atmega168 + GPS + MAG + Baro (i know baro can be one the main board but I have two quads so I can move this sensors between this models). I have one question. Waht values are you using in Dist to home box ?
Thanks again for this perfect solution!
Marcin.
I can say only wow. I just fallow EOSBandi instruction for i2c_gps_nav and everything works without any problems! So it is time to create separate small PCB for Atmega168 + GPS + MAG + Baro (i know baro can be one the main board but I have two quads so I can move this sensors between this models). I have one question. Waht values are you using in Dist to home box ?
Thanks again for this perfect solution!
Marcin.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Hi,
call me stupid but I have a problem, I tried to merge the current dev with my code (1.9 Multiwii.PDE compiled with Arduino 022) and I used the Conf of 22.12.2011 but I have no vis.
No graphs, no Bars, and no values, I can save the Values but not see them. I almost crashed the copter becaus I forgot to calibrate the ACC d'oh.
Can you give me a hint what is wrong here?
Is it the wrong conf I am using or is the conf incompatible to code compiled with the old arduino tool.
Thank You!!!
Nils
btw: Headfree seems to work very well...
call me stupid but I have a problem, I tried to merge the current dev with my code (1.9 Multiwii.PDE compiled with Arduino 022) and I used the Conf of 22.12.2011 but I have no vis.
No graphs, no Bars, and no values, I can save the Values but not see them. I almost crashed the copter becaus I forgot to calibrate the ACC d'oh.
Can you give me a hint what is wrong here?
Is it the wrong conf I am using or is the conf incompatible to code compiled with the old arduino tool.
Thank You!!!
Nils
btw: Headfree seems to work very well...
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi EOS,
you did a great job !
Could you explain more ?
According to the current accuracy (1/100 000), the distance step is around 1.11m
6372795 / 100000.0 * PI/180 = 1.11m
With 1/10 000 000, it would be 1.1cm
Are the GPS nowadays more accurate than 1m ?
you did a great job !
Since calculation speed is not a real issue, I increased the precision for position calculation it’s 1/10 000 000 instead of 1/100 000. According to my test, the lower precision caused +/-5M errors in distance calculations in short ranges.
Could you explain more ?
According to the current accuracy (1/100 000), the distance step is around 1.11m
6372795 / 100000.0 * PI/180 = 1.11m
With 1/10 000 000, it would be 1.1cm
Are the GPS nowadays more accurate than 1m ?
Re: GPS integration
Hi Alex,
Well, the issue is not in the distance calculation, but whith the lat/lon conversion routine. In the distance calculation I just followed the increased resolution of the coordinates.
Here is what I found:
Take a GPS coordinate, for example 47 34.2841N, 19 2.211E (This is my test field )
Convert it to decimal degrees with 10e5 prec, and we got 47.5714N 19.0368E This point is 3.7meters away from the gps coordinate.
Now convert it with 10e7 precision and we got 47.571402N 19.03685E This is pretty much at the same point.
Well, the issue is not in the distance calculation, but whith the lat/lon conversion routine. In the distance calculation I just followed the increased resolution of the coordinates.
Here is what I found:
Take a GPS coordinate, for example 47 34.2841N, 19 2.211E (This is my test field )
Convert it to decimal degrees with 10e5 prec, and we got 47.5714N 19.0368E This point is 3.7meters away from the gps coordinate.
Now convert it with 10e7 precision and we got 47.571402N 19.03685E This is pretty much at the same point.
Re: GPS integration
Hi,
Today I made another fly test but with a little different setup:
- my bigger quad wit 11"x4,5 popeller
- KDA 20-22L
- weight about 1kg RTF
- GPS using i2c_gps_nav
- GPS PID P=2, D=5
Thanks to heavier electronics with GPS etc. and new dumpering method this quad become really stable. But it is quite heavy so it overshot position more. I will try to made another test with smaller PID values but this evening it starts snowing again - maybe my children will be happy tomorrow but how can I test GPS ?
I also try to add patch for real MAG calibration for RTH but it is not working on pro mini. After calibration board seems to reset when saving data to eprom.
Now I think we should think about RTH implementation. I think we need full PID because quad should have some software brakes to reduce speed when reached home position. I don't know if PID is enough but now it overshot position everytime.
End of report - I hope this winter will be really short
Edit.
Another test with smaller PID values. P = 0.8 and D=3. Works much better now. But I think we should change this lines from:
to
But I think if we implement full PID result should be satisfied. All batteries are empty so today I can test anything.
ps. Sorry for my English - I almost sure I made many...
Today I made another fly test but with a little different setup:
- my bigger quad wit 11"x4,5 popeller
- KDA 20-22L
- weight about 1kg RTF
- GPS using i2c_gps_nav
- GPS PID P=2, D=5
Thanks to heavier electronics with GPS etc. and new dumpering method this quad become really stable. But it is quite heavy so it overshot position more. I will try to made another test with smaller PID values but this evening it starts snowing again - maybe my children will be happy tomorrow but how can I test GPS ?
I also try to add patch for real MAG calibration for RTH but it is not working on pro mini. After calibration board seems to reset when saving data to eprom.
Now I think we should think about RTH implementation. I think we need full PID because quad should have some software brakes to reduce speed when reached home position. I don't know if PID is enough but now it overshot position everytime.
End of report - I hope this winter will be really short
Edit.
Another test with smaller PID values. P = 0.8 and D=3. Works much better now. But I think we should change this lines from:
Code: Select all
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
to
Code: Select all
GPS_angle[ROLL] = constrain(P8[PIDGPS] * sin(radDiff) * GPS_distanceToHome / 100,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // with P=5, 1 meter = 0.5deg inclination
GPS_angle[PITCH] = constrain(P8[PIDGPS] * cos(radDiff) * GPS_distanceToHome / 100,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // max inclination = D deg
But I think if we implement full PID result should be satisfied. All batteries are empty so today I can test anything.
ps. Sorry for my English - I almost sure I made many...
Re: GPS integration
@EOSBandi.
What does the Dist home show? CM,DM or meters?
Looks like cm for me!
While sitting inside with 5 sats Dist home soon shows a value of 70-100.
With serial connection it only shows 1-2.
But it works!..
Haven't tested it in flight yet.
What does the Dist home show? CM,DM or meters?
Looks like cm for me!
While sitting inside with 5 sats Dist home soon shows a value of 70-100.
With serial connection it only shows 1-2.
But it works!..
Haven't tested it in flight yet.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: GPS integration
This may be a dumb suggestion to some but why not add a second arduino to handle all of the housekeeping items sure as GPS, Ultrasonic and Batteries monitoring? I purchased two of the Pro-Minis on Ebay a few days ago for 12 bucks each and I think the shipping was something like two bucks. I am sure some gifted enterprising person will come up with a shield to handle the job, wish I could but hopefully it will get done.
Here is a reference to connecting the two Arduinos.
http://hackaday.com/2011/11/08/a-simple ... -capacity/
Here is a reference to connecting the two Arduinos.
http://hackaday.com/2011/11/08/a-simple ... -capacity/
Re: GPS integration
PatrikE wrote:@EOSBandi.
What does the Dist home show? CM,DM or meters?
Looks like cm for me!
While sitting inside with 5 sats Dist home soon shows a value of 70-100.
With serial connection it only shows 1-2.
But it works!..
Haven't tested it in flight yet.
It is supposed to be in meters....
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
EOSBandi wrote:Hi Alex,
Well, the issue is not in the distance calculation, but whith the lat/lon conversion routine. In the distance calculation I just followed the increased resolution of the coordinates.
Here is what I found:
Take a GPS coordinate, for example 47 34.2841N, 19 2.211E (This is my test field )
Convert it to decimal degrees with 10e5 prec, and we got 47.5714N 19.0368E This point is 3.7meters away from the gps coordinate.
Now convert it with 10e7 precision and we got 47.571402N 19.03685E This is pretty much at the same point.
Hi,
I did this little test with the current function GPS_coord_to_degrees (1 degree = 100 000)
Code: Select all
char toto[] = "1902.211";
Serial.println(GPS_coord_to_degrees(toto));
The result is 1903685 and not 190368
So for me it's good.
Code: Select all
char toto[] = "4734.2841";
Serial.println(GPS_coord_to_degrees(toto));
The result is 4757140.
Here we lost the last figure 2 (47571402) according to your example.
But the distance between 47.57140 deg and 47.571402 deg is less than 22cm on the earth sphere.
So I still don't understand the need to push up the decimal accuracy.
Re: GPS integration
And you are right ! I did screw up somewhere during the long night....
I'll change my code accordingly.
Thanks for looking and insisting
I'll change my code accordingly.
Thanks for looking and insisting
Re: GPS integration
Meanwhile I moved forward with the onboard flight data logging. I think I got some very interesting data, which can underpin the justification of using i2c gps instead a serial one.
I made meassurements with the following config :
ATMega2560 proc, ITG3205+BMA020. Logging interval : 50Hz (20ms). Logged average cycleTime and maximum cycleTime since last log write.
What do you think ?
I made meassurements with the following config :
ATMega2560 proc, ITG3205+BMA020. Logging interval : 50Hz (20ms). Logged average cycleTime and maximum cycleTime since last log write.
What do you think ?
Re: GPS integration
I think this confirms that it is really worth doing i2c module. But do you have a GPS module with binary data format? I my case it only one frame 44bytes with checksum and all information we have so if someone have a Arduino Maga and more UART ports can use module with binary format. But if someone have a time and like soldering it is better use I2C module I think.
Thanks EOSBandi for all tests, I think we will get nice working GPS functions before spring
If someone are interested here is a firmware for GPS-GMS-U1LP (MTK3329 based GPS from GlobalTop) with binary format and 10Hz refresh + 115200 by default. But remember this is only for GPS-GMS-U1LP. Here isan information how can you load this firmware and all tools. It is quite cheap -about $20 in Poland - easy to solder, and nice working module.
Regards,
Marcin.
Thanks EOSBandi for all tests, I think we will get nice working GPS functions before spring
If someone are interested here is a firmware for GPS-GMS-U1LP (MTK3329 based GPS from GlobalTop) with binary format and 10Hz refresh + 115200 by default. But remember this is only for GPS-GMS-U1LP. Here isan information how can you load this firmware and all tools. It is quite cheap -about $20 in Poland - easy to solder, and nice working module.
Regards,
Marcin.
Re: GPS integration
marbalon wrote:I think this confirms that it is really worth doing i2c module. But do you have a GPS module with binary data format? I my case it only one frame 44bytes with checksum and all information we have so if someone have a Arduino Maga and more UART ports can use module with binary format. But if someone have a time and like soldering it is better use I2C module I think.
Thanks EOSBandi for all tests, I think we will get nice working GPS functions before spring
If someone are interested here is a firmware for GPS-GMS-U1LP (MTK3329 based GPS from GlobalTop) with binary format and 10Hz refresh + 115200 by default. But remember this is only for GPS-GMS-U1LP. Here isan information how can you load this firmware and all tools. It is quite cheap -about $20 in Poland - easy to solder, and nice working module.
Regards,
Marcin.
Hi !
Agree, it's on the ToDo list to implement binary protocols alongside with the NMEA (There are uBlox, MTK3329 bin, SIRF and the DiYDrones custom protocol that you mentioned above). (Once I implement it in i2C gps it can be easily moved to the main MultiWii code.) This will help ease the reading and parsing, but there are still a lots of calculation, especially when we start implement navigation (cross track, wind compensation, dead reconing etc.).
Btw, Could you point me to the source in Poland for the U1LP ? The cheapest what I found in Hungary was U.top-PA6B (Same chip, smaller form factor, without supporting electronics) but it's about 35usd.
(The I2C_GPS_NAV code is now lives at https://code.google.com/p/i2c-gps-nav/)
Re: GPS integration
Hi,
Here is the shop where I bought it. I don't think they ship this outside Poland, but if you want I can bought it and send it to you. Just pm me. But if you can wait a while, because me and some friends want to to build special small PCB with this GPS, Atmega, HMCL, and Baro - all powered from 3v3 and connected to main board only using four pins. I think this will be good solution because can be moved from one copter to other.
I forgot attach firmware and manual for binary format to previous message.
Here you are - only for GPS-GMS-U1LP module, 10Hz and binary format
Here is the shop where I bought it. I don't think they ship this outside Poland, but if you want I can bought it and send it to you. Just pm me. But if you can wait a while, because me and some friends want to to build special small PCB with this GPS, Atmega, HMCL, and Baro - all powered from 3v3 and connected to main board only using four pins. I think this will be good solution because can be moved from one copter to other.
I forgot attach firmware and manual for binary format to previous message.
Here you are - only for GPS-GMS-U1LP module, 10Hz and binary format
Re: GPS integration
i would be happyer if i would not have to build another board for I2C GPS with another schetch, instead i would like to use the same GPS as Remzibi OSD uses with no other hardware.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
Hi,
It's clear the GPS frame decoding and distance calculation takes some times in the arduino.
But I think your graph is a little bit smoothed we should see Dirac impulsion
Let me explain:
Without a GPS, a "standard" config should run at more or less 300Hz loop speed.
A 10Hz GPS will disturb the normal loop 1 time every 30 times. not really noticeable in flight.
But you're right on the principle. I2C GPS with offload computation will suppress those spike delays
It's clear the GPS frame decoding and distance calculation takes some times in the arduino.
But I think your graph is a little bit smoothed we should see Dirac impulsion
Let me explain:
Without a GPS, a "standard" config should run at more or less 300Hz loop speed.
A 10Hz GPS will disturb the normal loop 1 time every 30 times. not really noticeable in flight.
But you're right on the principle. I2C GPS with offload computation will suppress those spike delays
EOSBandi wrote:Meanwhile I moved forward with the onboard flight data logging. I think I got some very interesting data, which can underpin the justification of using i2c gps instead a serial one.
I made meassurements with the following config :
ATMega2560 proc, ITG3205+BMA020. Logging interval : 50Hz (20ms). Logged average cycleTime and maximum cycleTime since last log write.
What do you think ?
Re: GPS integration
Better use a proper gps with binary format, ublox, or even MTK (yuck)
-
- Posts: 92
- Joined: Thu Dec 01, 2011 8:55 pm
- Location: Scotter, Lincolnshire, UK
Re: GPS integration
Wonder if anyone can shed any light. Hoping to use this model of GPS.
http://www.globalsat.co.uk/product_pages/gsat_products_cable_bu303.htm
Would it be possible to use this, or should I just put it in the bin - bought it quite a while ago for another project but ended up not using it.
Many thanks in advance
Iain
http://www.globalsat.co.uk/product_pages/gsat_products_cable_bu303.htm
Would it be possible to use this, or should I just put it in the bin - bought it quite a while ago for another project but ended up not using it.
Many thanks in advance
Iain
Re: GPS integration
If you can hack it and find serial data in it!
Re: GPS integration
Hi all,
does anybody succeed on i2c GPS connection with secondary arduino?
I have 5V arduino nano, flytron GPS receiver and built a level converter:
http://www.flytron.com/osd-headtrackers ... odule.html
http://www.sparkfun.com/products/8745
I modified my dev_2011... MWI code in my quadrino board following the steps, uploaded the i2c_GPS to secondary arduino but it still looks like it doesn't work, I think there is something problem with serial communication.
I tried the i2c program of EOSBandi.
any idea what to change or try?
ps.:just one question. Should ' see the number of sats in GUI when communications are working and have valid 3D fix?
does anybody succeed on i2c GPS connection with secondary arduino?
I have 5V arduino nano, flytron GPS receiver and built a level converter:
http://www.flytron.com/osd-headtrackers ... odule.html
http://www.sparkfun.com/products/8745
I modified my dev_2011... MWI code in my quadrino board following the steps, uploaded the i2c_GPS to secondary arduino but it still looks like it doesn't work, I think there is something problem with serial communication.
I tried the i2c program of EOSBandi.
any idea what to change or try?
ps.:just one question. Should ' see the number of sats in GUI when communications are working and have valid 3D fix?
Re: GPS integration
refractions wrote:Wonder if anyone can shed any light. Hoping to use this model of GPS.
http://www.globalsat.co.uk/product_pages/gsat_products_cable_bu303.htm
Would it be possible to use this, or should I just put it in the bin - bought it quite a while ago for another project but ended up not using it.
If you aren't afraid to open it, you should be able to make use of it. It seems there is a "Serial to USB" chip (a PL-2303 from Prolific) between the GPS circuit and the USB port, so it should be possible to pull the serial data directly. You will have to remove or disable the PL-2303 chip and solder wires to the serial lines and power supply (Vcc) directly.
-
- Posts: 92
- Joined: Thu Dec 01, 2011 8:55 pm
- Location: Scotter, Lincolnshire, UK
Re: GPS integration
LenzGr wrote:refractions wrote:Wonder if anyone can shed any light. Hoping to use this model of GPS.
http://www.globalsat.co.uk/product_pages/gsat_products_cable_bu303.htm
Would it be possible to use this, or should I just put it in the bin - bought it quite a while ago for another project but ended up not using it.
If you aren't afraid to open it, you should be able to make use of it. It seems there is a "Serial to USB" chip (a PL-2303 from Prolific) between the GPS circuit and the USB port, so it should be possible to pull the serial data directly. You will have to remove or disable the PL-2303 chip and solder wires to the serial lines and power supply (Vcc) directly.
Many thanks for the info. Opened it up, but haven't got around to unsoldering the shielding covering the entire board. Will let you know how it goes.
Iain
-
- Posts: 92
- Joined: Thu Dec 01, 2011 8:55 pm
- Location: Scotter, Lincolnshire, UK
Re: GPS integration
Hi,
Got around to removing all the shielding on this board. You are correct in that the usb chip is a PL-2303. Seems simple enough from datasheet.
pin 1 TXD
pin 5 RXD
pin 20 VDD
pin 21 GND
Just need a small enough iron tip now.
Iain
Got around to removing all the shielding on this board. You are correct in that the usb chip is a PL-2303. Seems simple enough from datasheet.
pin 1 TXD
pin 5 RXD
pin 20 VDD
pin 21 GND
Just need a small enough iron tip now.
Iain
Re: GPS integration
How about this?...
Re: GPS integration
Precise question : The variable that hold GPSdirectiontohome in the multiwii, is it a value from -180 to 180 ???
0 in there will be straight foward, -90 will show that home is a 9h and 90 show home at 3h. ?
I'm asking this because i'm adding it to Rushduino Osd code and its hard to go outside to test gps and those data when its -15deg celcius outside.....with wind and snow
0 in there will be straight foward, -90 will show that home is a 9h and 90 show home at 3h. ?
I'm asking this because i'm adding it to Rushduino Osd code and its hard to go outside to test gps and those data when its -15deg celcius outside.....with wind and snow
Re: GPS integration
I just try tthe GPS-I2C-NAV (R6) all is working fine. GOOD JOB !
I try it with a old GPS (1hz @ 38400) on a promini and there is no problem.
Just one think, I had to change directly TWI.h to put the I2C speed to 100k. Is it possible to make a change in the soft to have this opition directly in I2C_GPS_NAV.ino ?
Next step, I wait for my rushduino OSD and I will try to integrate all.
I try it with a old GPS (1hz @ 38400) on a promini and there is no problem.
Just one think, I had to change directly TWI.h to put the I2C speed to 100k. Is it possible to make a change in the soft to have this opition directly in I2C_GPS_NAV.ino ?
Next step, I wait for my rushduino OSD and I will try to integrate all.
Re: GPS integration
Hi all,
I have just finished my setup with secondary Arduino nano and GPS, thanks for the code to EOSBandi!!!!!!!!!!
Here is a small test video:
http://youtu.be/SqMts1BAxD4
BR
Adrian
I have just finished my setup with secondary Arduino nano and GPS, thanks for the code to EOSBandi!!!!!!!!!!
Here is a small test video:
http://youtu.be/SqMts1BAxD4
BR
Adrian
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: GPS integration
now, let's see how it behaves in the air
Re: GPS integration
Some terrible weather arrived to Hungary right now... unfortunatelly I have to wait a few days... :(:(:(
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Ahoi,
piles of snow here, so.testing yet.
Nils
piles of snow here, so.testing yet.
Nils
Re: GPS integration
Excuse me but is possibile to install GPS on Arduino Nano 3.0? If yes, how?
Re: GPS integration
today i have test the EOSBANDI Code .
It works great , but the home position is not realy set at the homeposition , because after the first fix , the gps drift around 50m away to the real position .
So my question is , how can i juse position hold function from the EOSBANDI code ? I think its the better way to test the code
But it works JEAHHHHHHH !
THANKS SO MUTCH
It works great , but the home position is not realy set at the homeposition , because after the first fix , the gps drift around 50m away to the real position .
So my question is , how can i juse position hold function from the EOSBANDI code ? I think its the better way to test the code
But it works JEAHHHHHHH !
THANKS SO MUTCH
Re: GPS integration
I added this to the Multiwii.ino inside the i2c GPS part:
if (rcData[AUX1]>1700) {
GPS_fix_home = 0;
i2c_writeReg(I2C_GPS_ADDRESS,I2C_GPS_COMMAND,I2C_GPS_COMMAND_SET_WP);
i2c_writeReg(I2C_GPS_ADDRESS,I2C_GPS_COMMAND,I2C_GPS_COMMAND_ACTIVATE_WP);
GPS_fix_home = 1;
}
this re-define the home position, I have a mix in my TX which sets up AUX1 to high when I pull the spring-switch up on my TX.
Unfortunatelly sometimes I have to pull-up the switch for 4-5 seconds or even more till it re-defines the position, sumetimes just a second, I couldn't figure out why.
But, it works!
BR
Adrian
if (rcData[AUX1]>1700) {
GPS_fix_home = 0;
i2c_writeReg(I2C_GPS_ADDRESS,I2C_GPS_COMMAND,I2C_GPS_COMMAND_SET_WP);
i2c_writeReg(I2C_GPS_ADDRESS,I2C_GPS_COMMAND,I2C_GPS_COMMAND_ACTIVATE_WP);
GPS_fix_home = 1;
}
this re-define the home position, I have a mix in my TX which sets up AUX1 to high when I pull the spring-switch up on my TX.
Unfortunatelly sometimes I have to pull-up the switch for 4-5 seconds or even more till it re-defines the position, sumetimes just a second, I couldn't figure out why.
But, it works!
BR
Adrian
Re: GPS integration
Excuse me, but exist a GPS module that natively has a i2c capabilities? If yes I will not buy a FMP04 GPS that had only serial comm line.
Re: GPS integration
cool , thanks
But it does not juse the Position Hold function from EOSBANDI .....
But for now its good for testing
But it does not juse the Position Hold function from EOSBANDI .....
But for now its good for testing
Re: GPS integration
No, it doesn't use position hold, but you can re-define home position at any time, practically before take-off...
Re: GPS integration
You can get new home fix when you Arm.
Add GPS_fix_home = 0; in the arming code.( 2 places in MultiWii tab)
Every time you Arm the engines a new RTH point will be stored.
Add GPS_fix_home = 0; in the arming code.( 2 places in MultiWii tab)
Code: Select all
armed = 1;
GPS_fix_home = 0;
headFreeModeHold = heading;
Every time you Arm the engines a new RTH point will be stored.