Arduino gebruiken op de motor

Gixxer-harry

MF veteraan
4 jun 2006
3.244
1
Gasselte
Ik ben op het net de Arduino tegen gekomen en ik heb er eentje besteld want er zijn vast heel veel leuke dingen mee te maken voor op de brommert
Kennen jullie dit en doen jullie er ook leuke dingen voor de motor mee?
 
Met een Arduino, of een basic ATmega, is het wel makkelijker om real-time metingen te doen. Op een PI draait je programma boven op een operating system, en je kan niet voorspellen wat die allemaal doet terwijl je programma draait.

In de praktijk zal het juist moeilijker blijken omdat je programma zich in allerlei bochten moet wringen om dingen te compenseren die op een basic Arduino nooit zullen gebeuren.

Heb je meer kracht nodig dan een ATMega (of Arduino) heeft? Probeer dan een ARM LPCxxxx processor. Ook bij Voti te koop, leuke bordjes met veel kracht voor weinig geld. Bijvoorbeeld deze: http://www.voti.nl/winkel/catalog.html?ARM-P1343.

Totaal niet met je eens... op de PI draait een Debian variant, als jij je tools in C of python schrijft kan je prima voorspellen wat er gebeurd..... (het is geen windows _O- )

*Offtopic, Mijn Arduino's liggen in de hoek en zijn vervangen door de PI
 
Laatst bewerkt:
Misschien een idee om van Arduino te switchen naar een Raspberry-pi.
Persoonlijk vind ik die wat makkelijker te programren je hebt gewoon wat meer "vrijheid" dan een arduino.

Ligt compleet aan je toepassing. Voor mijn laatste project, mn gear indicator, is zo'n arm 9, (of wat zit er op?) complete overkill, veel te groot, veel te hoog stroomverbruik enz enz. Zo'n raspberry bordje incl operating system ga je pas gebruiken wanneer je dingen als ethernet, usb (host), audio ed nodig hebt. Dat is niet meer te doen als je het zelf allemaal moet gaan implementeren en ga je voor een operating system wat het voor je regelt.

Zelf heb ik niet veel ervaring met embedded linux. Er zijn best wat mogelijkheden om dingen realtime te doen, maar dan moet je bedreven zijn in het gebruik van interrupts ed.
 
Blijkt dat een ponyser programmer niet werkt met een PL-2303 usb-serial chip. Ik heb hem aan de enige PC met een ingebouwde seriele poort gemaakt, en voila ik kan AVRs branden! Ik heb even geprobeerd een USB loader erop te zetten en dat lijkt te lukken alleen heb ik nog geen test programma om te zien of hij daadwerkelijk werkt dus dat zal ik wel gaan schrijven dan. Ben verrassend genoeg nog klaarwakker! Toch maar preventief slapen. *zet soldeerbout uit*
 
Totaal niet met je eens... op de PI draait een Debian variant, als jij je tools in C of python schrijft kan je prima voorspellen wat er gebeurd..... (het is geen windows _O- )

*Offtopic, Mijn Arduino's liggen in de hoek en zijn vervangen door de PI

Er draait dus een operating system op, en je programma draait in 'user-mode'. Het operating system heeft dus een hogere prioriteit dan jouw programma. Jouw programma is in feite een slaaf van het operating system.

Als het operating system besluit om dingen te doen (geheugen garbage collection, interrupts afhandelen, whatever), dan wordt jouw programma gewoon even tijdelijk stil gezet. En daar gaat je meting, waarvan je dacht dat die precies was...

En dan moet je gaan uitzoeken wat het OS nou deed, en proberen daar omheen te werken. Etc. etc.

Ik ben al meer dan 30 jaar computers aan het programmeren. De enige reden waarom ik niet al mijn kennis in één keer spui is omdat het veel te veel is.

Om je een voorbeeldje te geven: op een ATMega wordt een interrupt altijd in dezelfde hoeveelheden clockcycles uitgevoerd (interrupt latency). Op een Raspberry PI is de interrupt latency variabel, afhankelijk van wat het OS (uclinux) toevallig aan het doen was.

Dus zijn de interrupts niet te gebruiken voor real-time metingen. Maar er zit op zo'n PI ook geen hardware-counter, dus je hebt geen alternatieven.

Er is wel wat aan te doen. Je kunt namelijk een nieuwe linux kernel bouwen met real-time extensies. Of misschien OS-9 erop zetten. En daar ga je dus al. Meer werk dan wanneer je meteen een ATMega, of zo'n LPC bordje had gepakt.

Daarbij zijn die linux extensies 'soft real-time', dwz. het is nog steeds niet real-time (een voorspelbare latency), maar er worden in ieder geval gegarandeerde maximale reactietijden gegeven.
 
Laatst bewerkt:
Totaal niet met je eens... op de PI draait een Debian variant, als jij je tools in C of python schrijft kan je prima voorspellen wat er gebeurd..... (het is geen windows _O- )

Om nog even duidelijk te zijn. Ik voorspel in dit geval dat je een kilometerteller of toerenteller gaat krijgen die bij een vaste snelheid of vaste toerental een beetje heen en weer loopt te zwaaien. Mogelijk dat 'ie af en toe een onverklaarbaar sprongetje vertoont.

Ga je die gegevens dan gebruiken voor een gear indicator, dan geeft die op onverklaarbare wijze regelmatig de verkeerde versnelling aan.

Gebruik je het voor een shiftlight, dan zal die af en toe een beetje staan te knipperen.

Gebruik je het om je ontsteking aan te sturen, dan zul je regelmatig knallen te horen krijgen.

Elke kleine fout in je metingen vermenigvuldigt zich in je besturingen.
 
Bovenste print bevat een PIC16f688, een 100nf condensator en 8 voorschakelweerstanden (0603), op de onderste print zit een spanningsregelaar (LD1117) en nog wat condensator/weerstanden grut. Om het stroomverbruik laag te houden zet ik maar 1 segment tegelijkertijd aan. Door dit heel snel te wisselen (1ms) zie je er niks van :).

Waarom zou je het stroomverbruik laag willen houden? Er zit toch een vette accu op een motor, en die laadt tijdens het rijden toch bij?

Ook is er wel degelijk een effect als je de segmenten op deze manier aanstuurt. De helderheid gaat omlaag. Op een bewolkte dag is de helderheid misschien nog genoeg, maar op een zonnige dag moet je al een flinke helderheid hebben omdat je anders niks kan lezen.

Ik begrijp wel dat je het doet omdat je anders te weinig outputs hebt.

Je kan natuurlijk dan de stroomsterkte naar de segmenten verhogen door kleinere weerstanden te gebruiken. Maar eigenlijk ga je dan over de maximale specificaties van de leds heen. Dat beinvloedt de levensduur.

De andere oplossing is om een latch te gebruiken. Om I/O poorten op de CPU te sparen, kun je dan een serieele latch gebruiken: 74594, 74595. Kost je wel een beetje extra ruimte op je printplaatje, natuurlijk. ;)

Maar als je verder niet zo veel I/O poorten nodig hebt (volgens mij kun je dan met 5 I/O poorten wegkomen), dan kun je ook een PIC in een 8-pins package gebruiken. Scheelt ook weer wat ruimte op de print.
 
Laatst bewerkt:
Die ruimte heb ik allemaal niet ;). Combinatie van een voeding en een uC die de totale stroom, volgens de specs, maar net aan kan. Op deze manier zit ik er ruim onder.
 
Arduino maakt gebruik van kant en klare blokken code, die alles sequentieel uitvoeren. Wil je een blok data verzenden via bijv. spi, gaat dat blok eerst al die data uitklokken om daarna door te gaan met de volgende instructie. Dit kun je overigens ook zelf in C kloppen, zijn wellicht ook libraries voor te vinden.

...

Ik werk niet met Arduino libraries, heb voor een timing-probleem wel gekeken hoe het in hun library is geimplementeerd. Ze hebben keurig interrupts gebruikt op een manier zoals ik het zelf ook geschreven had. In feite is Arduino een extra layer van libraries, in c++ geschreven en in te zien, die het voor de gebruiker gemakkelijker maakt. De gecompileerde code hoeft niet slechter te zijn.

Maar ik ben het met je eens dat gebruiksgemak niet gratis komt. Je bent minder flexibel in het kiezen van de hardware en de ongecompileerde code is groot door verschillende definities voor de kleine hardware variaties die er nog zijn. Op een gegeven moment wil je toch de volle flexibiliteit. Voor mij een reden om direct met GCC te starten, maar Arduino staat dat niet in de weg. Gewoon eigen libraries maken.

Misschien een idee om van Arduino te switchen naar een Raspberry-pi.
Persoonlijk vind ik die wat makkelijker te programren je hebt gewoon wat meer "vrijheid" dan een arduino.

:N
Zware overkill. Als "pong" spelen op een IBM Blue Gene zonder joystick :+
En dan ook nog gevangen zijn in systeemsoftware, waardoor pong net te laat reageert...

Wel interessant voor multimedia op je motor :')
 
Zo, de programmer werkt dus, ook de USB bootloader zo lang ik die include in het programma. Ik heb een programma geschreven (lees: bij elkaar gecopypaste) waarmee ik met een potmeter de frequentie van een knipperende LED kan besturen. Ik loop een beetje tegen de grens van mijn C kennis aan (vooral icm microcontrollers) dus ik ga even wat anders doen, komende week een hoop inlezen en volgend weekend weer verder denk ik. Ik ben in ieder geval voorlopig over op een gewone AVR, meer uit ongeduld maar goed dat lukt ook wel :P
 
Mooi topic!

Ik ben ook bezig met een Arduino op de motor. Wil hem mooi verwerken in mijn cockpit. Nou heeft een Bandit 600 twee ronde chrome tellers in de cockpit. Daar wil ik een derde tussen maken zoals de Bandit 1200 heeft. Ik wil daarvoor een oude fietslamp gaan gebruiken, zo'n chrome. Daarin komt een 1,5" vierkant OLED schermpje met GOLDELOX GPU van Sparkfun Wanneer er in die lamp nog ruimte is komt daar ook de Arduino, anders gaat die onder de tank. De Arduino krijgt ook een Bluetooth module zodat die met mijn telefoon kan koppelen. Die gaat met de GOLDELOX communiceren om dingen op het scherm te toveren.

Geplande features:

Sensoren:
- Benzinemeter
- Lean angle meter (verder dan bijv 35 graden? weergeven gedurende 3 sec na de bocht)
- Temperatuurmeter (laag bij de grond, voor gladheid, en carb freezing)
- Acceleratiemeter (0-100 sneller dan 6 seconden? weergeven gedurende 3 sec)
- Lichtsensor (automatisch schakelen OLED helderheid)

Softwarefuncties
- Controleren op flitsers via flitsservice ed
- Tijd weergeven
- Navigatie via Google Maps (GPS, Polyline en routing API, werkt al met 28.800 waypoints!)
- Automatisch navigatie instellen (adhv Google Now calendarnotificaties)
- Voorspellen regen op de route (Buienradar API)
- Beheren muziek (op telefoon of internetradio, via BT naar de helm)
- Loggen van ritten (op de smartphone, dus geen gedonder met SD kaarten)
- Spraakbesturing!


En dat alles moet, wanneer het niet via spraakbesturing gaat, aangestuurd worden met een enkele joystick (U, R, D, L, Ok) bij het rechter handvat. Op de OLED wacht ik nog, communicatie Arduino <=> Android via Bluetooth heb ik al werkend :) Die GOLDELOX processor schijnt vrij eenvoudig te zijn (normale commands via serial interface) dus daar verwacht ik geen problemen mee. Lastige is het programmeren van de software. Die moet dus gaan draaien op Android, maar grafische bewerkingen zelf via BT naar de GPU sturen. Geen ondersteunende basis dus.. Heb nu een tussenlaag geschreven die ik vertel wat hij moet doen (text, line, circle, rectangle) en die dat afhandeld. Twee standen, één is op de telefoon, de andere is doorrammen over Bluetooth. Abstractie dus :) Lijkt redelijk te werken, alleen het wachten is nog op het OLED schermpje..


Lastig, maar wel leuk om te doen :)
 
Mooi topic!

...


Lastig, maar wel leuk om te doen :)

Klinkt heel vet! Houd ons op de hoogte, want we willen natuurlijk foto's zien :+ en code! Dat schermpje is ook wel erg interessant, nog niet eerder gezien. Misschien ook maar eens in verdiepen wat dat allemaal kan.

Een Arduino (vooral een mini pro of een nano of zo) moet makkelijk in dat ding passen, als het een beetje compact gebouwd wordt.
 
Klinkt heel vet! Houd ons op de hoogte, want we willen natuurlijk foto's zien :+ en code! Dat schermpje is ook wel erg interessant, nog niet eerder gezien. Misschien ook maar eens in verdiepen wat dat allemaal kan.

Een Arduino (vooral een mini pro of een nano of zo) moet makkelijk in dat ding passen, als het een beetje compact gebouwd wordt.


Ga ik natuurlijk doen. Momenteel nog niet echt iets te laten zien. Ben nu bezig om de software op de telefoon verder af te maken. Ik zuig in Java, dus ben maar in PhoneGap met Javascript gaan werken, waar nodig ondersteund met Java als de performance krap werd. Android <=> Arduino koppeling ligt alweer uit elkaar omdat de Arduino weer Ambilight is gaan spelen achter mijn TV, maar een nieuwe is onderweg. Wordt ook weer een Nano, dus dat moet opzich passen. Omdat er ook BT bij zit, heb ik het liever niet direct onder de tank bij de bobines, kan nooit goed zijn. Een andere oplossing is onder het zadel zodat die dichter bij mijn telefoon zit, maar ik denk dat dan de kabel naar de GPU wat aan de lange kant wordt.. Kwestie van proberen :)

Ik zal jullie op de hoogte houden in ieder geval :)
 
Met wat voor sensor wil je de hellingshoek meten? Hou er rekening mee dat dat niet gaat werken met een sensor die de zwaartekracht als referentie gebruikt :)

Heel wat leuke plannen, succes!


Misschien toch wel want als je een vector-plaatje maakt van de krachten die op de motor werken, dan is volgens mij de hellingshoek direct gelinkt aan de kracht-vector die in de top-as richting werkt van de motor. Dus als je een G-sensor monteert die vast aan de motor in de richting van de top-as meet, dan kun je daarmee de hellingshoek berekenen. Het klopt waarschijnlijk niet meer helemaal als je er als rijder flinkt naast gaat hangen, waardoor de motor een iets kleinere hoek maakt (de reden voor het hangwerk). Maar met de deze sensor + nog een G-sensor haaks erop moet je de horizontale component (centrifugaal versnelling) kunnen berekenen en daarmee deze hoekcorrectie kunnen maken. Kun je meteen zien hoe effectief het "verzitten" werkt bij je :+ De meeste versnellingssensoren-chips meten standaard 3-assen xyz.
 
Misschien toch wel want als je een vector-plaatje maakt van de krachten die op de motor werken, dan is volgens mij de hellingshoek direct gelinkt aan de kracht-vector die in de top-as richting werkt van de motor. Dus als je een G-sensor monteert die vast aan de motor in de richting van de top-as meet, dan kun je daarmee de hellingshoek berekenen. Het klopt waarschijnlijk niet meer helemaal als je er als rijder flinkt naast gaat hangen, waardoor de motor een iets kleinere hoek maakt (de reden voor het hangwerk). Maar met de deze sensor + nog een G-sensor haaks erop moet je de horizontale component (centrifugaal versnelling) kunnen berekenen en daarmee deze hoekcorrectie kunnen maken. Kun je meteen zien hoe effectief het "verzitten" werkt bij je :+ De meeste versnellingssensoren-chips meten standaard 3-assen xyz.


Je kunt een high-pass filter gebruiken om te bepalen wat je kanteling t.o.v. de zwaartekracht (constante > 0Hz) is.
 
die meet relatieve beweging, wat is je 0 punt?
Is wel wat op te bedenken natuurlijk, als je stil staat kan je een "0" punt nemen als je ook een accelerometer gebruikt..

Een gyroscoop blijft in dezelfde stand staan (wet van traagheid). Aan de hand daarvan kun je meten wat de stand van de motor t.o.v. de gyroscoop is.

Of denk ik nou compleet mis? Mijn smartphone kan immers ook zijn hoek bepalen met zijn gyroscoop. Of zou dat dan met compas gaan?

Edit: Andere optie is een afstandssensor onder de motor plakken, bijvoorbeeld bij de voorvork. Recht naar beneden en niet precies in het midden. En dan kijken wat het verschil in afstand is bij een bocht. Moet er wel wat wiskunde aan te pas komen, maar er zijn vele mogelijkheden voor.
 
Laatst bewerkt:
In een smartphone zit een versnellingssensor (xyz?) die geen traagheid meet maar de versnellingskrachten in verschillende xyz richtingen (ax,ay,az).

De zwaartekracht ag is altijd constant :+ , dus op zich geen filter nodig, behalve misschien om de invloeden van het bumpy asfalt weg te filteren. Ik ga er even vanuit dat het niet interessant is om de hellingshoek tijdens jumps te meten...

Ga je de bocht door, dan hoort daarbij een berekenbare (centripetale versnelling) kantelhoek tussen deze vector en het totale zwaartepunt van jouw en je motor. Zit je perfect in lijn met je motor, dan zou je alleen een ax > 1.0G moeten meten en 0 ay. Ga je verzitten, dan zal de motor iets minder hoek hebben, waardoor een ay component ontstaat.

Wiskundig:

Hieronder wordt met ax en ay de signalen, gemeten met de versnellingsopnemer bedoeld. ac en ag zijn de centripetale en gravitatie versnellingen.

1. Resulterende versnellingskracht gemeten met ax en ay moet gelijk zijn aan die berekend met de centripetale versnelling en zwaartekracht:
ar = √(ax2 + ay2) = √(ax2 + ay2)
» ar bekend​

2. De hellingshoek tussen het zwaartepunt en de horizon (weg) is (hellingshoek zwaartepunt = 90-ß):
cos(ß) = ag / ar
» zwaartepuntshoek ß bekend​

3. De relatie tussen de gemeten y-component en het verschil in hoek van het zwaartepunt tov. de weg met en die van de motor (δß):
ay = ar * sin(δß)
» motor hoek met horizon = ß + δß bekend​
» motor hoek met vertikaal = 90 - ß - δß​

Een grote δß betekent dus dat het verzitten erg effectief was (of het nodig was en er stijlvol uitzag is een 2e)

Schiet maar lek :+
 
Ik ben aan het beredeneren hoe je dit nu uitlegt. Om te beginnen, hoe ligt je x, y en z-as? Zoals het IC op de print ligt:
geosphir.gif


Of de X-as horizontaal, y-as verticaal en de z-as in de lengterichting van de motor?
xyz-coordinates.png



ar = √(ax2 + ay2) = √(ax2 + ay2)

Is dit inderdaad wat je bedoelt? In feite staat er:
4 = 2 + 2 = 2 + 2

Ik heb totaal geen achtergrond bij dit soort berekeningen van krachten, ik moet nog wat moeite gaan doen om goed te begrijpen wat je hier beschrijft. Daarnaast verdwaal ik in wat afkortingen (zoals ar), wat het er niet makkelijker op maakt :P. Maar is het mogelijk om met alleen een sensor die de versnelling meet de exacte hoek ten opzichte van de horizon te meten?

Zijn er ook sensoren die deze data kant en klaar afleveren? :P
 
Laatst bewerkt:
Terug
Bovenaan Onderaan