OpenRC4CL (DIY LB met RC functies)


Hier kun je de nodige inspiratie opdoen voor een handvat.
 
De ESP32 heeft een ADC resolutie van 4096, bij gebruik van een deel van je bereik hou je genoeg over.

De gevoeligheid bij throttle down kun je beinvloeden door het getal wat uit de ADC komt wiskundig te manipuleren. Dat doet de ESP32 best vlotjes. Ik heb zelf software gemaakt die 3 stuks ADC uitleest met een rollend gemiddelde over 64 metingen maakt, de center positie calibreert, de maximale uitslag in plus en min toepast en dan mapped naar min-max waarde van 1000 of 2000 en trim functie op Rudder en Elevator. Dual Rate en Expo moet ik nog toevoegen. Met berichtenverkeer zit ik nu op 7ms cyclustijd.

Het berichtenverkeer staat op de langzaamste stand omdat ik het maximale bereik nastreef. •The ESP-NOW mode offers a connectionless and encrypted alternative to traditional WiFi. While the data rate is reduced to ~250 kbit/s the range is increased up to 1 km. Ik haal nu 700m op grond niveau met antenne.

Voor het terugkoppelen van de getallen had ik eerst een I2C 16x2 LCD maar die was erg traag en had 68 milliseconden nodig. Onlangs een piepklein TFT display aangeschaft en die is veel sneller, ik kan nu de getallen in 8ms publiceren. (getalletje in geel)

Bekijk bijlage 651254
Ik moet de boel nog samenvoegen maar de cyclustijd komt nu in de buurt van de 15ms wat overeenkomt met de Futaba T-FHSS.

Voor de gasregeling zou ik een potmeter en schakelaar toepassen waarbij je de low throttle met je duim kunt bedienen, volgas dan met je andere hand. De schakelaar op stationair of uit, een regelaar is veel fijner te beinvloeden als de prop een beetje draait, als het gas helemaal uit gaat dan duurt dat even en lig je al in de plomp voordat je model weer stijgt.

Wat alleen hindert is dat de pin nummers gemixed worden, De ADC volgt GPIO en de Tx niet en in plaats daarvan het nummer op het boardje. Slordig en iets wat gaat omvallen met de volgende update.
Bedankt voor je reactie en tips.

Je hebt gelijk, de ADC heeft een resolutie van 4096, dus als ik daar een ca kwart (90 graden vs 300 graden) houd ik meer dan 1000 eenheden over. De Tx stuurt zijn 'servo commandos' over in de range 1000-2000 us, dus 1000 eenheden is voldoende.

Ik zal ook eens naar die nieuwe ESP-NOW long range mode kijken. In de huidige opstelling is het bereik ruim 50m en wordt de cyclustijd gelimiteerd op 20ms. Testen van enige tijd gelden suggereerde dat 1-2ms mogelijk is, alleen wordt het stroom verbruik dan een stuk hoger. 50Hz is voor LB denk ik voldoende.

Ik heb ook nagedacht over een TFT scherm, maar om zo min mogelijk componenten te gebruiken (licht en laag stroomverbruik) gebruik ik voor logging BLESerial, hiermee zend ik alles wat normaal gelogd of verzonden wordt naar Serial (de standard terminal) ook over Blue Tooth Light weg naar een Serial Bluetooth Terminal App op mijn mobiel of laptop. Via een text menu kan ik dan bv ook instellingen wijzigen.
 

Hier kun je de nodige inspiratie opdoen voor een handvat.
Bedankt voor de inspiratie.
In de volgende fase wil ik de PCB nog wat verkleinen en kijken of ik alles, inclusief accu, in zo'n handvat kan 'proppen'.
 
In het handvat van Henk (bij mijn weten het eerste in zijn soort) hebben we een schuifpot gebruikt met een elastiekje.( begin van het seizoen even een nieuw er op en je hebt er geen omkijken meer naar).
Doordat ik in de na de AD omzetting nog een expo bewerking toepas, kun je met één pot af.
Hoe langzamer, hoe fijner de regeling....
 
In de volgende fase wil ik de PCB nog wat verkleinen en kijken of ik alles, inclusief accu, in zo'n handvat kan 'proppen'.
De eerste (1 kanaals) versie:
Handvat met nieuwe controller 2.jpg
Een soort van luxe servotester, met expofunctie....
Alleen een aan/uit schakelaar en aan de andere kant (slecht zichtbaar) de schuifpot.
Onder een lusje van klittenband dat de 9 V batterij op zijn plaats houdt.
Voeding is 9V naar Vraw van de Arduino die er zelf 5 V van maakt, ook gebruikt voor de pot.
Dit handvat is inmiddels omgebouwd naar een cppm generator met pot en schakelaar (vanghaak) functies.
In het model zit dan nog een decoder die ESC en vanghaakservo aan stuurt.
 
Laatst bewerkt:
Weliswaar een beetje "off topic", maar hier mijn proefopstelling om de "Climb and Dive" timer te programmeren.

Het blijkt nu dat de timer 3 pins heeft voor het aansluiten van een 'Neo Pixel LED', dit zegt mij helemaal niets maar het is een LED met 4 draden waarvan er 3 worden aangesloten.

Is deze LED iets bijzonders?

Overigens de capacitieve schakelaar, een smal stukje Latoenkoper werkt prima.

Harry
IMG_20260517_113002~2.jpg
 
Weliswaar een beetje "off topic", maar hier mijn proefopstelling om de "Climb and Dive" timer te programmeren.

Het blijkt nu dat de timer 3 pins heeft voor het aansluiten van een 'Neo Pixel LED', dit zegt mij helemaal niets maar het is een LED met 4 draden waarvan er 3 worden aangesloten.

Is deze LED iets bijzonders?

Overigens de capacitieve schakelaar, een smal stukje Latoenkoper werkt prima.

Harry Bekijk bijlage 651558

Ik heb nog geen Neo Pixel leds gebruikt, maar volgens mij zijn dat 'intelligente' leds waar je commando's (daarom 3 draaden) naar toe kunt sturen, zoals kleur, helderheid etc. De 4e draad wordt gebruikt om het commando naar de volgende neo led in bv een ledstrip aan te sturen.
 
Lijkt niet op neopixel, staat dat in de documentatie?

Een LED met 4 draden is meestal een RGB, als er maar drie draden gebruikt worden dan heb je maar twee kleuren.
 
Staat inderdaad in de documentatie onder 'Advanced Modifications'.
Niet dat ik nu direct een LED nodig heb, maar handig is het wel.

Bij de eerste versies moest je de LED nog op de print solderen maar ik zie nu 3 pins.
 
Voor het loggen in het model laat ik een Sparkfun Openlog meevliegen die met 100Hz alle benodigde data wegschrijft. Tijdens een vlucht heb je geen tijd voor de analyse en omdat geluid langzamer gaat dan licht hoor met enige vertraging wat je ziet, dat kan erg verwarrend zijn.

Je kunt goed zien welke sensor waarden er gehaald worden en het gedrag van de sensor in de figuren, dat is de input waarop je de correcties kunt baseren.

Kleiner maken lijkt me een goed plan, ik het een brooddoos nodig voor een 3 kanaals zender op basis van een C3 boardje. Die heeft maar 3 analoge inputs. Voor de batterij spanning gebruik ik een klassieke robbe spanningsbewaking. De Rx en Externe accu in het model worden wel echt gemeten.

Met de TFT die alleen gebruikt wordt als er wat te melden is kom ik tot 10ms cyclustijd. De processor is 73% gevuld, er past niet heel veel meer bij.
 

Bijlagen

  • 20260518_123843.jpg
    20260518_123843.jpg
    156,1 KB · Weergaven: 20
  • 20260518_115611.jpg
    20260518_115611.jpg
    124,2 KB · Weergaven: 21
Voor het loggen in het model laat ik een Sparkfun Openlog meevliegen die met 100Hz alle benodigde data wegschrijft. Tijdens een vlucht heb je geen tijd voor de analyse en omdat geluid langzamer gaat dan licht hoor met enige vertraging wat je ziet, dat kan erg verwarrend zijn.

Je kunt goed zien welke sensor waarden er gehaald worden en het gedrag van de sensor in de figuren, dat is de input waarop je de correcties kunt baseren.

Kleiner maken lijkt me een goed plan, ik het een brooddoos nodig voor een 3 kanaals zender op basis van een C3 boardje. Die heeft maar 3 analoge inputs. Voor de batterij spanning gebruik ik een klassieke robbe spanningsbewaking. De Rx en Externe accu in het model worden wel echt gemeten.

Met de TFT die alleen gebruikt wordt als er wat te melden is kom ik tot 10ms cyclustijd. De processor is 73% gevuld, er past niet heel veel meer bij.
Leuk project!
 
Gisteren avond een duurtest uitgevoerd op de Tx op lage snelheid met maximaal vermogen. Geen wijzigende input van de sticks dus, dan slaat mijn programma de TFT over omdat er niks nieuws te melden is en daalt de cyclustijd naar 6ms. Dus de zender moest goed aan de bak. Met een 4,8V NiMH pack van 800 mAh van Varta als voeding. De Rx van een grotere eneloop en 3 servo's voorzien zodat ik een eventuele failsafe niet zou missen. Na 3,5 uur was het einde van de Tx batterij, de Robbe spanningsbewaking liet een rode led zien en heb ik de test gestopt. Er ging 685 mAh in volgens de lader. Voor LB ruim voldoende omdat je per vlucht maar 6 minuten stroom nodig hebt. Voor een week-endje hellingvliegen aan de krappe kant.
 
Dat is de helft van mijn verbruik maar laat zich wel verklaren, de orde van grootte klinkt acceptabel. Voor deze test herhaal ik de cyclus zo snel als het gaat en stuur ik vaker een bericht uit. Daarnaast staat er nog een 240x240 TFT scherm aan wat ook stroom verbruikt. Ik wil nog een schakelaar programmeren die het display op zwart zet tenzij er een alarm van toepassing is.

Het voelt allemaal robuust genoeg om te gebruiken, de servo's staan mooi stil, geen jitter, geen knakjes zoals je dat hoort op een UNO en klaar voor een echte test. Ik begin met een bootje en een 30m touwtje en laat dan een helper meelopen langs de vaart totdat de failsafe ingrijpt en het touwtje nodig is.

Voor LB verwacht ik dat het goed gaat werken, de enige onzekerheid is nog het gedrag bij meerdere zenders op hetzelfde terrein en/of meerdere modellen per zender. Dat ESP-NOW werkt op basis van MAC-adress helpt al, als extra heb ik nog een pincode in het bericht gezet. Een LBT functie heb ik niet voorzien.

Klopt het dat je de LR functie nog niet gebruikt?

in setup heb ik:
esp_wifi_set_protocol( WIFI_IF_STA , WIFI_PROTOCOL_LR); // std range should be 220m uncomment this line extends the range to 1km, do not forget to add this line to the Rx too
 
Ik gebruik het long range protocol (nog) niet. Uit veldtesten blijkt dat het signaal tot zeker 50m heel stabiel is. Genoeg voor LB dus.

Op basis van het onderstaande verwacht ik niet dat er snel storing zal optreden bij meerdere gebruikers tegelijk:
- EPS-NOW is juist gebouwd om in een netwerk met veel nodes te werken.
- Indien ik me goed herrinner kan er op deze wijze pakketen tussen Tx en Rx verstuurd worden op ca 1000Hz. Ik zit nu op 50Hz. De hoeveelheid data die verstuurd wordt per pakket is klein.
- De failsafe van OpenRC4CL staat op 0.5 seconde geen pakketen ontvangen. Uit logging, zowel tijdens het vliegen als op mijn buro, blijkt dat er gemiddeld minder 1 loss per minuut is. Dus bij 50 Hz heeft tot 24 opeenvolgende losses alleen tot gevolg dat bv de throttle response trager wordt, bij 25 of meer wordt de motor uitgezet. Dan moet de ontvanger eerste gerest worden voor er weer gevlogen kan worden.

Mochten er wel storing op treden, omdat het gebruikte wifi kanaal door anderen (kunnen ook PC's pf mobiels zijn die aan het streamen zijn), dan kan ik via mijn mobiel van wifi kanaal wissellen op de Tx en Rx.

Om verstoorde data te kunnen herkennen wordt in OpenRC4CL een oplopend sequence nummer aan ieder pakket toegevoegd, dat de Rx kan gebruiken om te bepalen of er en hoeveel pakketen gemist zijn. Verder wordt aan ieder packet een checksum tegevoegd door een XOR uit te voeren over alle data. De Rx controleert deze checksum.

In dit kader is het mogelijk goed om te weten dat LineMaster gebruikers op wifi kanaal 1 zitten. Met hun ontwikkelaar heb ik afgesproken dat ik dat kanaal niet gebruik.

Mijn broncode, PCB file, etc staan als open source op https://github.com/JaapVanDeLoosdrecht/OpenRC4CL .
 
Wat een mooie spulletjes toch tegenwoordig, vroeger.... en dan gaan we niet eens zo heel ver terug in de tijd hadden we de beschikking over een Arduino 328P met analoge XYZ sensor. En omdat je in F2B de motor niet vanaf het handvat mag bedienen moet alles ingebakken zijn in de timer. In 2006 hadden we geen bluetooth en mobieltjes om e.e.a. in te stellen.

De eerste timer was professioneel gemaakt en goed genoeg om mee te nemen naar het WK van 2006.

Daarna sloeg het Arduino virus toe en gingen we van blink-led naar steeds mooiere oplossingen. De eerste actieve timer had een custom instelbox die draadje voor draadje in elkaar geknutselt was met parameters voor looptijd, versterking en alles wat we toen dachten dat nuttig was. Zoals WTHT, Walk To Handle Tijd, met 18 seconden aan de krappe kant, voor sommige piloten iets langer.

Om de inbouw te versimpelen gekozen voor de Flyduino NANO en om beter te weten wat er in de lucht gebeurt een Logomatic V2 data logger toegevoegd, later vervangen door een Sparkfun OpenLog. Voor instellen een I2C display toegevoegd.

De mogelijkheden zijn eindeloos, en met de huidige stand van de techniek zou je wellicht een andere insteek kiezen.
 

Bijlagen

  • a Oer timer.jpg
    a Oer timer.jpg
    21,7 KB · Weergaven: 18
  • aTimer.jpg
    aTimer.jpg
    126,5 KB · Weergaven: 16
  • Ellipse 110.JPG
    Ellipse 110.JPG
    196,4 KB · Weergaven: 20
@FB2: Leuk dat je deze historisch ontwikkeling deelt!

OpenRC4CL is mijn eerste 'Arduino' project.
Ik was verbaasd hoeveel rekenkracht, RAM-geheugen en Flash memory er in een ESP32-C6 zat en dan ook nog Wifi en Bluetooth. Dit alles voor 6 euro en ter grootte van iets meer dan een duimnagel met een gewicht van een paar gram.

Wil graag wat vaker naar (internationale) LB-events. Om ons kampeermiddel toch wat vrij te houden van diesel en wonderolie geuren wil ik dit jaar overschakelen op LB-elektro en alleen de op één dag te bereizen events nog diesel te vliegen. Dit jaar zal het vooral wat experimenteren zijn met OpenRC4CL en mijn eerste Carrier model. Verder wil ik enkele F2D modellen ombouwen tot elektro om weer wat meer en beter te leren vliegen. Voor volgend jaar wil ik dan een, niet te grootte, profiel stunter bouwen om het F2B programma te leren vliegen.

Je schrijft dat een actieve timer heb gemaakt. Indien ik het goed begrijp betekent 'actief' dat de vliegsnelheid constant gehouden wordt onafhankelijk van dalen/klimmen, wind mee/wind tegen.
Active control van de vliegsnelheid staat ook nog op mijn wensenlijstje om aan OpenRC4CL toe te voegen. Ik verwacht dat acceleratie sensoren en/of motor rpm monitor/control hiervoor nodig zijn. Maar ik heb nog niet goed een idee hoe dit moet.

Mocht jij kennis of ideeën hebben, die je wilt delen, hoe active control geïmplementeerd kan worden, dan hoor ik het graag.
 
Voor kunstvlucht probeer je de vliegsnelheid onder controle te houden, dus niet te langzaam en niet te snel. Een governor regelaar doet dat door het toerental constant te houden, verlies je snelheid dan gaat de propellor harder trekken en ga je te snel verliest de propellor trekkracht. Als het windstil is zet je de motor op 5.3 sec/ronden en de rest gaat vanzelf. Dus je timer hoeft alleen een vaste waarde naar de ESC te sturen voor maximaal 6 minuten want na 7 minuten moet het model weer stilstaan op de grond. Bij het uitzetten van de motor moet de propellor stilstaan, dat kan alleen als de regelaar governor en brake toestaat. Ik weet niet welke regelaars dat allemaal kunnen maar ik gebruik daarvoor een Castle Creations regelaar.

Als niet willekeurig voorbeeld sturen we 1639 us puls naar de ESC, de gemiddelde lijntrek in mijn situatie is 400. Loopt de lijntrek op naar 410 dan verminder ik de waarde naar de ESC naar 1629, verlies ik lijntrek tot 390 dan verhoog ik de ESC waarde naar 1649. Als dat niet genoeg reactie oplevert dan vermenigvuldig ik het verschil met een p-factor. Als die te hoog staat krijg je oscilaties en moet je de p-factor weer verlagen.

Dit is de manier waarop de actieve timer van Igor Burger in elkaar steekt. ESC_out = ESC_setpoint + (lijntrekgemiddelde - actuelelijntrek)*p_factor

In de bijlage 3 echte metingen van wat er met de lijntrek en ESC_out gebeurt bij verschillende p_factor
 

Bijlagen

Interessant, en onverwacht voor mij, dat de berekening alleen gebaseerd is op de lijntrek.

Het grootte voordeel van alleen de lijntrek meten is dat die vrij constant is, de te meten versnelling relatief laag (een paar G) en dat er voor deze lage versnellingen standaard accelleratie sensoren te koop zijn die goedkoop zijn (< 10 euro).
Ter vergelijking: de versnelling loodrecht op het model kan in bv loopings en hoeken oplopen tot 10-tallen Gs, sensoren hiervoor zijn kostbaar.

Ik geprobeerd om de achterliggende gedachte te begrijpen. Voel jullie vrij om me te corrigeren, mijn middelbare school mechanica kennis is ver weggezakt.

De lijntrek is, volgens mij, afhankelijk van de snelheid van het model en de hoek phi van de lijnen tov grondvlak (~vlieghoogte) waarmee het model vliegt.
  • Middelpuntvliedende kracht Fc = M*V**2/R.
  • Zwaartekracht component in de richting van de lijntrek Fz = -M*G*sin(phi).
  • Lijntrek Fl= Fc + Fz = M*V**2/R - M*G*sin(phi).
Classic combat met M=0.5kg, V= 30m/s, R=16, G=10 die een wingover inzet:
  • Horizontale vlakke vlucht: Fl = 0.5*30**2/16 – 0 = 28N = 2.8 kgf.
  • In het zenit (met zelfde snelheid): Fl = 28 – 0.5*10 = 23N = 2.3 kgf.
  • De snelheid zal dan voor 5N overgecompenseerd moeten worden om de lijntrek constant te houden:
    Vm = sqrt(Fc * R / M) = sqrt(33 * 16 / 0.5) = 32.5m/s
  • In dit geval wordt de sneldheid dus maximaal ca 10% te hoog.
Stunter met M=1.0kg, V= 25m/s, R=21.5, G=10 die een wingover inzet:
  • Horizontale vlakke vlucht: Fl = 1*25**2/21.5 – 0 = 29N = 2.9 kgf.
  • In het zenit (met zelfde snelheid): Fl = 29 – 1*10 = 19N = 1.9 kgf.
  • De snelheid zal dan voor 10N overgecompenseerd moeten worden om de lijntrek constant te houden:
    Vm = sqrt(Fc * R / M) = sqrt(39* 21.5 / 1) = 29.0m/s
  • In dit geval wordt de sneldheid dus maximaal ca 16% te hoog.
Indien bovenstaande klopt is active control op basis van alleen constante lijntrek een benadering voor constante snelheid met de hier boven aangeven maximale foutmarges (bij een ideale regeling).

Graag jullie reacties of mijn analyse klopt en of een maximale variatie van ca 16% acceptabel is bij stunt.
 
Back
Top