Kan någon bygga en Segway?

[bearing]

Nej, som jag förstår det är det en mer sofistikerad metod. Såg du videon där han talade om integrering av insignalen och fördelen med det när varvtalet ändras snabbt?
Problemet med vanlig sensorlös styrning är att man bara kikar på när signalen passerar nollgenomgången, och sedan gissar när motorn ska kommuteras. Gissningen blir fel ifall motorns varvtal ändras abrupt. Med InstaSPIN blir kommutering rätt oavsett varvtal och acceleration.

LHelge, du som läst mycket på endless-sphere, har du sett ifall någon använder (analoga) hallgivare för att mäta positionen, eller är det bara halleffektswitchar som används? Med hallgivare borde det vara möjligt att bestämma positionen med högre upplösning, tycker jag.

[Andax]

Melexis har något som de kallar TruSense som kombinerar BEMF och reluctance-mätning (dvs de mäter hur induktansen i lindningen beror på rotorns läge i förhållande till statorn) utan att använda hall-sensorer. Vet inte hur bra det funkar dock...

http://www.melexis.com/Brushless-DC-Mot ... 0-688.aspx

[ristomemo]

Jag la till en sektion på wikisidan angående belysning (framåt och bakåt) och anmäler mig som frivillig till att ta tag i den biten!

Haha, ok då kan vi nog räkna med rejält med ljus.

Vill man komplicera det hela så ska ljuset naturligtvis stabiliseras (rc-servo) så eventuella styr-rörelser inte ger en ljuskägla både högt och lågt.

Vill inte låta för pessimistisk, men. Sådant som belysning och framförallt stabiliserat belysning måste väll ses som lull-lull. Som en option för de som önskar. Samma sak med inbyggd GPS. Trevligt, men fördyrande och förlänger utvecklingsprocessen. Men sker den utvecklingen på sidan av så är det ju en annan sak, men den utrustningen bör ses som en option som enbart några kommer att välja.

[LHelge]

Nej, jag har aldrig sett någon använda analoga hallgivare, men det finns bara ett fåtal projekt där med folk som bygger en egen motorstyrning. De flesta där använder färdiga (eller modifierade) kinacontrollers och de har bara stöd för latchade digitala hallgivare. Det går garanterat få bättre upplösning men jag vet inte om det behövs i vårt fall. Har man en motor med drygt 25 poler och 6 hall-steg per kommutering så har man nästan 2 graders upplösning, vilket borde vara mer än nog. Extremfallet är Nine Continent 1606-motorn som har 57 eller 58 poler om jag inte minns fel.

Vad gäller sensorlös styrning: Det spelar ingen roll om man enbart tittar på nollgenomgångar eller kontinuerligt övervakar back-EMF, man kommer inte ifrån att man måste upp i varvtal innan det finns någon mätbar back-emf. Att istället titta på induktansen i spolarna borde fungera men låter som något man gör för att spara 20:- per enhet när man gör miljonserier av en produkt.

Med 3 st vanliga latchade digitala hall givare exempelvis elfas 73-490-46 som är populära i elcykelsammanhang. Kan man bygga en motorstyrning med ett par 74* logikkretsar och 6 MOSFET om man vill.

[blueint]

Vill inte låta för pessimistisk, men. Sådant som belysning och framförallt stabiliserat belysning måste väll ses som lull-lull. Som en option för de som önskar. Samma sak med inbyggd GPS. Trevligt, men fördyrande och förlänger utvecklingsprocessen. Men sker den utvecklingen på sidan av så är det ju en annan sak, men den utrustningen bör ses som en option som enbart några kommer att välja.

Belysning kan vara ett lagkrav..
Utrymme för fästen kan vara bra.

GPS bör vara en option, dvs en ledig UART port tack
Och framförallt API:er som ger möjlighet att lägga in extra funktionalitet utan att behöva konstruera om allt. Man kan t.om lämna paddar på kretskort så att man kan löda dit GPS mottagare osv.

Planering helt enkelt.

[Pajn]

Lyse är troligtvis ett lagkrav. Den klassas ju som cykel och en cykel måste ju ha lyse när det är mörkt.
Däremot borde det vara en option att stabilisera lyset.

EDIT:
Fast det är det ju alltid iof. bara för att det finns utgång för servo måste man ju inte koppla in ett. Lampan kommer ju lysa lika bra ändå.

[Gimbal]

Fast sådant lullul som belysning och GPS behöver väl knappast in i huvudstyrdatorn alls?

Den kritiska delen (balansering och styrning) bör vara så isolerad från lullul som möjligt, vill ju inte stå på huvudet för att GPS'n dog och drog med sig balanseringen.

[Meduza]

Nej frågan är om vi inte ska separera det ändå till två kort, ett kort som gör "skitgörat" av att hantera stabilisering, motorkontroll osv och ett för "tillbehör", alternativt använda ett mer kraftfullt kort till styrets display och låta detta hantera "runt-tillbehör" som belysning, gps osv.

Det viktiga är iaf att om "tillbehörskortet" packar ihop så ska detta inte påverka "huvudkortet" alls, dvs man ska inte göra ett dyk med ansikte mot asfalt om gpsen tappar signal eller något dylikt

Jag hade en liten fundering på att ersätta displayen i handtaget med en hållare för en android-telefon och en app för att kontrollera inställningar osv via bluetooth...

[LHelge]

Jag tycker det är bra idé att styrets kort hanterar allt som inte är livsviktigt. Huvudkortet kan ju vidarebefordra vinkelinfo om det är intressant. Jag tycker blåtand och Android kan vara en bonus, men ett snyggt integrerat displaykort a la Fagge:
http://elektronikforumet.com/forum/view ... &start=388
är ett måste.

[Pajn]

Jo att sepparara viktiga funktioner med "THE LULZ" är nog bra.

Korten skulle kunna kommunicera med UART, det är billigt och enkelt. Informationen som går där (vinkelinfo endast?) är inte livsviktig.

[LHelge]

Om du tittar på min senaste ändring i wikin så föreslås uart där. Det viktigaste som jag ser det är:
* Hastighet
* Momentan Strömförbrukning
* Batterispänning
* State of Charge.
* Ladding?
* Vinkel till den adaptiva framlyktan

Behöver inte uppdateras mer än 1-2 Hz skulle jag tro.

[Pajn]

Kollade i wikin. Troligtvis behöver vi inte en ARM om vi nu bara håller krav de viktiga funktionerna på huvudkortet.
Fast kostnadsmässigt och tidsmässigt kanske det inte är så mycket värre än en enkel µC?

EDIT: ARM prollen gör nog bättre nytta i tillbehörskortet.

[LHelge]

Största problemet med en ARM är väl at det inte är lika många här som är vana att använda dem som t ex PIC eller AVR. Jag är en av dem men jag lär mig gärna.

Annars ser jag ingen anledning att snåla på processor. Lika bra att ha något att växa i.

Edit: Ska vi använda kalmanfilter behövs lite beräkningskraft också.

[blueint]

Föreslår att dom interna korten kommunicerar via något multidrop asynkront protokoll. Så slipper man slösa UART portar på det. Iaf för sådant som skärm mm.

Och om man använder en AVR/PIC istället för ARM så sparar man säkert ungefär 30 kronor

[LHelge]

Fram till dess att man inser att processorn är för liten och man får göra om hela kortet.

Finns det risk att UART portarna tar slut på en medel-ARM? Jag tänkte att det var allra enklast när hårdvarustödet redan finns.