Kyosho Inferno Neo met een hightech sausje/telemetrie

Welke optische sensor heb je gebruikt? Ik ben bezig met een zelfde soort project. Arduino UNO, Xbee + sensoren.

Ik heb nu mijn testcase staan, seriële data stream naar de PC vanuit de arduino. Ik heb een C# Applicatie geschreven om realtime mijn data te plotten. Echter merk ik dat op hogere rpm ik leesfouten krijg. De optische sensor die ik gebruik zend infra rood en meet de reflectie. Maar wanneer de rpm boven de 800 komt te liggen zie ik toch echt vreemde meetwaardes.
 
Ik gebruik een QRD1114 hiervoor.

Deze is op zo'n 1,5 tot 1,8mm afstand geplaatst achter het vliegwiel. Op het vliegwiel heb ik voor de detectie ongeveer 1/6 vlak mat-zwart gemaakt.

Als je boven de 800 rpm al problemen krijgt met leesfouten e.d. dan heb je misschien een veel te langzame IR sensor, gebruik je deze niet goed, of doe je misschien in de software iets niet helemaal 'optimaal'. Of een sensor geschikt is kun je terugvinden in de diverse datasheets.

Om eventuele spikes door meetfouten te filteren kun je bij deze toerentallen overigens makkelijk een aantal samples nemen en daar een peak/noise-filter (in software) op toepassen. Of de minder nette manier en gewoon een X aantal samples nemen en het gemiddelde ervan bepalen.
 
Ik grbruik een magnetische sensor. Ik heb bij de conrad 2mm lange magneetjes gevonden met een 2mm doorsnede. Gewoon een 1.8mm gat in het vliegwiel boden en het magneetje erin persen.

By the way, hier een proggie van het conrad moduul:
http://www.euronet.nl/users/tooms/ftp/telemet.zip (werkt op zeker t/m Win7 32 bit)

Als iemand een Arduino zo kan programmeren dat het met dit progje werkt ben je snel klaar (en ik ook ;) )

Serielle Datenübertragung
-------------------------
Schnittstelleneinstellungen:
* von der Haupteinheit an den PC:
2400 Baud,
8 Datenbits,
keine Parität,
1 Stoppbit
* vom Memory-Modul an den PC (Blockmodus):
19200 Baud,
8 Datenbits,
keine Parität,
1 Stoppbit
Es werden nur Daten von der Haupteinheit an den PC übertragen. Die
Übertragung erfolgt im eingestellten Rhythmus (Framerate). Vom PC
gehen keine Steuerbefehle an die Haupteinheit.
Ein Datenrahmen umfaßt 14 Bytes und ist wie folgt aufgebaut:
Byte Daten
---- -----
1 8 Bit A/D-Wandlerwert vom Sensoreingang A (A1)
2 8 Bit A/D-Wandlerwert vom Sensoreingang B (A2)
3 8 Bit A/D-Wandlerwert vom Sensoreingang C (A3)
4 8 Bit A/D-Wandlerwert vom Sensoreingang D (A4)
5 8 Bit A/D-Wandlerwert vom Sensoreingang E (A5)
6 8 Bit A/D-Wandlerwert vom Sensoreingang F (A6)
7 8 Bit A/D-Wandlerwert vom Sensoreingang G (A7)
8 8 Bit A/D-Wandlerwert vom Sensoreingang H (A8)
9 8 Bits vom Digitalport
10 High-Byte des Zähler-/Frequenzmesserwertes
11 Low-Byte des Zähler-/Frequenzmesserwertes
12 Minuten-/Stundenwert der Stoppuhr
13 Sekunden-/Minutenwert der Stoppuhr
14 Hundertstel-/Sekundenwert der Stoppuhr
Die Zuordnung der A/D-Wandlerwerte (0...255) zu den physikalischen Meßgrößen
der von uns angebotenen Sensoren erfolgt in den meisten Fällen durch Tabellendateien.
Die Tabellen berücksichtigen eventuelle Nichtlinearitäten der Sensorkennlinien
und nehmen Rundungen vor.
Byte 12 enthält im MSB das Stopflag (kennzeichnet den letzen Datenrahmen
und die Stoppzeit nach dem Low-High-Übergang am Triggereingang).
Byte 13 enthält im MSB das Zeitformatflag der Stoppuhr:
0 = Minuten:Sekunden:Hundertstel
1 = Stunden:Minuten:Sekunden
Klik om te vergroten...
 
Toxical zei:
Ik gebruik een QRD1114 hiervoor.

Deze is op zo'n 1,5 tot 1,8mm afstand geplaatst achter het vliegwiel. Op het vliegwiel heb ik voor de detectie ongeveer 1/6 vlak mat-zwart gemaakt.

Als je boven de 800 rpm al problemen krijgt met leesfouten e.d. dan heb je misschien een veel te langzame IR sensor, gebruik je deze niet goed, of doe je misschien in de software iets niet helemaal 'optimaal'. Of een sensor geschikt is kun je terugvinden in de diverse datasheets.

Om eventuele spikes door meetfouten te filteren kun je bij deze toerentallen overigens makkelijk een aantal samples nemen en daar een peak/noise-filter (in software) op toepassen. Of de minder nette manier en gewoon een X aantal samples nemen en het gemiddelde ervan bepalen.
Klik om te vergroten...

Ik denk zelf dat de infrarood sensor zelf niet zo snel kan schakelen. Goedkoop dingetje. Daarnaast reflecteert infrarood eigenlijk alleen goed op spiegelend aluminium. Als het stoffig wordt zullen de meetwaardes ook afnemen. Dus om de software te maken is de testcase prima. alleen voor het inbouwen straks niet. Mijn arduino is in staat om meer dan 3000 meetwaardes te leveren per seconde op dit moment (dit moet ook meer dan genoeg zijn). Dit stream ik via een baudrate van 115200 via Serieel om het te plotten. De plotter kan de hoeveelheid data niet eens aan, buffers raken nog wel eens vol.

Ik zou in ieder geval niet kiezen voor een HAL sensor. Kan mij namelijk heel goed voorstellen dat deze sensoren op hogere RPM'S helemaal niet in staat zijn zo snel te schakelen. (Correct me if i'm wrong)

Een 2e probleem dat mij te wachten staat is dat ik de Arduino alleen als ISP wil gebruiken, om mijn zelf gemaakte AVM programmer aan te sturen. Zo ben in staat om met mijn ardruino andere chips te programmeren. Zoals een ATTiny (een stuk goedkoper dan een arduino (2 euro) ). In mijn final project zal er ook een attiny in de RC komen. en niet een volledige arduino. Ik hoop echter dat die dezelfde hoeveelheid aan meetdata kan leveren. Loopt ook op 16mhz. Maar een stuk minder geheugen en I/O's.

Geweldige projectjes, dat telemetrie gebeuren :-)

[EDIT]
Ik gebruik op dit moment een OPB706B sensor.

[EDIT2]
Ik denk dat ik weet waarom het bij mij ook moeizamer gaat. Jij hebt een vlak op een wiel kunnen maken. Ik probeer een streepje alu (2mm) uit te lezen op een ronde as. Dus het reflectie oppervlak is niet plat, maar gebogen.
 
npostma zei:
Daarnaast reflecteert infrarood eigenlijk alleen goed op spiegelend aluminium. Als het stoffig wordt zullen de meetwaardes ook afnemen. Dus om de software te maken is de testcase prima. alleen voor het inbouwen straks niet.
Klik om te vergroten...

De meetwaardes nemen inderdaad af naarmate de zaak stoffig wordt, logisch gevolg maar geen probleem. Er wordt namelijk alsnog meer dan voldoende gereflecteerd, vergeleken met een egaal mat-zwarte markering. Voor de juiste detectie is dit een kwestie van een threshold gebruiken. ;)

npostma zei:
Ik zou in ieder geval niet kiezen voor een HAL sensor. Kan mij namelijk heel goed voorstellen dat deze sensoren op hogere RPM'S helemaal niet in staat zijn zo snel te schakelen. (Correct me if i'm wrong)
Klik om te vergroten...

You're wrong... :D
 
Haha oke nice, dat had ik niet verwacht. Kan het wel tippen, of zelfs beter presteren aan een reflectie sensor?

Ik gebruik inderdaad een threshold. De eerste 2500 running cycles (software) worden gebruikt voor de calibratie, verzamelen van de aan en uit pieken. met een stelbare treshold standaard op 100. Arduino uno meet tussen 0 en 1023. Na calibratie meet ik vaak een hoog / laag verschil van 40 - 1000 dus dan pak 140 en 900 als omslag punt.

Als je gedesinteresseerd bent wil ik mijn code snippet wel op pastebin zetten. Wellicht heb je nog wat handige tips die ik kan gebruiken.
 
Dat is inderdaad in deze toepassing 1 van de grote voordelen van een hall sensor t.o.v. infrarood. Heb je overigens 1 magneetje gebruikt of 2 (om het vliegwiel niet in een te groot onbalans te brengen)?

Hier komt er t.z.t. ook een hall sensor op, die aanpassing is zo gedaan. Ik heb het eerst gemaakt met een IR sensor, ik had die toch liggen... Die zit er echter nog steeds op mede omdat ik met vuil/stoffigheid minder problemen heb dan verwacht. Zeg maar gerust geen want na een dag scheuren zet ik zowieso de compressor eventjes aan om de buggy 'schoon' te blazen.
 
IR vervangen door een HAL sensor is nog geen 15 min werk. Dus dat kan later nog. Ik heb nog wel een paar HAL sensoren liggen, alleen verkeerde type deze schakelen niet uit zichzelf terug. Ik zat te denken om de 2 x 4 mm magneet van conrad te gebruiken en die in de as te monteren. Ik heb een bigscale, die heeft een vrij dikke cardan as. Ik weet niet hoe dat zit met een nitro.

Zover ik weet heb ik geen (zichtbare) vliegwiel. Maar een mooi projectje heb je hier staan!

Waarom trouwens een webinterface? Ik heb op ebay voor nog geen 10 dollar een LCD schermpje gehaald. Die wil ik samen met een arduino monteren op mijn zender. zodat ik onder het rijden ook realtime de stats kan zien, zonder een laptop nodig te hebben. Wellicht een idee voor later :-)

Keep up the good work!
 
De voornaamste reden van een web-based applicatie is de cross-platform en cross-browser compatibiliteit, oftewel... Lekker universeel. Ik kan dus met ieder apparaat (PC, laptop, tablet, telefoon) de Raspberry Pi logger benaderen via een simpele URL.

Hedendaagse (relatief nieuwe) technieken zoals HTML5 en het gebruik van websockets maken dit goed mogelijk over iedere netwerkverbinding via wifi, bluetooth etc. etc.

De Raspberry Pi logger functioneert ook als wifi accesspoint. Kwestie van met je device (een tablet, laptop, telefoon of PC) connecten zoals je met ieder ander wifi netwerk doet. Browser openen en gaan met die banaan.

Op de voet van mijn zender ga ik een universele telefoonhouder monteren, dan kan ik dus ook m'n telefoon op de zender als display/besturing gebruiken en hoef ik daar geen speciaal kastje met display voor te maken zoals jij van plan bent. Dat kan ik op deze manier zelf niet beter/goedkoper/makkelijker maken dan het gebruik van een smartphone met touchscreen en al.
 
Telefoon op de zender monteren is inderdaad een goede optie! Wellicht is je interface dan ook een stuk strakker dan op een 1.8" inch scherm met een resolutie van 240x130.

Ik moet zeggen dat mijn keuze ook meer uit interesse voor embedded software is. Met zo min mogelijk software lagen.

Ik ben benieuwd wanneer jou gehele systeem operationeel is, Keep us posted!
 
Vandaag van Conrad m'n bestelde powerbank binnen gekregen. De Raspberry houdt het zo wel de nodige uurtjes uit zonder netspanning in de buurt. Wellicht zondag de hele dag wat gaan testen @ ORMCO. :D

 
You must log in or register to reply here.
Back
Top