Flitspaalmelder problemen

Postby joeri fr » Mon Feb 08, 2010 12:00 am

Ben,
Ik dacht even na over de segment-detectie ipv cirkel.
Misschien lukt het als volgt;

Gegevens:
- snelheid
- positie
- richting (kompas)

Hieruit kunnen we afleiden:
- de straal waarbinnen we willen detecteren (als functie vd snelheid)
- de hoek van het segment (als functie van de snelheid)
- de ligging van het segment (als kompas°)

Hiermee is het segment volledig beschreven (huidige positie x,y - ligging segment hoek alpha & straal r + breedte van segment hoek delta)

Een flitspaal heeft coordinaten x1,y1

Ten opzichte van x,y kunnen we dus zijn afstand berekenen (moet kleiner zijn als straal r)
Indien zijn afstand kleiner is als straal r (gewonen cirkeldetectie, denk ik),
Kunnen we kijken of de hoek beta (= atan[(y1-y)/x1-x)] ligt tussen alpha + delta en alpha - delta.

Hopelijk begrijp je mijn bedoeling...
joeri fr
 
Posts: 87
Joined: Thu Jan 02, 2014 3:27 pm

Postby schueler » Mon Feb 08, 2010 12:00 am

Joeri Frik denk dat 't x6/10 is, ipv omgekeerd om decimaal naar ° om te zetten. En dat de char een int moet zijn (of small int) om overflow te vermijden.

Yep, dat stond verkeerd.


Joeri FrEn om de leading 'nul' in de notatie weg te krijgen moet er nog even '0' van worden afgetrokken, daar het een leeg karakter is (' ').


Leading zero was al verwijderd... maar ik zoals je wilt.... ik vervang het wel met een spatie...


Ben
schueler
 
Posts: 1433
Joined: Thu Jan 02, 2014 10:40 am

Postby joeri fr » Wed Feb 10, 2010 12:00 am

ok.
Ik vraag me nog het volgende af;
De coordinaten uit de poi-lijst worden in 6 bytes opgeslagen.
3 bytes (0xffffff) voor lat en 3 voor lon.
Elke coordinaat tussen + en -180° moet dus worden afgerond.
Dit geeft een nauwkeurigheid van 360/16777215 of 0,0002°
Veel kans dat we de POI-warner enkel in Europa gebruiken, en voldoende hebben aan +/-99° lat. Dan hebben we 10-keer hogere nauwkeurigheid zonder iets te moeten doen.
Is dit zo?

Hoe worden de coordinaten nu in de eeprom bytes geplaatst?
joeri fr
 
Posts: 87
Joined: Thu Jan 02, 2014 3:27 pm

Postby schueler » Wed Feb 10, 2010 12:00 am

Ik heb (eer)gisteren al zitten stoeien en heb al wat werkend.
Er zit alleen nog ergens een foutje in de berekening voordat ik er de tan van neem...
Moet ik nog even uitzoeken.


Ben
schueler
 
Posts: 1433
Joined: Thu Jan 02, 2014 10:40 am

Postby schueler » Wed Feb 10, 2010 12:00 am

Joeri Frhet is de V9.7 (en picc 9.6 denk ik)

Dat zal dan wel 9.63 zijn...
Momenteel is het V9.63-PL3 de meest recente versie.

Joeri FrIk heb deze namiddag wel terug iets raars gehad: dicht bij een flitspaal aan een rood licht begon de radar telkens hoog te gaan en terug af te vallen. Zeker tot ene 500m na de paal.
En vanaf dan was dat zo voor iedere paal die ik tegenkwam.
Misschien ergens eens variabele die een rare waarde krijgt?

Beats me! Maar als je versie 1.17 of eerder gebruikt zou het wel kunnen, ik zal de een versie 1.19 uitbrengen zonder naderingsfunctie, dus alleen cirkel detectie om de paal heen.
Vanavond even tijd vrij maken hiervoor...

Joeri FrKun je mij kort uitleggen wat er in search_eeprom gebeurt?
Met de info in het programma kom ik niet erg ver :/
Het is namelijk erg moeilijk te achterhalen hoe iemand anders de variabelen gebruikt...

Phoe, daar vraag je me wat. Dati s niet 1-2-3 uit te leggen. Ik heb hier veel uren in gestoken om dit goed et krijgen en de variabelen, tja, zijn niet altijd duidelijk in naam.

Grof genomen ga ik eerst met een binairy search door het geheugen heen om de dichtstbijzijnde longitude te vinden ( Mode 1 ). Als ik deze gevonden heb en er is geen hit, dan ga ik over de longitude naar boven zoeken vanaf dat punt zolang de longitude binnen de zoek afstand blijft ( Mode 2 ). Als er dan nog niets gevonden is dan zoek ik vanaf hetzelfde punt naar beneden zolang de longitude binnen de zoek afstand blijft ( Mode 3 ).
Als ik een POI uit het EEPROM geheugen heb gehaald wordt de compare functie aangeroepen om de positie van de GPS te vergelijken met de POI. Dit is een vrij ingewikkeld verhaal om even hier zo uit te leggen. Kort gezegd word eerst gekeken welke van de twee de grootste longitude heeft en daarna welke latitude groter is van beide. Aan de hand hiervan wordt de delta van beide uitgerekend waarmee wordt gekeken of de POI zich binnen de zoek afstand bevindt. Zo ja, mag de RADAR geactiveerd worden. Binnen deze loop wordt ook gekeken of de paal benaderd wordt of dat de afstand tussen gps en poi steeds groter wordt. Wordt het groter dan ben je de paal voorbij en mag de detectie uit.


Ben
schueler
 
Posts: 1433
Joined: Thu Jan 02, 2014 10:40 am

Postby joeri fr » Wed Feb 10, 2010 12:00 am

het is de V9.7 (en picc 9.6 denk ik)

Ik heb deze namiddag wel terug iets raars gehad: dicht bij een flitspaal aan een rood licht begon de radar telkens hoog te gaan en terug af te vallen. Zeker tot ene 500m na de paal.
En vanaf dan was dat zo voor iedere paal die ik tegenkwam.
Misschien ergens eens variabele die een rare waarde krijgt?

Kun je mij kort uitleggen wat er in search_eeprom gebeurt?
Met de info in het programma kom ik niet erg ver :/
Het is namelijk erg moeilijk te achterhalen hoe iemand anders de variabelen gebruikt...
- Joeri
joeri fr
 
Posts: 87
Joined: Thu Jan 02, 2014 3:27 pm

Postby joeri fr » Wed Feb 10, 2010 12:00 am

het is de 1.19 die ik gtebruik.

dank voor de uitleg omtrent search_eeprom.
Ik pluis het wel verder uit.

De strings die we gaan nodig hebben voor de segmentdetectie zijn:
gprmc.compass
gprmc.speed
gps.gps_long_degree
gps.gps_long_minute
gps.gps_long_decimal
en ook de lat's

en de flitspaal coordinaten.
En waar zittten die in?
gps.gps_long_degree
gps.gps_long_minute
gps.gps_long_decimal
en lat

Is i2c_addr de positie van de eerst gevonden flitspaal binnen de cirkel?
joeri fr
 
Posts: 87
Joined: Thu Jan 02, 2014 3:27 pm

Postby joeri fr » Wed Feb 10, 2010 12:00 am

wel of geen onbeduidende nullen maakt in ieder geval niks uit in de POI-file (met gereduceerd aantal POI's tot +/-8000 werkt alles netjes.

De truncate warning, denk ik, wijst erop dat je een waarde met hex 0x100 afkapt tot 8bits. Mar dit is een waarde van 255, en dan kan het wellicht geen kwaad...
joeri fr
 
Posts: 87
Joined: Thu Jan 02, 2014 3:27 pm

Postby schueler » Wed Feb 10, 2010 12:00 am

Ok, dit kan te maken hebben met een fout die ik versie 1.18 opgelost heb. Hier bleek dat ik een variabele twee keer corrigeerde waardoor het zoek algoritme nooit boven de waarde 65535 uit kon komen.
In versie 1.18 is het probleem verholpen.


Betreft truncate, dat baat mij wel zorgen.
Welke versie van Hi-Teh C compiler gebruik je?


Ben
schueler
 
Posts: 1433
Joined: Thu Jan 02, 2014 10:40 am

Postby joeri fr » Thu Feb 11, 2010 12:00 am

De reden dat ik hieraan denk, is dat de plaatsen zowiezo worden afgerond door het 6-byte systeem.
Daardoor zullen we, ondanks de laterale coordinaat te sorteren, plots een aantal gelijke laterale coordinaten krijgen in de lijst.
De longitudinale zullen dan niet gesorteerd staan.
Kan dit kwaad in je zoekalgoritme?
(ik denk trouwens dat dit zoekalgoritme makkelijker kan, maar daar zoek ik wel even op).
joeri fr
 
Posts: 87
Joined: Thu Jan 02, 2014 3:27 pm

PreviousNext

Return to 2008-11 Flitspaalmelder

Who is online

Users browsing this forum: No registered users and 1 guest