Castle Creations ICE HV 80 vs Spin 99

Er zijn twee verschillende oplossingen:
1. Door PID in de regelaar en het kunnen beinvloeden van het schakelmoment. Hiervoor moet je regelaar hardware ter beschikking hebben en dit kunnen programmeren. Is heel veel werk en dat zie ik niet zitten.

2. Door een "black box" tussen Rx en ESC, met BEC de voeding uit de ESC, met opto uit de Rx. Meer is niet nodig. Voordeel is dat je met de remfunctie van de regelaar tussen soft en hard de warmte ontwikkeling kunt beinvloeden.

Meet Rx
Meet Hall passage 1/14 omwenteling
Bepaal welk signaal je naar de ESC wenst te sturen, deze logica kun je vrij kiezen. met PID of alleen een grenswaarde.
Stuur dit signaal uit

Interrupts vinden plaats op het moment van optreden en kosten vrijwel geen processor capaciteit, sampling op basis van polling kost veel resources.

Het Rx samplen heb ik hier beschreven, werkt op alle Atmel, dus ook Arduino dit zorgt er voor dat de Rx waarde altijd beschikbaar is. http://forum.pololu.com/viewtopic.php?f=2&t=2457

Je kunt dan in de main loop wachten tot de Hall voorbij komt en dan de PID berekening uitvoeren. Dit mag ook in een Hall interrupt, kwestie van smaak.

Hier moet je dan wel een beveiliging voor minimum en maximum waarde aan toevoegen, die PID kan namelijk uit je bereik lopen.

Om die pwm aan je ESC aan te bieden kun je het beste native pwm (timer1 OCR1A) toepassen, deze is dubbel gebufferd zodat je geen last kunt krijgen met de interrupts.

 

Dit is dus exact het riedeltje wat ik ook schreef.

Dat hangt er dus vanaf, welke functionaliteit de CPU in kwestie aan boord heeft. Het PICje wat ik gebruikte, had een poort die PWM uitlas en de pulsbreedte gaf. Dat kost dus geen resources, kun je gewoon á la minute uitlezen als je dat wil.

Verder is het verhaal helder en duidelijk. Qua code ook behoorlijk eenvoudig, het is geen rocket-science. Daarom blijf ik het raar vinden dat het nog niet door fabrikanten geimplementeerd is. Ik vrees dan toch dat je motor het niet gaat trekken, ofzo.

 

Techniek is ondergeschikt aan wat je wilt regelen, je kunt met verschillende middelen hetzelfde bereiken. Mijn voorkeur gaat uit naar de Baby-O boardjes, die ken ik inmiddels een beetje en heb ik in voorraad.

Meten is weten, door niet alleen de juiste instelling te zoeken maar ook te meten wat de bandbreedte is van je oplossing kom je te weten of je tegen een kritische grens van je setup aanloopt.

Ik zou voor F3A eerst een vlucht maken in governor LOW met een ampere, accellerometer en rpm logging, als in de downleg het vermogen er af gaat en de toeren niet toenemen en de kist blijft versnellen dan is extra remmen op de motor niet zinvol, hoef je dan niet te vrezen. In dat geval moet je de diameter van de propellor vergroten om meer remkracht te creeren.

Lopen de toeren op dan is de governor niet sterk genoeg en moet je bijremmen. Dan is het zinvol om deze schakeling te bouwen. Ik zou dan een temperatuur sensor toevoegen om te achterhalen hoeveel remvermogen je kunt toevoegen zonder dat de boel te heet wordt.

Ik heb in eerdere projecten als eens een Rx input, Hall input en PID toegepast en ga dit zeker in elkaar zetten. Variant a als pulserend reminstrument zodra de toeren boven de Rx waarde uitkomt en versie b waarbij ik de governor functie zelf aanstuur op een regelaar in flight modus.

 

De ene regelaar is de andere niet. Ik heb twee test situaties bekeken.
a. Een spool-up en spool-down, de mate waarin de toeren wijzigen als we in een keer de input puls vergroten of verkleinen. De Kontronik Jazz55 reageert op een geprogrammeerde snelheid en veel te langzaam, wellicht goed om de tandwielen in een helicopter heel te houden maar niet voor proplellor doeleinden.


De Castle Creations reageert veel sneller


b. Een tweede test waarbij de motor in governor plotseling te maken krijgt met een toename van de belasting die even later weer weggehaald wordt. De belasting wisselt tussen 350 en 700 Watt.

De kontronik zakt door het ijs onder belasting de toeren zakken direct in.


Je ziet dat de Castle Creations beter in staat is om de toeren stabiel te houden.

 

Interessant.. alleen ben ik recentelijk gewezen op een ander mogelijk probleem voor de CC, namelijk dat het ding z'n timing kwijtraakt als de rem 'engaged' is, en dan bij een transitie van een remmende situatie naar een aangedreven situatie, een forse koppelklap kan geven, eventueel met een piepend bijgeluid.

Dat zou het idee om dynamisch te remmen (dus afwisselend throttle/rem signaal afgeven) behoorlijk kunnen torpederen.

Castle ESC screaching during brake-to-throttle transition

Uit het verhaal van 'de CC man' maak ik wel op dat dat alleen geldt als de prop stil is komen te staan, of een lage snelheid heeft. Dan zou het dus op te lossen zijn door het dynamische remmen uit te zetten voor toerentallen onder de 1000, oid.

 

Een borstelloze motor start niet zomaar, daar zit een opstart cyclus aan vast, het zou best kunnen dat deze opstart cyclus (vast patroon) ruzie krijgt met een motor die vanzelf wil gaan draaien en te vroeg bij de volgende spoel aankomt. Dat geeft een rotklap.

Komt trouwens goed uit die lage toeren. Bij 16 bit kom ik rond de 1300 toeren aan de limiet van 65535, dus eigenlijk best wel een goed idee om het onder deze grens niet te laten remmen.

Ik heb de software gereed, via een polling mechanisme vang ik de pwm in af, doe dan een vergelijking met de gewenste waarde en stuur het dan via native pwm er weer uit. Deze laatste is dubbel gebuffered zodat ik niet bang hoef te zijn dat de uitgaande puls last heeft van de ingaande interrupt.

De Hall sensor geeft bij elke magneet passage in een interrupt routine een tijdstip door.

Een overflow counter geeft aan hoe het rekensommetje van de gepasseerde tijd moet lopen.

Heb nog geen tijd gevonden om dit on de praktijk te testen, moet dan eerst de motor en regelaar uit de kist halen.

 

Vandaag hen ik deze regelaar eens met wat sterkere rem gebruikt (60%), maar dan krijg ik zodra ik weer gas geef aan het einde van een neergaande lijn een verschrikkelijk snerp geluid.
Het lijkt wel of hij dan niet meer synchroon loopt.
Bij terugkomst bleek ook de prop los te zitten. Vastgezet en nogmaals proberen, maar geluid bleef.

Enig idee wat dit is?

Nu heb ik hem weer op 50% staan, maar ik wou eens testen wat de verschillen zijn.

 

Een fout in de regelaar. Bij transitie uit de rem naar een aangedreven situatie, gaat hij gillen. Is een bekend probleem. Vooralsnog ben ik de enige die het probleem niet heeft, mijn rem staat nu op 80%.

Het advies van CC is je rem reduceren tot max 30%. Ik neem aan dat er een software update voor gaat komen. Het schijnt ook dat er oudere versies (software) zijn die dit probleem niet hebben.

Castle ESC screaching during brake-to-throttle transition

Het zou kunnen dat ik dit probleem niet heb, omdat ik op 8s vlieg, met een hoger toerental en een kleinere prop.

Sowieso is het verstandig om op een electroaandrijving met rem een dubbele propmoer te gebruiken.

 

Bedankt Henri.

Nu zie ik software updates doorkomen en met name beta versies. Wat is de ervaring met deze beta-versies? Normaal sla ik betas meestal over tenzij er een zwaarwegende factor is. Maar dat betreft dan normale computer software.
Hoe is die ervaring met CC?

Trouwens, een dubbele moer op een plettenberg xtra gaat volgens mij niet echt werken.

 

Ik weet niet hoe de beta's allemaal bevallen, ik heb de laatste beta erop staan en die werkt voor mij prima.. verder geen ervaring met de beta's van hyperion.

 

De afgelopen 5 jaar heb ik elke beta van Castle Creations direct geinstalleerd en gebruikt. Tot op heden geen problemen gehad al doe ik het niet vlak voor een wedstrijd als ik niet meer kan vliegen.

Ik gebruik alleen de governor functie en heb geen ervaring met de overige instellingen

 

Mijn CC is afgelopend weekend in de lucht doorgefikt. Van het ene moment op het andere geen respons meer op gas, niets. Geen rooksporen, vlammen oid, maar gewoon een motor die niets meer deed.

Geland, en toen ik de kist openmaakte rook ik wel het typische luchtje van doorgebrande electronica. De regelaar was zelf niet warm en ik heb er ook al veel vluchten mee gemaakt bij warmer weer, het is geen overbelasting geweest.

Mijn vermoeden.. ik vloog met een ouder zippy pack wat een hogere Ir heeft dan het hyperion pack waar ik meestal mee vlieg. CC heeft in het verleden issues gehad met packs met hogere Ir, google maar eens op 'Castle Creations Ripple Current'.

Wat er in die situaties gebeurd, is dat de condensatoren het begeven. En als die eenmaal kapot zijn, is de rest van de regelaar ook snel kapot, het is net Bassie en Adriaan, als je de ene ziet, komt de ander er aan.

Dit strookt ook met het feit dat de regelaar bij aansluiten nu helemaal niets meer doet, ook niet vonken.

Ik heb deze regelaar bij Aerobertics gekocht en zijn service kan ik alleen maar goed noemen. De regelaar is opgestuurd en wordt gerepareerd of ik krijg een nieuwe.

 

Over de kwaliteit van de software-updates van Castle Creations heb ik toch wel m'n bedenkingen. Aan de kwaliteitscontrole lijkt toch wel iets te mankeren.
Sinds ruim een half jaar gebruik ik een Castle Creation Ice Lite, maar met de updates maak je toch wel wat mee.

Zo verscheen de nieuwe Castle Link 3.30. Die liet zich niet installeren onder Windows XP of Windows 7. En niet alleen bij mij. Het Internet stond "bol" van de gebruikersreacties. Twee dagen late verschijnt versie 3.30.1, die weer snel wordt opgevolgd door 3.30.3. Op dit moment zijn we toe aan versie 3.40.

Iets vergelijkbaard met de software voor de Phoenix Ice. Op 21 december 2010 verschijnt versie 3.25. De volgende dag opgevolgd door 3.26 wegens een ernstige fout in de governor. Inmiddels gebruiken we versie 3.27.

Natuurlijk, software is ingewikkeld. Foutloze software bestaat niet en corrigeren van fouten levert weer nieuwe fouten op. Maar als updates zich na enkele dagen opvolgen, dan kan je vraagtekens plaatsen bij het testen hiervan.

Ben wat voorzichtiger geworden. Als er nieuwe software verschijnt dan wacht ik nog even af. Kijk of er reacties zijn e.d. voor ik tot installatie over ga.

 

Dat is idd niet netjes van ze, maar wel een bekend feit.. als je wil dat spullen waar software staat altijd goed werken, installeer je updates het best niet meteen als ze uitkomen, maar als je wat andere gebruikers er (goede) ervaringen mee hoort hebben.

Aan de andere kant hebben ze wel een update-mechanisme voor hun regelaars. Een spin koop je met een bepaalde software versie, en daar moet je het mee doen. Of opsturen.

 

Tja, ook ik heb de ervaring en mening dat je niet altijd met alle updates moet meelopen. Maar dat geldt ook voor andere software van gewone computer applicaties!
Daarnaast ben ik ook van mening dat als iets goed loopt en aan je verwachtingen voldoet, waarom dan updaten? Goed doornemen wat de veranderingen zijn en dan bepalen of je het echt nodig hebt en dan ook nog eens niet gelijk na uitkomst.
Volgens mij is het ook nog eens zo dat CC vaak Betas uitbrengt en dat is in ieder geval voor eigen risico...... Het zegt het al, het is een test versie.

Net wat mijn voorganger zegt, ik ben blij dat de CC te updaten is. Wellicht niet altijd nodig, maar het bespaart kosten als het wel moet.

 

Nietsvermoedend de laatste versie van Castle link en regelaar binnengehaald en geinstalleerd (op vista), zonder op te schrijven van welke oude versie ik af kwam.

Nu bleek de response curve aangepast te zijn en er bij de pwm naast 12 kHz nog een extra optie "outrunner mode" bijgekomen te zijn.

Mijn afstelling was volledig naar de maan, de throttle curve reageerde totaal anders zodat de motor de eerste vluchten veel te langzaam liep.

Als kers op de taart levert "outrunner mode" een besparing op van 10% op het verbruikte vermogen en dat was een aangename verrassing.

Ik ben van mening dat je bij software updates altijd mee moet maar dat het niet verstandig is dat de avond voor een wedstrijd uit te voeren.