Onderwerp: PGN om een RM ACU100 + wheel drive te besturen?

Ik heb een ACU100 en een Wheel Drive van Raymarine maar geen EV1. Ik probeer de wheel drive te laten bewegen door de ACU100 aan te sturen.

Ik heb zelf een N2K-netwerkje gebouwd met een Arduino en een CanBus interface er in. Ik krijg van de ACU100 verschillende PGNs die de roerpositie vertellen. Maar ik wil juist de wheel drive laten draaien. Welke PGN zou ik moeten sturen naar de ACU100 om de Wheel Drive te laten bewegen?

Dit komt er o.a. uit een EV1 ;

Vessel Heading PGN (127250) – 10 Hz

Rate of Turn PGN (127251) – 10 Hz

Attitude PGN (127257) – 1 Hz

Moet het perse met een PGN? Bij mijn weten zet de ACU100 simpelweg stroom op de drive en als het de andere kant op moet wordt de polariteit omgewisseld.

Je moet de acu100 natuurlijk wel vertellen wanneer de drive wat moet gaan doen , hoelang en linksom of rechtsom .

Dat weet de acu100 door het kompas de EV1.

De roerstandgever zit direct op de acu100 dus die berichten zie je wel voorbij komen. Als er geen kompas is zal je die ook niet zien en de berichten , resultaat de acu100 heeft geen idee wat hij moet doen .


Als je Duits kan heeft deze wat ook met een Arduino gemaakt en gespeeld wellicht heb je er iets aan klikker de klik

PB hanst even; hij heeft gewerkt om een control head voor een ACU te emuleren op een B&G plotter via een SignalK conversie. Heb lang geleden voor hem nog een CANdump gemaakt om het busverkeer te loggen.

Maar wat wil je precies? Een kompas- of grondkoers sturen, of alleen het roer laten bewegen? Zelfs voor dat laatste zijn proprietary PGN’s nodig om je ACU in Follow-Up mode zetten en vervolgens rudder commands door te geven. Het lijkt eenvoudiger dan het is. Wel interessant

github.com/htool?tab=repositories

github.com/htool/signalk-raymarine-autopilot

Ik heb een ACU100 en de wheel drive maar geen EV1. Wel voldoende GPS en heading sensoren om met bijvoorbeeld pypilot de wheel drive aan te sturen. Om met PyPilot te werken, moet je een motor controller hebben die de wheel drive aanstuurt - maar omdat ik ook al die ACU100 had, die ook als motor controller lijkt te fungeren, hoopte ik stiekem dat ik die kon gebruiken in plaats van rechtstreeks de wheel drive aan te sturen.

Ik neem aan dat de stuuralgoritmes obv input van sensoren in de EV1 zitten (dus component die vervangen kan worden door PyPilot). Op de RM website zelf staat:
Ben dus inderdaad op zoek naar commando's die ACU in follow-up mode zetten (hoe? kan er niets over vinden) en dan, neem ik aan, commando's aan de ACU die zoiets zeggen als: zoveel beweging naar links, zoveel naar rechts.
Jeroen-Pion schreef :

Nachtvlinder schreef :
Dat is wel nuttig, gaat vooral over de communicatie tussen controlepaneel en EV1. Heb je die dump misschien nog ergens?

Heb je hier iets aan?
Hierin kun je ook vinden welke commando's werken om het stuur te draaien....

lschip schreef :
Ja, enigszins. Dit gaat over de verbinding Controlepaneel <-> EV1, en ik ben juist geïnteresseerd in de verbinding EV1 <-> ACU100 (en dus ook: <-> wheel drive).

Als ik zelf overigens een Rudder angle PGN stuur naar de ACU100 (PGN 127245) dan krijg ik van de ACU100 een ongedocumenteerde PGN terug die lijkt op een foutmelding:

Ouderwets trial-and-error...

roelanto schreef :
12 Feb 2020 heb ik iets verzonden naar hanst, echter kan díe mail met attachment niet meer vinden. Vraag hanst even; die heeft dit mss nog en is hier behoorlijk ver mee gekomen (er staat meer op zijn Github omgeving dan ik gelinked heb!)

Daarna nog in detail willen loggen op zijn verzoek, ook het ISO overhead verkeer waar beide apparaten elkaar bevragen en opnemen in hun device list, maar dat is misgelopen met Corona enzo. Die zinnen zul je allemaal moeten uitpluizen en afhandelen, anders snapt je EVO niet dat hij door een door hem ondersteunde control head bediend wordt

Is het niet makkelijker de uitgangen naar je drive te overbruggen en alleen nog wel de roerstandsensor te gebruiken van de ACU? pypilot bevat toch al alle intelligentie...

Nachtvlinder schreef :
Eigenlijk is dat ook wat ik wil. Die ACU dus gebruiken als motor controller en niets anders. Er zit geen roerstandsensor aan de ACU volgens mij. Als ik 'tikkie naar links' kan sturen of 'tikkie naar rechts' dan ben ik al blij

Die ACU100 is me overigens nogal een duur apparaat, 500 euro. Vraag me af wat die dan allemaal doet, als het de EV1 puck is die de intelligentie levert. Is de ACU echt alleen maar een PWM controller met een canbus-interface?

Er is ongetwijfeld allerlei proprietary RM communicatie tussen EV en ACU.
Dat gaat nooit met (openbare) PGN's.

Bovendien stuurt de EV de ACU niet alleen volgens het beng-beng principe aan: aan of uit.
Er wordt gemoduleerd; de ACU kan met meerdere variaties de stuurmotor (Type 1 hier) tussen hard en zacht aan sturen, niet alleen aan-uit. Het gaat veel subtieler.

Baasklusje schreef : Dat heb ik al eerder gelezen.
Maar ik merk daar niets van, het stuur wordt door het motortje, zo lijkt het, met kleine stapjes verzet of bij een grotere richtingverandering draait het motortje met een vaste snelheid.
Dus het lijkt dat de snelheid van de motor altijd gelijk is maar dat deze bij kleine correcties alleen heel kort wordt aangestuurd.

lschip schreef :
Bij mijn ACU200 en Type1 lineaire motor gaat het heel zeker met allerlei intensiteiten. Maximaal de Drive aansturen is een grote uitzondering, het zijn meestal kleine subtiele geluiden uit de TYpe1

Baasklusje schreef :
Ik neem aan dat het de ACU100 is die moduleert bij het aansturen van de drive, en niet de EV1? Dat lijkt me in ieder geval logisch: EV1 leest sensoren (onder andere zijn eigen kompas) en plant koerswijzigingen, ACU voert die uit door Wheel Drive te draaien?

roelanto schreef :
De EV geeft commando's aan de ACU. De EV IS de stuurcomputer, niet alleen de sensor.
Die ACU voert dat braaf uit. Als het commando iets is als 'voorzichtig tikje naar SB met ROT 10 graden per minuut en voor 0,5 seconde' zal de ACU vermoedelijk niet de volle 12,6V op de drive zetten maar iets lagers. Denk ik.

Baasklusje schreef :
Precies, dat dacht ik al. Nu nog dat stukje van dat 'voorzichtig tikje naar SB ...' zien te genereren...

Dat is wel heel specifiek. Vast proprierary PGN's. Dan heb je ook niets aan mijn CANdump file, want dat was binnen een B&G/Simrad systeem. Dat zit fundamenteel anders in elkaar. Stuurcomputer en drive-uitgangen zitten daar fysiek in één apparaat. Dit zal in een RM netwerk wel behoorlijk veel traffic geven!

BK lief vragen of je je Pi in zijn netwerkje mag laten spioneren

De auteur van deze plugin lijkt veel met dit bijltje gehakt te hebben; ik geloof niet dat hij zich op dit forum ophoudt maar je kunt hem misschien bereiken via github.

Nachtvlinder schreef : Ah juist, dacht dat het een CANdump was van een draaiend RM-systeem...

Nee, ik heb zo min mogelijk inferieur spul aan boord

Serieus: waarom verkoop je die ACU niet en bouw je op die Arduino een PWM uitgang; heb je alles in eigen hand en scheelt je heel veel trail&error backengineering werk (hoewel dat laatste ook leuk kan zijn natuurlijk)!

Het verleidelijke is dat het nu slechts "een software dingetje" lijkt (en dat ook is...), maar dat maakt de oplossing niet eenvoudiger

Douwe is op vakantie! Je kan beter die ACU snel verkopen en dan een motorcontroller van Sean kopen dan ben je meteen klaar, als dan iets niet goed werkt komt het door Pypilot en weet je dat het niet komt door de motorcontroller. Roersensor is voor het stuurgedrag overbodig bij Pypilot.

Nachtvlinder schreef :
Ik begin ook wat voor die route te voelen. Het was gewoon verleidelijk dat er al een kastje met een PWM controller en een groen lampje en een mooi stukje plastic leek te zijn. Maar het lijkt inderdaad meer werk te worden, en dan wordt het voordeel al gauw een nadeel.

Zeilprutser schreef :
Hij gaf toch meteen antwoord Zijn antwoord kwam er op neer dat hij iets heeft gebouwd voor aan de voorkant van de EV1 en niet voor aan de achterkant. Hij zei ook: "Ik herinner me nog wel dat er erg veel over de bus gaat tussen de EV1 en de rest van het systeem (AC100)." dus dat lijkt te suggereren dat het nog niet zo eenvoudig is om de communicatie van de EV1 over te nemen.

De aparte motorcontroller wordt verleidelijk.

Slecht systeemdesign zou ik denken: een N2K bus voor algemeen gebruik gaat RM misbruiken om met hoge frequentie tussen twee van hun eigen apparaten te praten. Waar verder geen ander device geïnteresseerd in is, maar wel de bus belast (en niet een beetje denk ik). Zou ook met een dedicated serieel busje kunnen tussen EV en ACU...

Anyway blijkbaar gaat dat goed, in de praktijk.