GPS integration
Re: GPS integration
Very cool to see GPS support getting integrated into the MultiWii code base. I've just recently switched controllers in my quad (I was using an ArduIMU v2 flat with custom code before), first test flights look good! I'm thinking about adding a GPS module to my copter at some point. I recently purchased a SparkFun GPS Micro-Mini module - do you think it would be usable? The default baud rate is 4800bps (changeable), the update rate is 1Hz (fixed). It's probably too slow for accurately holding a position, but might be sufficient for simple return to home or waypoint navigation. What do you guys think?
Re: GPS integration
I suggest this GPS receiver:
http://www.flytron.com/osd-headtrackers ... odule.html
cheap and works great, I already have three of them woth different OSDs.
So, could anybody help me integrate my i2c GPS idea into the multiwii code? I think many of us with arduino mini would be really interrested in because then they only need a receiver, an Arduino mini and some soldering... But I'm not as qualified programmer as this issue needs...
http://www.flytron.com/osd-headtrackers ... odule.html
cheap and works great, I already have three of them woth different OSDs.
So, could anybody help me integrate my i2c GPS idea into the multiwii code? I think many of us with arduino mini would be really interrested in because then they only need a receiver, an Arduino mini and some soldering... But I'm not as qualified programmer as this issue needs...
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Do you guys think, that there is a possibility to send gps data to a sending device? IO currently use a hombing ebacon to find my copter if it is lost, I already lsot two copters and only found one.
I am very careful not to loose it right now an I use a GPS GSM beacon but it is very heavy. Maybe we can use the nmea data and a small gsm module/or another kind of tx/rx combi to send the data.
My current beacon sends the data via sms (text message) when I call it after I lost the model.
Nils
ps.: can someone give me a short overlook of the theory of position hold via GPS?
I want to try developing something into that direction for understanding it.
I am very careful not to loose it right now an I use a GPS GSM beacon but it is very heavy. Maybe we can use the nmea data and a small gsm module/or another kind of tx/rx combi to send the data.
My current beacon sends the data via sms (text message) when I call it after I lost the model.
Nils
ps.: can someone give me a short overlook of the theory of position hold via GPS?
I want to try developing something into that direction for understanding it.
Re: GPS integration
Hi guys.
After many hours of trying I had to realize that I should spend on lot of time to learn the programming basics properly, and figure out how multiwii code works. In lack of this it is almost impossible to do finalize my idea. But also I think it would be 2-3 afternoon job for somebody who knows what to do, since even I had some success on i2c communication establisment between the two arduino panels (with some test modifications, I was able to turn on the LED of the secondary Arduino with an aux input of multiwii..... ), but I can't figure out how to read the data and import into the MW code properly, etc...
So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...:
// legends: PRA - primary arduino with MW code, SEA - secondary arduino with GPS connected
- SEA and PRA are connected with i2c, SEA and GPS with serial
- SEA establishes serial communication with the gps and reads out GGA strings on 115200 baud (I have to use VTG too for my OSD because of airspeed, so the program should be able to read the GGA only from two type of sentences)
- SEA translates latitude, longitude, fix, satellite number values, and update these values continously if fix is OK (else leaves them unchanged)
- SEA learns home and hold coordinates and continously calculates the distance and direction between current position and home and hold coordinates (at initialization both should be the first fix, then changing regarding the followings)
- if PRA would read SEA, distance and direction to home; fix and numsat are available in 10 bytes from SEA. (fix 1byte, numsat 1 byte, distToHome 2 bytes, dirToHome 2 bytes, distToHold 2 bytes, dirToHold 2 bytes)
- I plan to put home position learning onto a spring-switch on my radio, so when spring state of switch is active in PRA, PRA asks SEA to learn the home position coordinates, but it could be linked to arming too.
- every time hold mode becomes active in PRA, it sends an order to SEA for learning the current position as hold. It is important to send the command only once per hold activation.
- PRA only uses the datas from SEA for positioning (distance, direction) to reduce PRA code size
- I think, for safety in both hold and home functions there should be a condition for fix=1, so when there is GPS fix, they are working, when fix takes away, hold and home deactivates, and copter stays in autolevel, and once fix returns, copter continues the way if option is still enabled.
- I think for both home and hold functions the same algorythm should used for first time since the task is almost the same, stay as close to the desired point as possible).
- as an addition, SEA led should light up when fix is OK (only some lines in code but great help for checking if GGA sentences are translated properly)
That's all folks!
BR
Adrian
ps.: sorry for my english, I'm not using the language daily... , and many thanks to EOSBandi for the basic idea...
After many hours of trying I had to realize that I should spend on lot of time to learn the programming basics properly, and figure out how multiwii code works. In lack of this it is almost impossible to do finalize my idea. But also I think it would be 2-3 afternoon job for somebody who knows what to do, since even I had some success on i2c communication establisment between the two arduino panels (with some test modifications, I was able to turn on the LED of the secondary Arduino with an aux input of multiwii..... ), but I can't figure out how to read the data and import into the MW code properly, etc...
So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...:
// legends: PRA - primary arduino with MW code, SEA - secondary arduino with GPS connected
- SEA and PRA are connected with i2c, SEA and GPS with serial
- SEA establishes serial communication with the gps and reads out GGA strings on 115200 baud (I have to use VTG too for my OSD because of airspeed, so the program should be able to read the GGA only from two type of sentences)
- SEA translates latitude, longitude, fix, satellite number values, and update these values continously if fix is OK (else leaves them unchanged)
- SEA learns home and hold coordinates and continously calculates the distance and direction between current position and home and hold coordinates (at initialization both should be the first fix, then changing regarding the followings)
- if PRA would read SEA, distance and direction to home; fix and numsat are available in 10 bytes from SEA. (fix 1byte, numsat 1 byte, distToHome 2 bytes, dirToHome 2 bytes, distToHold 2 bytes, dirToHold 2 bytes)
- I plan to put home position learning onto a spring-switch on my radio, so when spring state of switch is active in PRA, PRA asks SEA to learn the home position coordinates, but it could be linked to arming too.
- every time hold mode becomes active in PRA, it sends an order to SEA for learning the current position as hold. It is important to send the command only once per hold activation.
- PRA only uses the datas from SEA for positioning (distance, direction) to reduce PRA code size
- I think, for safety in both hold and home functions there should be a condition for fix=1, so when there is GPS fix, they are working, when fix takes away, hold and home deactivates, and copter stays in autolevel, and once fix returns, copter continues the way if option is still enabled.
- I think for both home and hold functions the same algorythm should used for first time since the task is almost the same, stay as close to the desired point as possible).
- as an addition, SEA led should light up when fix is OK (only some lines in code but great help for checking if GGA sentences are translated properly)
That's all folks!
BR
Adrian
ps.: sorry for my english, I'm not using the language daily... , and many thanks to EOSBandi for the basic idea...
Last edited by nhadrian on Wed Jan 11, 2012 5:51 pm, edited 2 times in total.
Re: GPS integration
I love what you try to do it's an exellent idea. I can't help you ... but I follow this post
Re: GPS integration
nhadrian wrote:So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...
I'm not sure I'm getting the point on this. Why would you want to go with two Mini Boards, when you can get a Mega at roughly the same price, which provides the additional required serial port, and more?
Re: GPS integration
Simple, was majority of the boards available on the market are atmega384 based. So with an I2c gps you can use these boards for gps based functions. Plus, offloading computing and memory intensive tasks to a secondary processor frees up resources on the main proc, and helps keeping the cycle time low. That allows you to use higher precision calculations for navigation. (there are many tasks with gps handling. Parsing gps sentences, calculating bearing and distance, check cross track error, even calculating dead reconing with an 1Hz cheap gps....)
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Sorry for changing the topic, but what about Position Hold?
Isnt' Position Hold easier to develop than Retun Home?
I do not have the balls to try return home right now I would like tos tart with position hold.
Nils
Isnt' Position Hold easier to develop than Retun Home?
I do not have the balls to try return home right now I would like tos tart with position hold.
Nils
Re: GPS integration
Following the idea with secondary processor and i2c, position hold and RTH is the same situation, only coordinates are changing, because once you reached the home point you should stay around there. So the excersise is the same but only when on hold mode (I meant position hold) you starts from the destination point. Thats easier but the main calculation is the same, maybe some PID tuning is neccessary for better holding.
BTW, for examle Mikrokopter is using dedicated processor for navigation calculations on a different panel too...
BTW, for examle Mikrokopter is using dedicated processor for navigation calculations on a different panel too...
Re: GPS integration
Position hold and RTH.
The differense should be that.
Position hold should just keep the position in the sky.
RTH should start to climb to a safe heiht ex 50m over home pos to avoid colliding with trees and houses.
After reaching home it should hold positon an decend to a preset altitude over home.ex 5-10m
After some time attempt to land. and shut down engines.
Or just do Position hold
/Patrik
The differense should be that.
Position hold should just keep the position in the sky.
RTH should start to climb to a safe heiht ex 50m over home pos to avoid colliding with trees and houses.
After reaching home it should hold positon an decend to a preset altitude over home.ex 5-10m
After some time attempt to land. and shut down engines.
Or just do Position hold
/Patrik
Re: GPS integration
My oppinion is that first should be more than enough if it would do the same as EOSBandi presented some posts earlier.
If RTH is activated, it starts to move towards to home position. When it reaches the home position it stays around there.
For position hold, it also has to be able to go back to position once a big wind ghust or so sweeps away by some meters. And then, the goal is the same...
Till now, alt hold works well alone without GPS, so when alt.hold activated via the same AUX as the GPS, then it will hold the altitude and the position too.
Then, later, of course, some more advanced features like flying stright between two points, altitude variation and others could be added... they are all really difficult programming jobs.
I think the first step is to establish connection between two arduino mini boards and GPS and have a basic function for RTH/HOLD.
If RTH is activated, it starts to move towards to home position. When it reaches the home position it stays around there.
For position hold, it also has to be able to go back to position once a big wind ghust or so sweeps away by some meters. And then, the goal is the same...
Till now, alt hold works well alone without GPS, so when alt.hold activated via the same AUX as the GPS, then it will hold the altitude and the position too.
Then, later, of course, some more advanced features like flying stright between two points, altitude variation and others could be added... they are all really difficult programming jobs.
I think the first step is to establish connection between two arduino mini boards and GPS and have a basic function for RTH/HOLD.
Re: GPS integration
Will have some time during weekend, I hope i'll be able to finish the code alongside with the inflight data logging.
-
- Posts: 178
- Joined: Fri Apr 01, 2011 10:32 pm
- Location: Czech Republic, Prague
Re: GPS integration
Hi all!
I agree with following EOSBandi and nhadrian idea!
Most multiwii users have ATMega 328 based boards - sometime nice complete boards with all sensors on one board (like me - I have very nice "crius" board) and don't want to exchange it for Mega board, but would like to play with GPS.
This I2C secondary arduino would be an easy, cheap and very smart solution allowing further growing in the future.
Secondary arduino can be any cheap promini or whatever you have in the drawer, it can work at any serial speed and refresh rate with any GPS you have, even configure the GPS and do all calculations to offload the primary arduino and provide only results to it. It can even "sniff" NMEA output from the OSD GPS on the given speed and use it. In future it can log flight data to micro SD card, keep there preprogrammed waypoints and provide to primary arduino just requested distance, heading (later also height, speed, etc.) for any kind of tasks you can imagine. It will have enough calculation time, memory and also necessary serial port for that tasks.
Unfortunately my programming skills are too bad for that so I can't write it. I can only support it with the electronic part, ideas, testing etc. I'd like to encourage someone to write the code.
In every case I vote for that brilliant idea!
Roman
I agree with following EOSBandi and nhadrian idea!
Most multiwii users have ATMega 328 based boards - sometime nice complete boards with all sensors on one board (like me - I have very nice "crius" board) and don't want to exchange it for Mega board, but would like to play with GPS.
This I2C secondary arduino would be an easy, cheap and very smart solution allowing further growing in the future.
Secondary arduino can be any cheap promini or whatever you have in the drawer, it can work at any serial speed and refresh rate with any GPS you have, even configure the GPS and do all calculations to offload the primary arduino and provide only results to it. It can even "sniff" NMEA output from the OSD GPS on the given speed and use it. In future it can log flight data to micro SD card, keep there preprogrammed waypoints and provide to primary arduino just requested distance, heading (later also height, speed, etc.) for any kind of tasks you can imagine. It will have enough calculation time, memory and also necessary serial port for that tasks.
Unfortunately my programming skills are too bad for that so I can't write it. I can only support it with the electronic part, ideas, testing etc. I'd like to encourage someone to write the code.
In every case I vote for that brilliant idea!
Roman
nhadrian wrote:Hi guys.
After many hours of trying I had to realize that I should spend on lot of time to learn the programming basics properly, and figure out how multiwii code works. In lack of this it is almost impossible to do finalize my idea. But also I think it would be 2-3 afternoon job for somebody who knows what to do, since even I had some success on i2c communication establisment between the two arduino panels (with some test modifications, I was able to turn on the LED of the secondary Arduino with an aux input of multiwii..... ), but I can't figure out how to read the data and import into the MW code properly, etc...
So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...:
// legends: PRA - primary arduino with MW code, SEA - secondary arduino with GPS connected
- SEA and PRA are connected with i2c, SEA and GPS with serial
- SEA establishes serial communication with the gps and reads out GGA strings on 115200 baud (I have to use VTG too for my OSD because of airspeed, so the program should be able to read the GGA only from two type of sentences)
- SEA translates latitude, longitude, fix, satellite number values, and update these values continously if fix is OK (else leaves them unchanged)
- SEA learns home and hold coordinates and continously calculates the distance and direction between current position and home and hold coordinates (at initialization both should be the first fix, then changing regarding the followings)
- if PRA would read SEA, distance and direction to home; fix and numsat are available in 10 bytes from SEA. (fix 1byte, numsat 1 byte, distToHome 2 bytes, dirToHome 2 bytes, distToHold 2 bytes, dirToHold 2 bytes)
- I plan to put home position learning onto a spring-switch on my radio, so when spring state of switch is active in PRA, PRA asks SEA to learn the home position coordinates, but it could be linked to arming too.
- every time hold mode becomes active in PRA, it sends an order to SEA for learning the current position as hold. It is important to send the command only once per hold activation.
- PRA only uses the datas from SEA for positioning (distance, direction) to reduce PRA code size
- I think, for safety in both hold and home functions there should be a condition for fix=1, so when there is GPS fix, they are working, when fix takes away, hold and home deactivates, and copter stays in autolevel, and once fix returns, copter continues the way if option is still enabled.
- I think for both home and hold functions the same algorythm should used for first time since the task is almost the same, stay as close to the desired point as possible).
- as an addition, SEA led should light up when fix is OK (only some lines in code but great help for checking if GGA sentences are translated properly)
That's all folks!
BR
Adrian
ps.: sorry for my english, I'm not using the language daily... , and many thanks to EOSBandi for the basic idea...
Last edited by rbirdie001 on Fri Jan 13, 2012 9:26 am, edited 1 time in total.
Re: GPS integration
I remember that Alex said that it could program an extra serial RX pin controlled by software to connect the gps to (for Atmega 328). The same extra RX pin i saw it to Remzibi who took the serial output from mwc and plotted on OSD, in parallel with serial GPS communication.
So i think this is the elegant solution, no extra hardware needed.
So i think this is the elegant solution, no extra hardware needed.
Re: GPS integration
If we use i2c we still have all pins availible for other things.. no ?
-
- Posts: 178
- Joined: Fri Apr 01, 2011 10:32 pm
- Location: Czech Republic, Prague
Re: GPS integration
Hi Dramida!
Yes, of course, I had originaly the same idea of direct GPS connection but after some reading in forums I got feeling that not only missing serial is the problem. It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.
So if there is the way to support GPS directly in primary 328, it would be perfect, but if not, then secondary arduino is great idea which can provide a lot of space for future developement. Once you have connected SD card and free RAM, you can log your flights, fly on waypoints, even repeat the same flight you have once recorded including height and speed (great e.g. for filming! When you expect some ocassion in the night, you can prepare your flight in the day and then in the dark it will fly alone.)... Almost unlimited possibilites so for one little arduino it could be great "added value"
The only problem is that I'm unable to write it alone so I'm just trying to encourage someone who can do it.
Nice day!
Roman
Yes, of course, I had originaly the same idea of direct GPS connection but after some reading in forums I got feeling that not only missing serial is the problem. It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.
So if there is the way to support GPS directly in primary 328, it would be perfect, but if not, then secondary arduino is great idea which can provide a lot of space for future developement. Once you have connected SD card and free RAM, you can log your flights, fly on waypoints, even repeat the same flight you have once recorded including height and speed (great e.g. for filming! When you expect some ocassion in the night, you can prepare your flight in the day and then in the dark it will fly alone.)... Almost unlimited possibilites so for one little arduino it could be great "added value"
The only problem is that I'm unable to write it alone so I'm just trying to encourage someone who can do it.
Nice day!
Roman
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: GPS integration
Hi,
my first copter was a selfmade shrediquette based copter with 328 and then I upgraded to multiwii flyduino based.
I now build a Arduino pro mini basedone for everyday action.
IMHO the flyduino copter is my mercedes with every feature I want: BARO,MAG,GPS,NICK/ROLL-Compensation, etc.
And the Arduino Mini copter is my action copter with only the neccesary stuff. I can live with that pretty well.
If I were you I would wait a couple of weeks until GPS is finished and get myself a mega board, it is worth every penny, is is very convenient and open for future development.
Nils
my first copter was a selfmade shrediquette based copter with 328 and then I upgraded to multiwii flyduino based.
I now build a Arduino pro mini basedone for everyday action.
IMHO the flyduino copter is my mercedes with every feature I want: BARO,MAG,GPS,NICK/ROLL-Compensation, etc.
And the Arduino Mini copter is my action copter with only the neccesary stuff. I can live with that pretty well.
If I were you I would wait a couple of weeks until GPS is finished and get myself a mega board, it is worth every penny, is is very convenient and open for future development.
Nils
Re: GPS integration
rbirdie001 wrote:Hi Dramida!
It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.
Remzibi uses Atmega 168 that means half of multiwii 328 based RAM .
If you read deeply in Alex's posts, he agrees that mwc has enough resources to make gps working with Atmega 328.
-
- Posts: 178
- Joined: Fri Apr 01, 2011 10:32 pm
- Location: Czech Republic, Prague
Re: GPS integration
dramida wrote:rbirdie001 wrote:Hi Dramida!
It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.
Remzibi uses Atmega 168 that means half of multiwii 328 based RAM .
If you read deeply in Alex's posts, he agrees that mwc has enough resources to make gps working with Atmega 328.
OK, let's agree that both have some advantages - having GPS on one chip or two. For me it's more important which way will be earlier passable. I can't write code for any of those solutions so I can just try encourage people who can do it.
Anyway I guess that flight controller in 328 will not have enough resources to additionally connect SD card, write there logs, read POI, calculate vectors and navigate by side of controlling the copter so for future it's a good idea. I use (and like) remzibi OSD but I know he is now having troubles with the processor resources, mainly RAM.
Roman
Re: GPS integration
I was skimming over bits an d pieces and started to play join the dots in my head.
multiwii has support for flying wings (which i fly via fpv but recently lost in teh middle of nowhere) and now gps support is being built in.
If i read correctly there is plans for RTH.
Would i be safe in saying that multiwii set in flying wing mode would be able to utilize the RTH function??
I would then like to ask if that works does someone with knowledge of the Rushduino OSD know if it would also utilize the gps data??
This would make a very powerful and cheap OSD RTH stabilization package.
multiwii has support for flying wings (which i fly via fpv but recently lost in teh middle of nowhere) and now gps support is being built in.
If i read correctly there is plans for RTH.
Would i be safe in saying that multiwii set in flying wing mode would be able to utilize the RTH function??
I would then like to ask if that works does someone with knowledge of the Rushduino OSD know if it would also utilize the gps data??
This would make a very powerful and cheap OSD RTH stabilization package.
-
- 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)