presnejsi trackovani pro OSM

17 zpráv
Zpět na přehled

presnejsi trackovani pro OSM

17 zpráv PMHJZPP 7 účastníků 15 min čtení
  1. Petr Holub hopet na ics.muni.cz #m3106d0
    Ahoj vespolek, trochu jsem hledal, jeslti by se nejakymi rozumne dostupnymi prostredky nedala zlepsit presnost tracklogu, zejmena ziskanych na kole, ale klidne i pesky a autem. Zlobi mne to hlavne pri rychlejsi jizde na kole spojene s rycheljsimi zmenami smeru (kdy Garmin 60CSx "nestiha zatacet") a v lese, kde je presnost vubec na pytel (60CSx ani Holux M-1000C). Zacal jsem uvazovat o nejakem modulu, ktery by sbiral raw GPS data na dostatecne frekvenci, na nichz by se dal udelat postprocesing - ale ne v cenove kategorii 30.000CZK a vic (tedy profi GPS zarizeni). Narazil jsem dve firmicky, ktere neco takoveho delaji (a do jiste miry spolu i spolupracuji): Optimalsystem.de a OneTalent-GNSS. Navrhy desek dela Michele Bavaro pro obe firmy a primarne pracuje pro ten OneTalent-GNSS - nize najdete jak moje dotazy na neho, tak i jeho odpovedi. Prestoze vyjadruje skepsi kolem dosazeni presnosti 1m v lese (pricem 1m povazuji pro potreby OSM naprosto dostacujici), nicmene porad by to mohlo by podstatne zlepseni proti tomu, co mam ted. Uvazuji o jednom z nasledujicich modulu: http://www.onetalent-gnss.com/ideas/wireless/denga10logbt http://www.onetalent-gnss.com/ideas/wireless/rappen10logbt Jinak data pro postprocesing by napr. pro okoli Brna mely byt zdarma dostupne ze site stanic EUREF: http://www.epncb.oma.be/_networkdata/stationlist.php pro Brno napr. tady: http://www.epncb.oma.be/_networkdata/siteinfo4onestation.php?station=TUBO_11503M001 Moje dotazy do fora: - Hrali jste si nekdo s necim podobnym? - Meli byste chut a cas se nekdo do toho taky pustit? Diky, Petr Hello Petr, Thanks for getting in touch! It will be very difficult to guarantee 1m accuracy (standalone real-time or differential post-processed) under dense foliage. Trees are well known to disrupt carrier phase information which is essential to achieve such accuracies. There is something about it on the German forum Kowoma: http://www.kowoma.de/gpsforum/viewtopic.php?f=1&t=3248&p=14992#p14992 Denga10 and Rappen10 are not suitable. But their _LogBt or _LogWi version instead might work: they have a battery which will last a longer than 6hr, logging, and Bluetooth - or pretty much any other wireless communication system. Of course both have raw measurements but their carrier phase will be impaired under foliage as I wrote above. I am finalising the firmware in these days (today I had logging with fatfs and USB MSC running simultaneously finally) but -as it is quite experimental- I cannot really claim that is a "set and forget" kind of solution. Firmware is open though and if you have programming skills you may modify it to your needs. I am also working on enclosures... I have the bare boxes but I need to hand-tool them. If you are happy to do it by yourself I can make a discount: http://www.onetalent-gnss.com/announcements/contributorsgetafreereceiver Unfortunately in any case I cannot make you a lower price than 250EUR+VAT+shipping as I hand assemble the boards and I don't sell many of them so I cannot reduce the price by producing volumes. I would love to help you but I understand that compared to a 100EUR logger it's a lot of money to invest. By the way, all new Mediatek receivers have 10Hz and very high sensitivity... the new MTK3333 also has Glonass. ST Microelectronics has the STA8088FG which performs very well and it's very low cost. Not to mention of course the usual CSR GSD4E and Skytraq Venus.. Have you looked at Fastrax, Locosys, and GlobalTop? I am very happy to help an enthusiastic mapper, please let me know if I can do something else for you. Best regards, Michele Hello, I'm looking for a GNSS module that could improve precision of my mapping efforts for Openstreetmap - mainly mountainbike trails and hiking paths in the Czech Republic (http://www.mtbmap.cz/). Up to now, I'm using Sirf3-based Garmin 60CSx mounted on the MTB handlebar, and MTK3329-based Holux M-1000C logger switched to 10Hz, mounted to my MTB helmet. While Garmin 60CSx produces reasonably precise results while hiking open-air, it has significantly worse behavior in hilly forests and 1Hz operation is not sufficient for accurately tracking shape of paths when riding fast on my bike. Holux provides improves tracking of fast motion, but it has usually significantly worse accuracy (i.e., wanders more) despite being mounted on top of my helmet and thus having good sky view. Thus I'm looking for a reasonably priced (<400 EUR, ideally 200-300EUR) solution for more accurate logging of MTB trails, ideally at 4Hz or better and approx. 1m accuracy - obviously I don't need 1cm accuracy, but I'd like to have 1m accuracy even under forest foliage. I don't need precise real-time output (Garmin will work fine for real-time navigation; having, e.g., additional Bluetooth NMEA output to verify operation, would be nice for the module, but it is not conditio sine qua non). I assume to put the device on my helmet again, replacing the Holux logger - so I shouldn't be excessively large or heavy. An alternative solution would be to have the device in my backpack and only put the antenna onto the helmet. The device should keep working on a battery for at least 6hrs. The ideal workflow for me is to keep the device logging into its internal memory, come back home, download the raw log and post-process it using RTKLIB to achieve 1m log accuracy, without need for paying recurring costs (such as CZEPOS professional DGPS correction). I'm doing this effort as a hobbyist, thus minimizing operational costs is important. Is there some solution for this in your portfolio? I was looking into Denga10LogBt, but I'm not sure if it meets my requirements - to sum it up: - battery operated for at least 6 hours - internal RAW logging for later processing - 1m accuracy under foliage (50cm accuracy would be absolutely perfect) - 4Hz or higher frequency (about 10Hz is ideal) - either whole device or at least the antenna should be helmet-mountable - helmet-mountable part of the device (or complete device) needs to be weather-sealed and needs to have reasonable weight (I can try to build my own housing, but not sure...) - post-processing should avoid need for paid data (such as CZEPOS) - ideally use open-source software to process the data Maybe my wishes still can't be fulfilled, but I've just stumbled over your website and the devices really look promising... Thanks, Petr
  2. hanoj ehanoj na gmail.com #m99e5c7
    Ahoj, nejsem si jist, zda si chces hrat s nekonvencnim merenim 2) nebo opravdu potrebujes jen lepsi klasicky pristroj 1). Nicmene problem lesa je predevsim vicecestne sireni signalu, utlum, terenni prekazky a voda po desti. 2) kodove mereni * frekvence vzorkovani signalu u kapesnich prijimacu neni problem 1hz, nikdy jsem se zatacenim nemel problem. Samozrejme v terenu vzdy existuje jista mira nejistoty/nepresnosti. * Garmin Vista co jsem mel byl pro mapovaci trackovani temer nepouzitelny 1) nekonformni mereni, tj. * fazova mereni * fazova mereni na vice GNSS * fazove mereni na vice frekvencich jednoho GNSS * fazove/kodove mereni s postprocessnim zpresnenim http://cs.wikipedia.org/wiki/GNSS * to o cem se pise nize v mailu je mereni fazove uplne odlisne od kodoveho, ma to sve vlastni problemy. Je hodne metod jak s tim pracovat... * abys mohl delat postprocessing potrebujes RINEX nebo podobny vystupni format a na korekce kdysi byl nejaky free sw, lze delat nad fazovym i kodovym merenim * samotne fazove mereni je nejednoznacne a ma problemy s prerusenim signalu Prakticky se mi to v roce 2007 nepodarilo dat dokupy sestavu s kodovym mereni+postproc. PS: jinak lesaci se touto problematikou docela casto bavi, napr: http://www.lesycr.cz/odborne-rady/granty-a-dotace/Documents/optimalizace_tds_pomoci_gps-web.pdf ha hanoj 2012/10/13 Petr Holub <hopet na ics.muni.cz>:
  3. Martin Kokeš shr3k na typo3-hosting.com #ma01f9d
    Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X na 5 Hz v kombinaci s funkcí Kalman Filter v http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html. Největší gró tam asi dělá ten Kalman filtr. Možná že by šlo použít pro postprocessing toto: https://github.com/lacker/ikalman Nicméně pro ostré zatáčky v lese by pomohl jedině GPS v kombinaci s gyroskopem/akcelerometrem. MK
  4. hanoj ehanoj na gmail.com #ma6b99e
    Nicméně pro ostré zatáčky v lese by pomohl jedině GPS v kombinaci s gyroskopem/akcelerometrem.
    *** to mne taky uz napadlo proc se to v praxi nepouziva, vzdyt 3D akcelerometr a elekro-kompas ma uz kazdy Android.... hanoj
  5. Martin Kokeš shr3k na typo3-hosting.com #m9c38d4
    Prý to je hodně špatné: http://stackoverflow.com/questions/7829097/android-accelerometer-accuracy-inertial-navigation Třeba by se dalo něco sestavit na platformě Arduino, ale to by musel nějaký znalec... http://arduino.cc/forum/index.php?topic=58048.0 http://arduino.cc/forum/index.php/topic,104951.0.html MK
  6. Zdeněk Zavadil zzavadil na gmail.com #m789d98
    Zdar, co třeba tohle: http://gpspp.sakura.ne.jp/rtklib/rtklib_beagleboard.htm (viz první odkaz na pdf) Zdeněk
  7. Petr Holub hopet na ics.muni.cz #m04caa1
    nejsem si jist, zda si chces hrat s nekonvencnim merenim 2) nebo opravdu potrebujes jen lepsi klasicky pristroj 1). Nicmene problem lesa je predevsim vicecestne sireni signalu, utlum, terenni prekazky a voda po desti.
    Jj, vim o tom - akorat bych se rad dostal tak daleko, jak by to do rekneme 10.000 CZK investice slo.
    2) kodove mereni * frekvence vzorkovani signalu u kapesnich prijimacu neni problem 1hz, nikdy jsem se zatacenim nemel problem. Samozrejme v terenu vzdy existuje jista mira nejistoty/nepresnosti.
    Dle mych zkusenosti hodne zalezi na rychlosti pohybu vs. pozadovane presnosti. V zasade bych chtel neco, s tim se bude dat natrackovat i tohle: http://www.openstreetmap.org/?lat=49.24047&lon=16.60118&zoom=17&layers=M (Soucasna metoda Holux M-1000C + Garmin 60CSx + hromada najetych tras je dost otravna a stejne moc presna.)
    * Garmin Vista co jsem mel byl pro mapovaci trackovani temer nepouzitelny
    To se nedivim - mne uz tech loggeru rukama proslo par a zatim bych rekl, ze Garmin 60CSx se Sirf3 chipsetem je zdaleka nejlepsi, co jsem zatim mel (kupoval jsem ho z druhe ruky, protoze podle rady zahranicnich testu je to prave otazka toho Sirf3 chipsetu, nez presli na Mediatek). Co se Mediateku tyce, tak ten Holux M-1000C ma v sobe MTK-3329 (tentyz, co ma Martin Kokes ve zminene Qstarz BT-Q1000X), ktery by na tom papirove mel byt lepe nez Sirf3. V aute to funguje taky celkem dobre, ale vozim ho i nahore na helme na kole (co nejmensi stineni signalu telem) a na tom kole je to furt o kus horsi nez ta 60CSx s Sirfem. Na druhou stranu to zjevne neni jen o chipsetu - v minulosti jsem pouzival igotU GT-120, ktery ma sice taky Sirf3, ale byl o rad horsi ne Holux, a to ve vsech aspektech.
    * to o cem se pise nize v mailu je mereni fazove uplne odlisne od kodoveho, ma to sve vlastni problemy. Je hodne metod jak s tim pracovat... * abys mohl delat postprocessing potrebujes RINEX nebo podobny vystupni format a na korekce kdysi byl nejaky free sw, lze delat nad fazovym i kodovym merenim * samotne fazove mereni je nejednoznacne a ma problemy s prerusenim signalu
    Ano, ty veci od OneTalent-GNSS jsou stavene na pouziti s RTKLIB (http://www.rtklib.com/), coz je predpokladam to, co mas na mysli. Jinak ten Rappen10LogBt je postaveny na NEO-6P, ktery to do jiste miry umi delat i primo v sobe bez postprocesingu - uBlox tomu rika PPP: http://www.u-blox.com/en/precise-point-positioning-ppp.html
    PS: jinak lesaci se touto problematikou docela casto bavi, napr: http://www.lesycr.cz/odborne-rady/granty-a-dotace/Documents/optimalizace_tds_pomoci_gps-web.pdf
    Jj, nasel jsem i jine, napr. http://warnell.forestry.uga.edu/warnell/bettinger/GPS/CJFE_33_1_149-157.pdf http://warnell.forestry.uga.edu/warnell/bettinger/GPS/MCFNS_4_2_81-91.pdf a dalsi.
    Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X na 5 Hz v kombinaci s funkcí Kalman Filter v http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html. Největší gró tam asi dělá ten Kalman filtr. Možná že by šlo použít pro postprocessing toto: https://github.com/lacker/ikalman
    Diky za tip - o Kalmanovic filtrovani jsem sice vedel, nicmene jsem si myslel, ze mi to moc nepomuze - u toho Holuxe mam problem v tom, ze on ma jakoby tendenci ustrelovat jakoby systematickou nikoli nahodnou chybou (tj. ne ze by ty body byly rozhazene kolem nejakeho spravneho prumeru, ale jsou ujete o nejak metry tam ci onam). Bohuzel nemam Windows Mobile, s nimiz bych to mohl primo pouzivat, nicmene jsem narazil na NMEA Processor, ktery by to mel taky zvladat: http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=106662&whichpage=21 https://sites.google.com/site/victorpomortseff/nmea-processor ale jeste ho budu muset trochu prozkoumat, co to vlastne umi.
    co třeba tohle: http://gpspp.sakura.ne.jp/rtklib/rtklib_beagleboard.htm (viz první odkaz na pdf)
    Beaglebord s RTKLIBem jsem videl - ale chtel jsem nejake reseni na cesty do batohu, ne do zasuvky :) Navic bych uprednostnoval nekutit - mapovani pro OSM mam primarne jako odreagovani, abych mel dobry duvod se dostat do prirody :)) Petr
  8. Petr Holub hopet na ics.muni.cz #m740c41
    Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X na 5 Hz v kombinaci s funkcí Kalman
    Filter
    v http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html. Největší gró tam asi dělá ten Kalman filtr. Možná že by šlo použít pro postprocessing toto: https://github.com/lacker/ikalman
    Diky za tip - o Kalmanovic filtrovani jsem sice vedel, nicmene jsem si myslel, ze mi to moc nepomuze - u toho Holuxe mam problem v tom, ze on ma jakoby tendenci ustrelovat jakoby systematickou nikoli nahodnou chybou (tj. ne ze by ty body byly rozhazene kolem nejakeho spravneho prumeru, ale jsou ujete o nejak metry tam ci onam). Bohuzel nemam Windows Mobile, s nimiz bych to mohl primo pouzivat, nicmene jsem narazil na NMEA Processor, ktery by to mel taky zvladat: http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=106662&whichpage=21 https://sites.google.com/site/victorpomortseff/nmea-processor ale jeste ho budu muset trochu prozkoumat, co to vlastne umi.
    Takze - uchodit jsem to uchodil a Kalman filtrovani dela presne to, co bych od neho cekal - odfiltruje tu "nahodnou chybu" (v uvozovkach to pisu proto, ze to, co jsem vyse oznacil jako "systematickou chybu" je ve skutecnosti taky nahodna, ale jina nez to kratkodobe driftovani. Pokud chcete, muzu nekam vystavit priklad, jak to dopadlo. Petr
  9. Martin Kokeš shr3k na typo3-hosting.com #m8759c1
    Určitě, ukaž, zajímá mě to. Já si tenkrát dělal porovnání současného záznamu Mediateku na 5 Hz s Kalmanem a Sirfu na 1 Hz vestavěného v HP RX5910 a ten Mediatek vypadal definitivně lépe. MK
  10. Petr Holub hopet na ics.muni.cz #me22218
    Určitě, ukaž, zajímá mě to. Já si tenkrát dělal porovnání současného záznamu Mediateku na 5 Hz s Kalmanem a Sirfu na 1 Hz vestavěného v HP RX5910 a ten Mediatek vypadal definitivně lépe.
    Takze 2 rychle priklady: - Kalmanovske filtrovani - priklad ze Zamilce, Holux M-1000C (MTK3329), 10Hz na kole; Kalamnuv filtr udelan NMEAprocessorem (predtim zkonvertovano do GPX GPSBabelem, protoze na tom puvodnim NMEA logu ten NMEAprocesor padal): http://arwen.ics.muni.cz/~hopet/tmp/osm-cz/kalman.zip - Holux M-1000C (MTK3329) vs. Garmin 60CSx (Sirf3); nevybiral jsem nic specialniho, vzal jsem log ze vcerejsi kratke vyjizdky na kole http://arwen.ics.muni.cz/~hopet/tmp/osm-cz/60CSx_vs_Holux.zip Znacna cast te trasy (nikoli cela) je projeta tam i zpet, takze je pekne videt, i jak moc to lita mezi prujezdy. Petr
  11. Petr Holub hopet na ics.muni.cz #maa4070
    Apropos, zapomnel jsem popsat soubory v tech ZIPech:
    Takze 2 rychle priklady: - Kalmanovske filtrovani - priklad ze Zamilce, Holux M-1000C (MTK3329), 10Hz na kole; Kalamnuv filtr udelan NMEAprocessorem (predtim zkonvertovano do GPX GPSBabelem, protoze na tom puvodnim NMEA logu ten NMEAprocesor padal): http://arwen.ics.muni.cz/~hopet/tmp/osm-cz/kalman.zip
    - 2012-09-08.gpx: puvodni mereni zaznamenane jako NMEA proud na Androidim telefonu, prekonvertovane do GPX GPSBabelem - 2012-09-08_kalman.gpx: data prohnana pres Kalmanovo filtrovani
    - Holux M-1000C (MTK3329) vs. Garmin 60CSx (Sirf3); nevybiral jsem nic specialniho, vzal jsem log ze vcerejsi kratke vyjizdky na kole http://arwen.ics.muni.cz/~hopet/tmp/osm-cz/60CSx_vs_Holux.zip Znacna cast te trasy (nikoli cela) je projeta tam i zpet, takze je pekne videt, i jak moc to lita mezi prujezdy.
    - 2012-10-13.gpx: Garmin 60CSx - 2012-09-11_09-10-32.nmea: Holux M-1000C Zdravi, Petr
  12. Jakub Sykora kubajz na kbx.cz #mcc56d4
    Ahoj, nebude se doufam nikdo zlobit, kdyz vysledek shrnu i pro ostatni tak, ze: 1) kalmanuv filtr data trosku vyhladi, takze nejsou zubata 2) vyhlazeni se pohybuje pro potreby OSM v zanedbatelnych mezich, nebot samotna chyba prijimace je radove daleko vetsi... Takze data jsou pri rozumne urovni priblizeni (treba v JOSM) uplne identicka. Pri hodne velkem zoomu je pak Kalman trochu min zubaty, ale prakticky vzato to nic moc neprinasi. Zajimave by to, IMO, bylo pouze tehdy, kdyz by to byla jedna z voleb treba v JOSM a kdyz si clovek otevre GPXko, tak by se mu takhle predfiltrovalo. Bylo by to hezke, ale nic vic, nic min :) K
  13. Jakub Sykora kubajz na kbx.cz #m16a1a6
    Je videt, ze oba pristroje se s tim popasovaly vicemene velmi dobre a skoro stejne!
  14. Petr Holub hopet na ics.muni.cz #m7b81f5
    Je videt, ze oba pristroje se s tim popasovaly vicemene velmi dobre a skoro stejne!
    - 2012-10-13.gpx: Garmin 60CSx - 2012-09-11_09-10-32.nmea: Holux M-1000C
    Z meho pohledu ne - ten Holux ma tak o 3-8m vetsi rozptyl nez ta 60CSx (je to typicky videt na tech cestak projetych tam i zpet). Petr
  15. Pavel Machek pavel na ucw.cz #m072217
    Ahoj!
    Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X na 5 Hz v kombinaci s funkcí Kalman Filter v http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html. Největší gró tam asi dělá ten Kalman filtr. Možná že by šlo použít pro postprocessing toto: https://github.com/lacker/ikalman Nicméně pro ostré zatáčky v lese by pomohl jedině GPS v kombinaci s gyroskopem/akcelerometrem.
    To by asi fungovalo v aute, ale na kole se obavam bude gyroskop/akcelerometr dost zmateny... (Hmm. a co teprv na konskym hrbetu...) Pavel
  16. Martin Kokeš shr3k na typo3-hosting.com #mf97a6a
    Mno já myslel, že gyroskop je právě gyroskopem od toho, aby zmatený nebyl. ;-) A že akcelerometr nefunguje jen v jedné ose. Nicméně,když taková zařízení fungují ve všem možném od RC vrtulníků, přes foťáky, Wii, Segway, auta až po kosmické sondy, kola i koně, nebo jiné přerostlé psy by to určitě zvládlo... MK
  17. Petr Kadlec petr.kadlec na gmail.com #mb49c33
    2012/10/15 Pavel Machek <pavel na ucw.cz>:
    To by asi fungovalo v aute, ale na kole se obavam bude gyroskop/akcelerometr dost zmateny...
    Oproti tomu ideální kombinace je při chůzi akcelerometr v botě, páč tam je vždycky chvilka klidu, kdy se dá resetovat, takže to nedriftuje? http://www.aetherczar.com/?p=2348 -- Petr Kadlec / Mormegil
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.