Onderwerp: Autopilot Tiller Drive icm Pypilot controller

Nee, in de Pelagic zit een microcontroller.

Zeilprutser schreef :
Nee, in de Pelagic zit een microcontroller.

sinds de eerste melding (19-8) dat de tiller opeens max BB uit stuurde was het een tijdje stil, maar afgelopen week was het weer een paar keer raak.
Het zit m dus niet in de tiller want het gebeurt op beide drives.

Het probleem wordt vermoedelijk veroorzaakt door de kabel van het fluxgate kompas dat in de tafel in de kajuit is geplaatst. Deze kabel zit wat krap door een uitholling van een vloerdeel en als je op de vloer staat drukt dat blijkbaar de kabel iets in. Er zal in de loop van de tijd een beschadiging zijn ontstaan, in ieder geval gebeurde het de laatste keren toen iemand hier ging staan.
(behalve die keer dat er een telefoon op tafel werd gelegd, dat was 90 graden de andere kant op )

Ik neem aandat de kabel gewoon in te korten is en dat ik het kompas opnieuw kan aansluiten.

Blijft nog wel een punt dat de gain van de stuurautomaat nu op 2 staat bij opstarten en niet op 5, mogelijk een keertje opnieuw calibreren als de kabel is gefixt

Ik ben ook nog opzoek naar mijn (incidentele) op hol slaan van mijn S1.
Zijn er hier ervaringen met het vervangen van een fluxgate door een GPS? Is een fluxgate sneller maar gevoeliger voor magnetische invloeden? Wanneer je bootje stilligt doet GPS het qua koers natuurlijk niet maar damn doet de stuurautomaat het ook niet...

ISO788 Hans schreef :
Geen ervaring, maar een GPS geeft andere data (course over ground) dan een fluxgate (heading). Ik verwacht niet dat een stuurautomaat daar veel mee kan.

[edit:] tenzij je altijd op routes en waypoints wil sturen misschien?

Wel off topic bovenstaande, het is een Raymarine probleem, echter met de Pypilot zou het mooi zijn als we dit kunnen voorkomen!

oei sorry, ik ben al weg...
De RM manual geeft aan dat er ook een NMEA vanuit GPS ipv fluxgate mogelijk is). Maar dat doe ik in een ander draadje,
Over en uit

oww sjips je hebt gelijk... Kunnen de mods er misschien een apart draadje van maken
raymarine stuurautomaat gaat in de fout?

Laten we voor de verandering eens een draadje posten in dit draadje dat ontopic is

Ervaringen met de laatste tinypilot versie (2020-09-30 beta):
- sturen op GPS werkt
- invoer Wind vanuit SignalK werkt
- Uitvoer naar SignalK voor roerstand en heading werkt
- Bediening vanuit OpenCPN (pypilot_pi 2020-09-02) werkt ook.

Bij de laatste pypilot kun je ook de roerstand en IMU direct callibreren in de pypilot-plugin. Dus OpenPlotter is niet meer noodzakelijk voor de pypilot.

Ik moet nog even kijken hoe een en ander beschikbaar kan komen voor Ubuntu Focal 20.04. Dat wordt waarschijnlijk via de pluginmanager (Sean is druk, maar dat heeft hij goed voor elkaar. De plugin zit nu nog niet in de repo maar met een klein beetje hulp en pushen komt dat er wel.)

Voor de laptop is de pypilot plugin gewoon via de pluginmanager te installeren.
Op de laptop ziet dat er dan zo uit (even zonder kaart):


De zooi moet bij mij nog worden ingebouwd, dus een praktijktest zal waarschijnlijk eerder van anderen komen.

reuver schreef :
Goed bezig Huub, jammer dat je nog niet hebt kunnen testen.!
Voor de testsets wil ik graag een ander display gebruiken maar ben daar nog niet verder mee.
Volgende week vrijdag komt Niels langs en gaan we daar eens naar kijken.
Die zaterdag er na ga ik met Seaquest Solozeiler de drive testen of voor hem die het verschil kan maken, misschien dat we dan ook ff de mogelijkheid hebben onze setup eens te vergelijken.
Hij heeft al de Q047 met EVO100 dus het is allemaal plug in, kalibreren and play.

Zonder nou weer het hele draadje door te moeten worstelen: ik heb de knoop doorgehakt en besloten om van een actuator bij de spiegel (ik heb geen helmstok) af te zien. Reden: twijfel over de veiligheid (niet snel los kunnen maken in geval van nood) en het formaat van de actuator van ZP, die voor mijn doel te lang is.
In plaats daarvan heb ik een gebruikte Raymarine ST4000 MKII wheeldrive op de kop getikt op Ebay. Mijn vraag is nu: die wheeldrive gaat toch net zo goed werken met ZP's controller? De controller van het Pypilot project is in ieder geval werkend bevonden, dus dat kan het probleem niet zijn.

@ Eclips Dat is correct.

Heb zelf nu 1 keer met ons systeem gevaren dat ging nog niet helemaal foutloos vooral omdat ik op dat moment nog geen snars snapte van de PID regeling, daarnaast is Sean aardig aan het updaten en had ik natuurlijk een laatste versie met nog wat bugs....
De weergegeven koers was echter meteen zeer constant en correct dat vond ik eigenlijk het belangrijkste.
En met de kennis nu opgedaan over PID denk ik dat ik die instelling ook wel goed moet kunnen krijgen.
Wacht nu op bericht van Seaquest solozeiler dat ik weer een keer met hem mee mag.

De test set zit nog steeds vast op de bedienunit ik wil een ander display en dan laat ik meteen een professionele frontfolie maken zodat het ook meteen geschikt is voor productie.

Top! Ik blijf het volgen.

Zeilprutser schreef :
Display? Ik dacht dat de bediening via Pypilot zou gaan. Of maak je iets wat ook standalone kan werken?

Ja, nee, ja...
Je hebt de drive, motorcontroller en aanstuurunit/bedienkast.
Drive is klaar, motorcontroller is klaar.

En dan heb je een zee van mogelijkheden voor het aansturen van de Motorcontroller

1:Ik ben nu bezig met een standalone unit die je ook kan koppelen aan elk ander systeem naar wens.
Dit is echter op basis van de gewone Pypilot icm de EMU Pi-ZeroW een display en een paar toetsen.
Op die manier heb je ook alle mogelijkheden van punt 2.

2: Het Display en de toetsen zijn echter niet noodzakelijk, want je kan hem ook bedienen met elk apparaat met een webserver (mobiel, tablet, laptop, pc, raspberry, etc) of je kan hem bedienen via de pluginn van OpenCPN en/of Openplotter.

De Drive, Controller en aanstuurunit op basis van punt 2 zijn nu leverbaar!

3: Icm OpenPlotter of Pypilot op een Raspberry kun je indien je daar ook een EMU (digitaal kompas) aan hangt ook direct de MotorController aansturen, ik heb daar echter zelf nog geen ervaring mee.

Ik had een testset in de planning maar de uitwerking van de Standalone bedienunit had niet het gewenste resultaat.
Komt er op neer zoals ik het front nu heb gemaakt kan ik zelfs niet met droge ogen als testunit uitleveren.

De toetsen op de goede hoogte krijgen is een drama, te veel losse onderdelen, display heeft een rotmaat waardoor ik voor een beetje smoel de toetsen er wel naast moet zetten zoals ik gedaan heb, maar ik heb 4 toetsen in een strip naast elkaar die ik liever gebruik, maar dan moet de behuizing een stuk groter en heb je allemaal loze ruimte naast het display.
Folie is zo niet goed genoeg (laat los) dus ik moet investeren in een betere folie en dan wil ik eigenlijk naar een versie die ook verkoopbaar is.
Met kleine aanpassingen in de software dacht ik wel een geschikter display te kunnen vinden.
Dat blijkt echter nu niet zo te zijn.
Toevallig vanochtend weer een uur gebrainstormd hierover en weer een paar verwijzingen gekregen naar opties, die worden het ook niet. Maar ik wil graag nog verder kijken in die richting....

Dit is het prototype van de testunit waar ik niet blij mee ben:
(Links Controller die is goed rechts de bedienunit)

Het valt nog niet mee, hè.

Ik weet niet of het hier op zijn plek is, maar het idee kwam bij me op toen ik dit draadje las, dus vandaar...

De discussie voerde even naar varen op GPS koers, dit lijkt mij zelf te langzaam aan te passen (koer is een gemiddelde) om een AP goed op te laten varen. Wat wel zou kunnen is de heading halen uit een GPS kompas zoals die commercieel voor te veel geld te krijgen zijn....
Zou je een dergelijk kompas ook op basis van een Raspberry kunnen maken? In beginsel is het niet meer dan twee GPS antennes die op een afstand van elkaar gemonteerd zijn (cm of 60 bij de commerciële units) die tegelijk een positief doen. Door het verschil in de verschillende fixen kan je de oriëntatie van de unit bepalen.
ALs je twee GPS ontvangers aan een PI zou koppelen, zou je dan iets vergelijkbaars kunnen doen of kom je daar rekenkracht (of iets anders) voor te kort?

Voorbeeld van een dergelijke unit van Furuno www.furuno.com/en/products/compass/SC-70

HotSnail schreef : Misschien moet je toelichten waarom je GPS-ontvangers wil gebruiken voor een Pilot?
GPS is notoir onzuiver, (in verhouding) duur en het vraagt veel rekenkracht om daaruit iets bruikbaars te destilleren.

Met een 9-DOF IMU krijg je een compleet beeld van de voorliggende compaskoers EN de beweging van de boot. En dat met minimale rekenkracht, zolang je de module gebruikt met alles bij elkaar en korte lijntjes.

Feitelijk doet een pilot weinig anders dan de ingestelde (voorliggende) koers vergelijken met huidige voorliggende koers en een stuursignaal doorgeven aan de drive. GPS koers en Windkoers zijn daarbij 2 methoden van invoer, maar in feite heeft de Pilot niets met GPS (positie) te maken. GPS snelheid en richting hebben alleen indirect een invloed op de Pilot.

De standaard raspberry oplossing is een TinyPilot met een IMU. De hier besproken is feitelijk een TinyPilot.

Voordat je in de war raakt met termen:
- TinyPilot: de raspberry pi zero met IMU (dus de hardware)
- pyPilot: de software voor de pi zero (of RPI1/2/3)

GPS als kompas (dan met een dubbele antenne en daar een diffetentiaal berekening op) om dat deze een zeer snelle respons op heading verandering geven die wel heel precies is. De GPS fix zelf is niet heel precies, maar door op hetzelfde moment twee posities te bepalen die vlak bij elkaar liggen heb je dezelfde afwijking en zijn de positie's relatief ten opzichte van elkaar wel precies.
Als je de heading uit een op magnetisme gebaseerd apparaat haalt zit je altijd met de afwijking die daar bij hoort. Wij hadden de fluxgate naar mijn idee goed geplaatst maar ik was even vergeten dat er in de spiritusbrander intern wel magnetisch materiaal zit wat bij uitschuiven van de keuken een koerswijziging gaf van een graad of 40... best lastig onder spi
Ook aan boord van een polyester schip heb je altijd magnetische storing en dat zou zo mooi te ondervangen zijn. Nog afgezien van de storing die je hebt als je langs een vrachtschip vaart of op sommige plaatsen bij tunnels of buizen.

Ik zou zeggen: geef een link naar een library voor zo'n oplossing.
Bij de IMU's en verschillende andere sensoren werden deze ook geleverd door de fabrikant.

HotSnail schreef : Ja en nee je komt zeker geen rekenkracht te kort.

Zoals Reuver zegt als iemand er al een library voor vrij heeft gegeven dan is het zo te maken.

Je moet je echter wel even afvragen is het zo goed als ze zeggen?
Het zou zo maar kunnen dat het moduultje van een paar dollar het beter doet dan zo'n systeem.
Als voorbeeld bij Thales dachten ze daar ook anders over het zou toch niet kunnen dat hun defensie GNSS van $ 10.000,- het slechter zou doen dan een U-Blox module van $ 12,-, het bleek toch zo te zijn.....

Het grote voordeel is dat de DOF/IMU modules goede bewegingssensoren hebben.
De bak met ruis van het kompas wordt aangevuld met de data van de werkelijke bewegingen.
Het goede nieuws is dat de kompaskoers van de pypilot verrassend goed lijkt te werken, dus ik zie geen noodzaak energie in de GPS oplossing te stoppen.

Naar mijn mening met helaas de weinige ervaring die ik persoonlijk nu heb met de unit denk ik dat de Pypilot op dit moment al een heel goed elektronisch kompas is.
En met wat hulp van de community kan dat alleen maar beter worden mocht het nodig zijn.
Mocht het dan wenslijk zijn dan zou ik eerder een tweede DOF/IMU plaatsen.

Je zou de Tinypilot naar mijn mening ook alleen als elektronisch kompas kunnen gebruiken.
Als daar vraag naar is kan ik wel kijken wat dat zou kosten met een NMEA0183 OUT zonder display en toetsen.

Het is jammer dan ironman dit jaar niet meer potst die heeft volgens mij de meeste ervaring met het systeem zoals het nu is.

Zeilprutser schreef :
Sorry, hier moet ik toch als elektronica ontwikkelaar met meer dan 30 jaar ervaring even op reageren. Technisch inhoudelijk.

Ik heb al eerder aangegeven dat het probleem van Mems sensoren is dat de de gemeten koers mede erg afhangt van de helling van de module. Dat is dus precies wat een zeilboot doet, dat hellen. En dus krijg je onbruikbare waardes.

Nu is dat op te lossen met omgekeerd geïnstalleerde sensor erbij en dan weer het verschil als heading gebruiken.
Maar ik ben wel benieuwd of iemand dat al zo werkend heeft , op hobby nivo, dat het ook bruikbaar is voor een AP. Want dat is allemaal echt niet zomaar even "heel goed" werkend

Meer dan 5 graden ernaast is echt een probleem als je serieus gaat zeilen.

Op hobby nivo maakt het allemaal niet uit, en is het een leuke gadget.

De echte modules zijn niet voor niks zo duur hoor. Ik weet wel dat de rpi + hat gebruikers denken dat het allemaal erg makkelijk na te bouwen is, en het dan zelfs nog beter werkt. Maar het is geen broodje kroket, zoals een mede ZF'er plagt uit te drukken.
Vele van deze ontwikkelaars komen pas na een paar jaar erachter waarom het zo moeilijk is om een acceptabel resultaat te krijgen. En dan zijn ze allang weer met wat anders bezig natuurlijk. Het is immers een hobby...



nb: er zullen wel weer een aantal gaan flippen nu, maar dat moet dan maar. Verder moet een ieder moet zelf weten wat ie doet. Van mij part hang je je hele boot vol met frambozen.
Maar de onschuldige lezer kan zo wel een hele verkeerde kant op gestuurd worden. pun intended.
Er was een tijd dat ik me hier serieus zorgen over maakte, die tijd is voorbij, dus discussies in die richting zijn zinloos, en zal ik ook niet op reageren

@roos
Ik denk dat dat je een beetje moeilijk denk over de installatie (in absolute zin dan).

Voorbeeld 3D GPS:


Zet als proef 3GPS modules met een paar plankjes op een fixed afstand van zeg 40cm (driehoek).
Maak een kleine HAT voor een Pi-zero met 3 seriele poorten.
Lees 3 GPS modules uit, daarna moet je werken met gesynchroniseerde data of je stelt dat alle data altijd in dezelfde volgorde binnenkomt.

Dan heb je 3 positiemetingen X,Y,Z. Daaruit kun je de positie van de boot berekenen (heading, roll, pitch). Elementaire matrix rekening, niet moeilijk en zeer waarschijnlijk is de arm1176 niet de meest optimale processor hiervoor. Callibratie zou ik ook meteen in de eerste berekening stoppen, maar dat is zorg voor later.

De 3 zaken die fout kunnen gaan:
- een fout in de positie wordt mega uitvergroot 1cm verschil is al 2 graden afwijking.
- zijn de 3 GPS-sen onafhankelijk?
- de positie moet ca 20 keer per seconde bepaald worden...

Als je de tijdfactor eruit kunt slopen zal e.e.a. wel mogelijk zijn. De vraag is of alleen een realtime OS hier voldoende is. Als je pech hebt moet je de onafhankelijkheid uit de GPS-modules met hardware afhankelijk maken. En ik vermoed dat dat bij de JLR ook gebeurd.

Er is nergens gezegd dat een 3D GPS bruikbaar is voor een pilot. En de laatst bekende nauwkeurigheid van een sensor zat volgens mij rond de 30cm. Als je 2 onafhankelijke GPS-sen vergelijkt heb je het dus over een meetfout van ca 60 graden.

Maar om even aan te sluiten bij roos:
Leuk projectje, maar niet voor 1 winter.

Oh, ik ging uit van mems sensoren. Alleen gebaseerd op gps gaat zeker niet werken, op hobby nivo, naar mijn mening.

Vergeet ook niet dat je vervelende reflecties krijgt vanaf het water oppervlak. Die beïnvloeden de gemeten waarde.

Professioneel zijn ze ook erg duur, en dat is niet voor niks.

roozeboos schreef :
Volgens mij is het niet zo zwart-wit als jij het schetst. In een 9DOF module zitten sensoren in alle richtingen om de genoemde effecten af te vangen. Daarom is het van belang dat je een goede library gebruikt, want daarin zitten alle effecten en foutafhandeling verwerkt (ook de fouten van de specifieke chipoplossingen),

Met de GeDad hebben we inmiddels gezien dat een Raymarine geen optische isolatie inbouwt om kosten te besparen. Denk je dat ze wel een dubbele 9-DOF IMU inbouwen in een EVO?

Ja, bij een professionele installatie ga je redundant en fouttolerant werken. En misschien dat je het op een zeilboot gaat toepassen als je de Vendee Globe vaart. Hoeveel serieuze Vendee Globe zeilers ken je met de consumentenpilots van Raymarine, Simrad, Garmin of B&G aan boord?

De pyPilot doet het beter dan mijn oude Autohelm, dat is een heel ander prestatie niveau dan jij verlangt.