Vad har jag gjort... (bilbanetillbehör, slotracing)

[Erik M]

... är lite av varje för bilbana.
Och för slotracing, vilket egentligen är samma sak.

Det är fyra projekt, som går under samlingsnamnet MCR.
MCR Chase Car (CC), dynamisk autonom slotcar - kör runt banan som du själv, minst.
MCR Raceline Racing (RLR), sammanför analog och digital slotracing - till mer fröjd.
MCR Control (eQ), digitalt fartreglage för både hem & klubb - med annorlunda lösning.
MCR 64~nånting (MCR-64), digitalt slotracing system - med plats för trettiotvå förare...
(...och trettiotvå Chase Cars.)

Nedan når ni en tidig presentation av MCR Chase Car, då MCR DASC...
(...men hustrun insisterar på Chase Car, "för den jagar dig". Benämningen Chase Car är dock använd redan, av Chase som gör Chase Cars - slotcars som kränger och ser tuffa ut när de tar sig runt banan.)

Peek Preview DASC 01

I videon ovan använder jag en (dubbel-) komparator för styrning av bilens hastighet genom kurvor och bromsande inför dem.
Bilen i sig har två sensorer, en som talar om att bakvagnen hänger ut och en som talar om att det kommer en kurva.
Runt banan sitter det signalgivare, bromspunkter, som ger bilen order om att bromsa.
Bromsen hänger i tills bilen antingen ...
1) når en minimum hastighet - som den håller (tills ...)
2) når en andra bromspunkt - varvid den accelererar mot full fart.
3) når en kurva - varvid kurvsensorn tar över.
Kurvsensorn löser ut när bakvagnen hänger ut - varvid bilen ges en aningen lägre (PWM-) hastighet.

Denna inledande analoga modell fungerar utmärkt, och behöver inte egentligen digitaliseras.
Med digital styrning kan dock ett antal funktioner, som kan vara bra, läggas till.
Sådant som att automatiskt känna av och tolka sådana signaler som start, stopp och safety car etc.
Så jag började med PIC i april (?) - från noll.
Och börjar närma mig lite av varje.

Nedan video visar MCR RLR anpassad till Scalextric Digital System (SSD).
Förutom att bidra med RLR, inklusive anti-kollision, åtgärdar MCR RLR problemet med att SSD i original inte tillåter spårbyte från slipstream. Dvs du måste ligga minst en decimeter bakom framförande bil för att bilarna ska kunna välja egna spår. (Beroende på det exakta, för korta, avståndet bestämmer den framförvarande eller den bakomliggande om båda ska byta spår eller ej...)

5-6 cars 12 min stress test

Jag började även här analogt och med komparatorer.
Digital hantering av processerna ger dock möjlighet till mer utförlig styrning, så även här gick över till PIC, och Assembler.
Speciellt kan man fånga och använda betydligt bättre tidsintervall för de olika funktionerna.


MCR-64 ligger långt bak i kön.

MCR eQ följer tätt efter MCR CC, de flesta processerna finns i båda projekten.


Detta är vad jag kommer hit och söker hjälp/information/intresse för...
...och ni som hjälpt till - Ett Stort Tack!

Ett extra, och stort, tack till Lars Koksholm, Danmark, utan vars intresse och generösa stöd de som använder SSD inte kommit att kunna nyttja MCR-modulen RLR alls och CC endast delvis. TACK!

[Tekko]

Minnena av ozoned from gnistrandet i motorerna och rälsen, samt värmen från motrlindningarna väcks till liv när jag ser detta.

[MadModder]

Mmmm, jag körde mycket med pappas gamla bilbana som han fick när han var liten. Det var de här tunga cigarrformade bilarna. Jäklar vad det luktade ozon efter ett race.

Intressant projekt det där.

[Lennart Aspenryd]

Mycket intressant utveckling. Det behövs ett nytt synsätt och nya tankar kring BilBaneRacing för att kunna visa upp dess hela potential!
Bra jobbat Erik M.

Om man tittar på MCR 64 kan du alltså adressera och ge kommandon till 32 plus 32 enheter när det gäller Motorpådrag och Växling!
Hur matchas enheter tillsammans med MCR eQ enheten och kortet i bilen? Eller var det MCR 64 någonting som gjorde detta.
Hur ser enheterna ut för att bromsa bilen respektive känna av tailsving? Låter som en bra lösning.

Kommer detta att vara en slags Open Source lösning! Jag tror många här på Sef är intresserade av hur man anropar, knyter Id och ger signaler till 64 enheter.

Vilket chip använder du för detta och kringkretsar för effekt!

[Erik M]

Just nu använder jag PIC12F683 till CC och eQ, PIC12F615 till RLR.

Jo, det är riktigt, 683'an har endast en PWM.
Och jo, jag styr både broms och fart med den.
Utan att för den skull växla direkt mellan dem.
Läget fart/broms används inte, endast fart/rulla respektive broms/rulla.
Fördelen är oxå att även om koden får hicka kan n-FET och p-FET aldrig vara påslagna samtidigt.
En uppenbar risk vid olika PWM I/O, hur bra och säker man än är.
(Ja alltså då givetvis såsom läget är här, där de är kopplade för sina uppgifter som de är.)

Till Scalextric används PIC16F630 till både bilar och växlar, så där använder jag dem, dvs skriver om koden på befintliga enheter (vilket naturligvis är vanskligt - men motsvarigheten till originalkoden finns kvar, som ett av alternativen).

Med tanke på att ingen kod än så länge sträcker sig till mer än femtio instruktioner är det ingen ko på isen vad gäller Open Source.

Kraft till banan till den mängden bilar är ett relativt litet problem.
Och var och en som tänker sig den mängden bör lägga försörjning till växlar etc på separat aggregat.

Det stora problemet torde bli att hitta lämpligt kraftaggregat som ska skicka in kraft till systemet.
Dvs att slå på och av spänning och ampere ut till bilarna och signalerna till dem på banan finns det n-FET att tillgå.N-FET med så liten Rds(on) att inte ens detta antal parallellkopplade motorer, speciellt inte då PWM'en dessutom sprider ut behovet, torde ställa till det.

Men givetvis - om man tänker sig sextifyra parallellkopplade motorer, som var och en drar 300mA, då är det klart även en Rds(on) på åtta mΩ får jobba...

[Lennart Aspenryd]

Tack för svar Erik M. Rätt påpekat så bör all strömförsörjning till växlarna ske separat!
Faktiskt bör även den fasta strömmen till olika delar av banan vara separat,
man borde kunna laborera med olika utmatningar, allt mellan 9 V till 16 V.
Men hur skickar du kommunikation till de adresserbara anheterna?

[Erik M]

Att leverera kraft till olika delar av banan från olika aggregat skulle ställa till det mer än det skulle lösa.
Främst med tanke på att bilarna tenderar köra i klump, dvs belasta samma aggregat.

Att leverera olika spänning till olika delar skulle betyda att samma läge på handtaget skulle ge olika hastighet på olika delar av banan. En oönskad komplikation - det är besvärligt nog som det är hålla bilen i spår, när man kör med folk som vet att köra
Att isolera de olika delarna, elektriskt, från varandra skulle oxå medföra olämpligt merarbete - ingrepp i bandelarna i sig.

Kommunikationen sker med hjälp av signal liknande Manchester.

[Erik M]

Men det finns en annan väg, kanske, att använda fler, men individuellt svagare, kraftaggregat.

Genom att sprida ut vardera PSU's tillfälle användas skulle man kunna begränsa antal laster per PSU.

Enklast, och billigast, är antagligen att helt simpelt parallellkoppla tillräckligt många - men styrda av varsin MOSFET, för att isolera dem från varandra.

[Erik M]

Nå och i alla fall...

Första delen är nu verkligen klar, den del som gjorde det väldigt nödvändigt gå den digitala vägen - MCR SSD RaceLine.

[MadModder]

Det är ju för jäkligt att videor ska anmälas för olaga distribution av musik fortare än kvickt!
Larvigt säger jag. Och anmält av upphovsrättsinnehavaren själv? Jag undrar det jag...

I vart fall, det ser förjäkla kul ut när de kör om varandra sådär helt automagiskt. Bra jobbat.

[Erik M]

Tackar!

Jo, jag blev lite förvånad, speciellt som det bara var bakgrundsbrus...

Lite automagiskt är det onekligen - men mest att föra samman analogt och digitalt.
Det är du, din bil och ditt handtag, precis som det ska vara.
RaceLine håller sedan reda på om du kommer ikapp och ska försöka köra om, eller inte.

[Erik M]

Jag har nu protesterat mot det hela, det är bakgrundsljud, inte musik.
Och det måste vara en person som gör anmälan, den kan inte göras via automation.

Så imorgon har jag väl inget youtube-konto...

Alltihop är lite fånigt.
När jag gjorde den första DASC-videon så använde jag aktivt Personal Jesus, och fick endast en anmodan om att medge att så var fallet. Rätt sätt använda copyright.

[hanzibal]

När jag var liten (och körde med ozonalstrande cigarrer) så brukade jag låsa ena fartgrglagets avtryckare med hushållstejp.

[Erik M]

Jag med.

Men med DASC-modulen får du en bil som kör maximalt - utan att vara annorlunda från den du själv kör och försöker komma ikapp den med.

[Erik M]

Så, nu är modulen RaceLine Racing för Scalextric's SSD färdig.

Det som tagit mest tid har varit att finna ett käckt sätt mäta bilarnas hastighet.
En hastighet som sedan används till att beräkna de olika tidsintervall som är inblandade.

Till slut fick jag ihop det som redan från början ansågs vara vad som vore vettigast.
Dvs att mäta från start av första blink från IR-dioden, som dels indikerar bilens ID och dels indikerar om bilen önskar byta spår, tills slutet på sista blink innan bilen lämnar sensorn.
Längden över sensorn är 17mm vilket vid någorlunda hastighet ger en passagetid på sisådär 4ms. Tillräckligt för att överbrygga de väldigt olika ID-profilerna och ge ett användbart tidsintervall.

Just nu används två sensorer per spår, en för anti-kollision och en för raceline, och en helt ny styrkrets, skild från SSD's.
Men då tidsintervallet nu är så väl definierat, och signalen för växling lätt tillgänglig, månne det vara värt gå tillbaka och utnyttja den ursprungliga kretsen.
Då den hursomhelst måste flyttas, och alla ledningar förlängas, blir det enklare ta loss den och skicka iväg den för uppgradering.
Speciellt som den ursprungliga funktionen kommer finnas kvar - om än förbättrad.
Dvs möjlighet välja hur mycket bättre upplevelse man vill ha; endast förbättrad funktion, iallafall anti-kollisionen eller fulla RaceLine Racing.