Hoe kan ik een geschutstoren 290 graden laten draaien

[max z]

Ik gebruik hier de pulseIn() functie, die werkt op elke pin om een willekeurige puls op te pikken. Pin 2 en 3 op de UNO zijn de z.g. hardware interrupt pins. Je kunt daarmee een "Interrupt Service Routine" (ISR) op elk moment aanroepen, ongeacht wat de rest van het programma aan het doen is. Kijk eens naar de code die ik plaatste in post #30, daar worden zelfs beide interrupt pins gebruikt voor twee verschillend kanalen, maar die wel allebei dezelfde ISR aanroepen op het moment dat de status van de pin wijzigt van 0 naar 1 of omgekeerd. Met slimme code worden dan vervolgens de twee uit elkaar gehaald en de tijd tussen 0>1 en 1>0 gemeten, die dan vervolgens weer de variabele met dezelfde naam in de loop wijzigt. Die variabele moet daarom ook als "volatile" bestemd worden, oftewel gevoelig voor wijzigingen die door andere code routines buiten de hoofd-loop gegenereerd worden.

Ook de synchronisatie van inkomende en uitgaande pulsen wordt op dezelfde manier geregeld ( variabele "sync") met een while() loop die uitvoering van de hoofd-loop tegenhoud totdat sync false wordt vanuit de ISR, waardoor de while()-loop verlaten wordt.

Ik heb pin 4 als pulse input gekozen in de huidige code, maar als je niet ook met interrupt werkt is er niets op tegen om 2 of 3 te specificeren.

De squigly duidt op een mogelijke PWM output, dus een pseudo-analoge output pin. Daarmee kun je een analoge waarde simuleren door de pin snel tussen 1 en 0 te laten variëren met een regelbare verhouding en een vaste herhaalfrequentie. Daarmee kun je een gewenste pulslengte genereren, maar ik vind dat onoverzichtelijk. Bovendien is de herhaalfrequentie veel te snel voor een gemiddelde servo, in plaats van 50 Hz gaat dat met 490 Hz (pins 3,9,10,11) of zelfs 980 Hz (pins 5 en 6). Niet alle servo's kunnen daartegen, zeker de analoge types niet. Bovendien is de standaard PWM aansturing te maken met een variabele tussen 0 en 255 (8-bits), waarvan je dus moet berekenen hoe groot die stap moet zijn om de gewenste servopuls te genereren, en dat moet kleiner zijn dan 255, want daarmee genereer je een continue 1 op de pin. Pin 5 en 6 zijn volgens mij helemaal niet bruikbaar voor dat doel, dus houdt je nog maar 4 uitgangen over.

Ik gebruik de Servo_h library om de pulsen te genereren, klaarblijkelijk werkt dat goed op alle digitale pins (inclusief A0 t/m A5), met het bijkomende voordeel dat de herhaling met 50Hz door de library zelf gegenereerd wordt, ook al wacht de loop op nieuwe input met pulseIn().

 

[max z]

Hier alvast de code voor de "uitgerekte" output. De beide arrays Xpulselow en Xpulsehigh bevatten de laagste en hoogste pulswaarde voor elke servo.
Ik heb e.e.a. symmetrisch rond een puls van 1500 microseconden gehouden, maar dat is niet strikt noodzakelijk. Wel moet je in de gaten houden dat, als één van de twee veranderd, het middenpunt ook verschuift.
Op deze manier kun je alle servo's zo inregelen dat de uiterste standen overeenkomen. Maar als je servo niet een lineaire curve graden/microseconden heeft zullen de middenstanden mogelijk niet overeenkomen, en dat ga je merken als meerdere servo's/kanonnen met één multiprop pot bediend wordt. Als je individueel de middenstanden wilt kunnen corrigeren wordt de code een stuk uitgebreider, met een hoop if'en.

Ik kan de code zo niet testen, mijn servotester komt niet zo laag..........

Een snelheidsbegrenzing volgt later.

int mpcount, pulse, Xpulse;
int Xpulselow [ ] = {650, 650, 650, 650, 650, 650, 650, 650};
int Xpulsehigh [ ] = {2350, 2350, 2350, 2350, 2350, 2350, 2350, 2350};
bool start = false;

#include <Servo.h>
Servo MPS[8]; // array of Multi Prop Servo objects MPS [0] - MPS [7]

void setup() {
 
  pinMode(4, INPUT);
 
  Serial.begin(9600);

  for (int i=0; i<8; i++) {
  MPS[i].attach (i+5); // servo output attached to pins 5 - 12
  }
}

void loop() {
 
  pulse = pulseIn(4, HIGH); // timeout?

  if (start && pulse >=1000) {
    Xpulse = map (pulse, 1030, 1980, Xpulselow [mpcount], Xpulsehigh [mpcount]); // extending pulse to Xpulse
   
    MPS[mpcount].writeMicroseconds(Xpulse); // array starts at MPS[0], ends at MPS[7]
    Serial.print ("MPS"); Serial.print (mpcount); Serial.print (" pulse"); Serial.print (pulse); Serial.print (" Xpulse");
    Serial.println (Xpulse);
    mpcount += 1;
    if (mpcount >7) {
      start = false; // stop saving subchannels after 8 counts
      delay(500); // only for testing the output by monitor, deactivate for servo operation
    }
  }
 
  if (pulse >= 850 && pulse <950) { // syncpulse
    start = true;
    mpcount = 0;
    Serial.println ("");
  }
}

 

[Herby63]

@max z
Al de halve dag aan het testen en tweaken met een proefopstelling.
Alles stabiel, maar de servo's gaan elk om beurt, en soms enkele tegelijk enkele graden heen en weer, waarschijnlijk te wijten aan de lichte variatie van de pulsen.
Klaar voor een eerste foto dus:
Losgekoppeld van de PC, en alles gevoed met een 9V batterij, via de voeding in de Elegoo super starterkit, die 5V geeft op de onderste 2 rijen van het breadboard.
De servo's zijn geplaatst in een patroon dat overeenkomt met de plaats van de potmeters. De potmeters staan allen in neutraalstand
De blauwe miniservo's dienen voor het baksen (horizontaal draaien) van de geschutstorens.
De zwarte microservo's moeten in de torens ingebouwd worden voor het heffen en dalen van de lopen.
De blauwe servo's moeten dus liefst 290 ! ° kunnen draaien (opgezocht in het boek Anatomy of the Ship - The battleship Bismarck)
De zwarte servo's hebben een veel kleinere reisweg te doen, maar daar kom ik later op terug.
De zwarte servo's kregen vlug warm op 5V, en daarom heb ik deze van 3,3V voorzien (de 2 bovenste rijen op het breadboard).
Let niet op de 8 LED's, die zijn van een vorige test en niet aangesloten.

En nu met alle pots naar rechts gedraaid - alle servo's zijn naar links gedraaid

De blauwe servo's hebben een verlengde reisweg maar halen maar ongeveer 115° ( en niet de gewenste 145°)
De zwarte servo's hebben een veel kortere reisweg, maar dat is geen probleem, omdat die een veel kortere reisweg moeten hebben.

En toen ik alle pots naar links draaide werd het ganse systeem weer onstabiel, met grote uitslagen heen en weer, vandaar geen foto.

Die 9V batterij heeft blijkbaar maar een beperkte capaciteit (150mAh) en stond zo laag dat ik geen 5V meer op de voeding mat.
Deze dus vervangen door een voeding die ik vroeger gebruikte als ik met RC cars racete.

Met de Arduino aangesloten op de voeding (5V) krijg ik het systeem echter niet stabiel, wel als ik de Arduino aan de USB-kabel leg, en al de rest aansluit op de voeding. Bizar !

In een volgende test heb ik alle zwarte servo's vervangen door de blauwe miniservo's, om uit te sluiten dat deze voor onverwachte reacties zorgen.
Nu is het systeem weer stabiel. Ik heb wel de waarde van de pulsen een beetje getweakt om te vermijden dat een onverwacht lage puls niet gelezen wordt (1000 ipv 1030) (syncpuls onveranderd tss 850 en 950).

Nu het weer stabiel was, heb ik wat met de xpulselow en xpulsehigh gespeeld om te zien of ik de uitslag nog wat kon vergroten.
Een verhoging blijkt geen grotere uitslag op de servo's te geven.
Bij 1 servo heb ik dan een externe travelextender tussen de arduino en de servo geplaatst. Uitslag is nu ongeveer 137° naar elke kant, wat aanvaardbaar is.
Hierop dan maar getest wat de invloed van xpulselow en xpulsehigh is: waarden op 1000 - 2000 gezet, geeft hetzelfde resultaat als 650 - 2350, een aanvaardbare 107° dus.

Nog en laatste tweak, de servo's draaien in de omgekeerde richting van de pots, het gevolg van mijn vasthouden aan de REVerse op dit kanaal in de zender.
Voor de onderste servo's is dat goed, want voor het heffen van de lopen moet de servo naar onder (links) duwen op het affuit van de lopen als ik de pot naar rechts draai.
Voor de bovenste servos is dat echter niet goed omdat de toren in de richting van de pot uitslag moet draaien. Ik heb dus voor de eerste 4 servo's (bovenste rij) de waarden in xpulselow en xpulsehigh omgewisseld, en nu doen ze precies wat ik wil.

Conclusie:
Oplossing te zoeken voor het extern voeden van de Arduino, want ik kan moeilijk de PC in het schip meenemen als ik wil varen
In het draadje dat je al 2x aanhaalde waar Jan (Corrien) waardevolle info ter zake verschafte meldt de vraagsteller dat het programmeren van een vertraagde travel zijn systeem stabiliseerde wat het ritmisch kort heen en weer bewegen van de servo's betrof. Ik zou dat dus graag eens proberen.

 

[max z]

@Herby63 Dat roept allemaal vragen op, dus ik begin daar eerst maar eens mee.

- zijn de blauwe servo's de versie waar we in post #21 over spraken, met de geadverteerde weg van 270 graden bij pulslengtes van 520 - 2350?
- waarom het systeem bij een gecombineerde 5V voeding niet stabiel blijft weet ik ook zo gauw niet, maar de UNO heeft een eigen spanningsregelaar. Je kunt proberen op de plug aansluiting bijvoorbeeld een 9V batterij aan te sluiten, of een 2s lipo.

Ik heb wel de waarde van de pulsen een beetje getweakt om te vermijden dat een onverwacht lage puls niet gelezen wordt (1000 ipv 1030)

- als je hier de 1030 in de map() functie bedoeld, dat is geen limiet, maar een rekenwaarde. Als de aangeboden puls lager dan dat is wordt uitkomst geëxtrapoleerd. Maar de if-functie waarbinnen map() staat zou moeten garanderen dat er geen pulsen van <1000 verwerkt worden. Dus tussen 1000 en 1030 gaat de uitkomst lager dan Xpulselow, maar dat merkt alleen de servo, en zolang die dat aankan zou er geen probleem mogen zijn. Tenzij de servo dus een limiet heeft waaronder deze continu gaat draaien (zie mijn eerste vraag)

Bij 1 servo heb ik dan een externe travelextender tussen de arduino en de servo geplaatst. Uitslag is nu ongeveer 137° naar elke kant, wat aanvaardbaar is.
Hierop dan maar getest wat de invloed van xpulselow en xpulsehigh is: waarden op 1000 - 2000 gezet, geeft hetzelfde resultaat als 650 - 2350, een aanvaardbare 107° dus.

- kennelijk heeft de extender die je hier gebruikt dus een begrenzing op de toegestane pulslengte, buiten die grens blijft de output constant.

Later verder..

 

[Ernst Grundmann]

[.....- waarom het systeem bij een gecombineerde 5V voeding niet stabiel blijft weet ik ook zo gauw niet, maar de UNO heeft een eigen spanningsregelaar. ..

Ik denk dat ik het weet, die 9V batterij kan de (piek)stromen niet leveren. Hierdoor zak de spanning te ver in waardoor de spanningsregelaar problemen krijgt. De 5V zakt ook (iets) in elkaar en zulke vervelende dipjes vindt de rest van de elektronica ook niet leuk.
Volgens mij zullen de problemen met de voeding over zijn wanneer je voor een voeding zorgt die meer (piek)stroom kan leveren. Een 9V batterij kan dat namelijk niet zo best.

 

[max z]

In het draadje dat je al 2x aanhaalde waar Jan (Corrien) waardevolle info ter zake verschafte meldt de vraagsteller dat het programmeren van een vertraagde travel zijn systeem stabiliseerde wat het ritmisch kort heen en weer bewegen van de servo's betrof. Ik zou dat dus graag eens proberen.

Ik heb een versie klaarstaan daarvoor, waarbij de "gemapte" puls (sorry, ik weet even geen alternatief in goed Nederlands) opgeslagen wordt als een "target". Bij elke ontvangen puls worden de posities van alle servo's vergeleken met de target (dus niet alleen degene die "aan de beurt is" in de cadans van de multiprop), en wordt de servo dan daar naar toe gestuurd met een maximum stapgrootte per keer.

Daardoor wordt de impact van een "misslag" in de puls vanuit de ontvanger dus minder zichtbaar, hoogstens doet de servo een stapje terug op de ingeslagen weg.

Mijn probleem is nu dat ik dat er structurele wijzigingen in de code zitten waardoor dat ik dat niet goed meer kan testen met mijn simpele servotestertje. Ik zou eigenlijk een andere arduino moeten programmeren als pseudo-multiprop...........

 

[max z]

Ik denk dat ik het weet, die 9V batterij kan de (piek)stromen niet leveren.

Deze dus vervangen door een voeding die ik vroeger gebruikte als ik met RC cars racete.

De 9V batterij was al uit bedrijf Ernst, maar kennelijk blijft het problematisch om de arduino en de servo's uit dezelfde bron te voeden. Ik stelde daarom voor om een aparte bron aan te bieden via de ingebouwde spanningsregelaar, en dat mag volgens mij best een 9V batterij zijn, want zoveel stroom trekt een UNO niet denk ik.

 

[max z]

Hier dan toch maar de ongeteste code. Let erop dat de pulsen binnenhalen nu wel met een Interrupt Service Routine gaat, dus de ontvanger moet verplicht op pin 2 aangesloten worden.

volatile unsigned long timer; // all timer variables are unsigned long
volatile int inpulse =  1500;
volatile byte sync = 0;
int mpcount, pulse;
int Xtarget [8], Xpulse[8];
const int slowstep = 1;
const int Xtargetlow [] = {83, 83, 83, 83, 205, 205, 205, 205};
const int Xtargethigh [] = {467, 467, 467, 467, 410, 410, 410, 410};
bool start = false, RxchWas = false;

#include <Wire.h>
#include <Adafruit_PWMServoDriver.h>

// called this way, it uses the default address 0x40
Adafruit_PWMServoDriver pwm = Adafruit_PWMServoDriver();

void setup() {
 
  attachInterrupt(0, read_pwm, CHANGE); // Pin 2 = interrupt 0
  pinMode(2, INPUT);
 
  Serial.begin(9600);
 
  pwm.begin();

  pwm.setOscillatorFrequency(27000000);
  pwm.setPWMFreq(50); // 50Hz, frame length 20 millis

  for (int i=0; i<8; i++) {
    Xtarget [i] = 308; // equivalent of 1500 micros
    Xpulse [i] = 308;
  }

  delay(10);
}

void loop() {
 
  while (sync == 0); // ISR sets sync to true when reading Rx pulse is complete, loop starts.
  sync = 0; // stops loop after one run.
 
  delay (6); // do an atomic copy, delayed to midframe to reduce jitter
  cli();
  pulse = inpulse;
  sei();
 
  // read next 8 incoming pulses, triggered by a syncpulse, map to extended range and save in array Xtarget []
 
  if (start && pulse >=1000) {
    Xtarget [mpcount] = map (pulse, 1030, 1980, Xtargetlow [mpcount], Xtargethigh [mpcount]); // extending pulse to Xtarget

    mpcount += 1;
    if (mpcount >7) {
      start = false; // stop saving subchannels after 8 counts
      delay(500); // only for testing the output by monitor, deactivate for servo operation
    }
  }
 
  if (pulse >= 850 && pulse <950) { // is syncpulse
    start = true;
    mpcount = 0;
  }

  // update all servo outputs with or without changed targets, maximum step is slowstep setting
 
  for (uint8_t j=0; j<8; j++) {
    if (Xtarget [j] - Xpulse [j] >= slowstep) Xpulse [j] += slowstep;
    else if (Xtarget [j] - Xpulse [j] <= -slowstep) Xpulse [j] -= slowstep;
    else Xpulse [j] = Xtarget [j];
    pwm.setPWM(j, 0, Xpulse [j]); // LOW>HIGH at 0, HIGH>LOW at pulselen
  }

}

void read_pwm(){
  if (RxchWas == 0) { // if pin 2 was false previously
    timer = micros(); // start timer
    RxchWas = 1;
  }
  else if (RxchWas == 1) { // if pin 2 was already true, read timer
    inpulse = ((volatile int)micros() - timer);
    RxchWas = 0;
    sync = 1; // start loop
 
  }
}

 

[Ernst Grundmann]

De echte Arduiuno uno gebruikt ongeveer 30mA plus de stroom die elke uitgang levert. Dat kan een 9V batterij redelijk makkelijk leveren. De capaciteit van een 9V alkaline batterij is ongeveer 500 á 600mAh. bij 30mA zou je in theorie tot 20 uur stroom kunnen leveren, in de praktijk is dat meestal minder.

 

[max z]

Hier dan toch maar de ongeteste code.

Ik zie dat de delay(500) er nog inzit, die was bedoeld om eventueel zaken te controleren met de seriële monitor. Voor het testen met servo's kun je dat beter weghalen of deactiveren.

 

[Herby63]

zijn de blauwe servo's de versie waar we in post #21 over spraken, met de geadverteerde weg van 270 graden bij pulslengtes van 520 - 2350?

inderdaad

Je kunt proberen op de plug aansluiting bijvoorbeeld een 9V batterij aan te sluiten, of een 2s lipo.

Test ik morgen uit, ik blijf voorlopig zo ver mogelijk van al wat met Li- is (lipo, lifepo, enz.), maar ik heb nog een bruikbare NiMh batterij van 7,2V liggen, proberen waard.
Normaal moet uiteindelijk alles op de 6V loodbatterij van de Bismarck, maar mogelijks, als het totaalgewicht het toelaat neem ik een afzonderlijke accu voor de elektronica.

De 9V batterij was al uit bedrijf Ernst,

Ik denk dat ik het weet, die 9V batterij kan de (piek)stromen niet leveren.

Als ik het goed geïnterpreteerd heb heeft de oplaadbare 9V accu een capaciteit van MAAR 150 mAh. dus dat zou de reden kunnen zijn van de korte gebruiksduur, immers daar zat op de foto's dus het volledige afgebeelde systeem op, van zodra ik de Arduino van de navelstreng (USB-kabel naar PC ) gehaald heb.

als je hier de 1030 in de map() functie bedoeld ...

OK, maar dat zou dus geen probleem mogen geven.

kennelijk heeft de extender die je hier gebruikt dus een begrenzing op de toegestane pulslengte, buiten die grens blijft de output constant.

inderdaad, maar de gewenste uitslag wordt toch benaderd.

Ik stelde daarom voor om een aparte bron aan te bieden via de ingebouwde spanningsregelaar, en dat mag volgens mij best een 9V batterij zijn, want zoveel stroom trekt een UNO niet denk ik.

Wordt morgen getest.

Ik heb een versie klaarstaan daarvoor, ...

Wordt morgen uitvoerig getest

Ik zie dat de delay(500) er nog inzit,

Ik heb in de vorige code er // voor gezet, voor als ik die vlug wil heractiveren als het systeem onstabiel is. Dat ga ik met de nieuwe code dus ook doen, maak je geen zorgen

Ik stelde daarom voor om een aparte bron aan te bieden via de ingebouwde spanningsregelaar, en dat mag volgens mij best een 9V batterij zijn,

Daar was ik dus niet zeker over hoeveel V je op die aansluiting mag zetten, maar je stelt me ook hier weer gerust.

 

[max z]

Nog even over die delay(500): tot nu toe werd de informatie naar de servo's bij iedere wijziging van de ontvangerpuls geüpdatet , al dan niet met een groter bereik.
Nu wordt de verandering beperkt tot 2 microseconden (of zoals bepaald door de slowstep variabele) per keer dat de loop draait. De loop volgt de timing van de binnenkomende pulsen, dus ongeveer 50Hz ofwel om de 20 milliseconden, en de stappen die de servo maximaal maakt is daarop gebaseerd, dus ong. 50x2 = 100 stappen per seconde.
Als je echter een extra vertraging van 500 milliseconden in de loop zet, wordt het dus 2 stappen per 520 milliseconden, dus nog geen 2 stappen per seconde.
Een aanzienlijke invloed op de vertraging dus, op zichzelf geen probleem, maar iets dat je zou kunnen verrassen bij het testen.

 

[Herby63]

@max z
De mysteries van de elektronica zijn ondoorgrondelijk.
Ik heb je laatste code opgeladen, delay(500) uitgeschakeld, (er staat trouwens geen printopdracht in de code);
Na een eerste test heb ik voor alle volgende wel de slowstep op 1 gezet en de waarden van xtargetlow en xtargethigh omgewisseld zodat de servo's zo traag mogelijk en in de richting die overeenkomt met de potverdraaiing bewegen.
proefopstelling zonder bijkomende elementen;
servo's en ontvanger aan de externe gestabiliseerde voeding;
Arduino aan de navelstreng;
Systeem is niet stabiel te krijgen, eerst gaan alle servo's naar de neutraalstand (volgens opdracht in Xtarget = 1500; Xpulse = 1500; denk ik)
Daarna gaan ze allen een eigen leven leiden op een gezapig heen en weer bewegend ritme, en de meeste servo's reageren niet op de verdraaiing van de pots.

Ten ende raad, en totaal losstaand van het voorgaande ging ik op zoek in de doos met oude laders en aansluitkabels naar een aansluitplug voor de stroomvoorziening die ik later zou kunnen gebruiken in het schip. Kwestie van even de gedachten te verzetten.
Ik vond een lader/voeding van een oude barrerijlader, die als output 12V 0,5Ah geeft, en die de passende plug heeft.
Toen ik deze inplugde, en de stroom voor de Arduino ook hiermee verbond (via de Breadboard 5V) werd alles plots stabiel.
Servo's gaan naar de neutraalstand, en bewegen vervolgens elk afzonderlijk volgens de stand van de overeenkomstige pot.
Ze staan eenmaal de gevraagde positie bereikt, ook mooi stil.
De traveltijd van volledig naar de ene kant naar volledig naar de andere kant is ongeveer 38 seconden. Ook dat is mooi.
Enige minpunt, is dat de beweging schokkerig verloopt.

Het systeem staat hier nu al enkele minuten stil, terwijl ik dit typ, en er is geen enkele onverwachte beweging.
Als ik nu de 8 pots verdraai, gaan de 8 servo's op hun gezapige tempo, zij het in schokjes, hun nieuwe positie in gaan nemen.

De laatste configuratie heb ik herhaald met slowstep = 2.
Arduino aan de navelstreng om code op te laden, weer gaan de servo's hun eigen leven leiden nadat ze eerst in de neutraalstand zijn gaan staan.
USB-kabel verwijderd en 5Vin verbonden met de breadboard, en op het schakelaartje van de Arduino gedrukt om code te resetten, en alles werkt weer normaal, de traveltijd is nu ongeveer 19seconden.

 

[max z]

Ik vond een lader/voeding van een oude barrerijlader, die als output 12V 0,5Ah geeft, en die de passende plug heeft.
Toen ik deze inplugde, en de stroom voor de Arduino ook hiermee verbond (via de Breadboard 5V) werd alles plots stabiel.

Op zich een hoopgevend resultaat, toch?

Ik kan niet helemaal volgen hoe je e.e.a. aangesloten hebt. Het zou zó moeten zijn:
- 12V met plug aansluiten aan de UNO ( of voeding via de USB, maar niet allebei tegelijk)
- 5V aansluiten op het breadboard om de servo's te voeden
- GND van UNO en breadboard verbinden
- 5V van de UNO NIET met het breadboard verbinden. De UNO heeft de GND van het breadboard alleen nodig om een referentie voor de servo-output te hebben, en de voedingsspanning van UNO en servo's blijft gescheiden.

Wat betreft het schokkerig gedrag, ik ben bang dat daar niet veel aan te verbeteren valt, dat ligt hoogstwaarschijnlijk aan het oplossend vermogen van de servo-electronica. Misschien dat een digitale servo daar verbetering in kan brengen, maar daar heb ik geen ervaring mee. Bovendien ben je op zoek naar een servo met meer dan het normale bereik. Er zijn voor zover ik weet ook programmeerbare digitale servo's op de markt die dat wel kunnen, maar dat wordt waarschijnlijk diep in de buidel tasten.

 

[Herby63]

Het zou zó moeten zijn:

Zo is het ook ongeveer, als ik de code wil updaten verwijder ik de 5V aansluiting tussen UNO en breadboard, en sluit ik de USB-kabel aan,
Daarna verwijder ik de USB-kabel, steek de 5V weer in en de 12V powersupply zit in de module die je rechts in de breadboard ziet zitten op de foto's in post 102, dus i.p.v. die 9V accu. Dus nooit allebei tegelijk.
Gnd van UNO is inderdaad met de breadboardmin verbonden.

Op zich een hoopgevend resultaat, toch

Inderdaad
Aanvullende tests volgen met externe servotravelextender , ik kan al verklappen dat met 1 exemplaar tussen UNO en servo 4 de reisweg verder gaat, maar de servo zich van onze inspanningen om reisweg en travelspeed via de UNO te regelen niets aantrekt, of het bereik nu op 650-2350 of op 1000-2000 staat, het resultaat blijft hetzelfde, zoals ik gisteren al meldde, en de travelspeed is gereduceerd tot 15 seconden voor een volledige uitslag ipv 19 sec op slowstep2 of 38 seconden op slowstep1. De beweging is wel veel "smoother"
Straks eens proberen met 4 travel extenders, of het systeem nog stabiel blijft, want eerder had ik daar een probleempje mee.

 

[max z]

DEZE zien er qua specificatie interessant uit. Gemaakt voor Lego Technic, en toevallig heb ik daar een paar onderdeeltjes van zodat ik de afmetingen goed kan inschatten.
L/B/H 40/25/17 mm. Wel groter als jouw blauwe servo's schat ik, ik weet niet of je zoiets in de boot kwijt kan. Aandrijving via een as met kruisvormige doorsnede.

 

[max z]

als ik de code wil updaten verwijder ik de 5V aansluiting tussen UNO en breadboard,

Maar dat betekend dus dat je de servo's èn de UNO via de 5V voedt. Dat is op zich geen probleem, maar beter is het om de UNO apart via z'n eigen spanningsregelaar met een spanning ergens tussen 7V en 20V te voeden via de ronde plug-aansluiting.

Alhoewel je dat min of meer al doet met de USB (al is het dan met 5V voeding, maar in ieder geval apart van de servo's), en juist dan krijg je problemen.....blijft de GND verbinding wel steeds intact?

Gelukkig helpt dus het aansluiten van de UNO op 5V ( een reset zou dan niet nodig hoeven zijn) .

 

[Herby63]

en juist dan krijg je problemen.

inderdaad, bizar hé?

blijft de GND verbinding wel steeds intact?

jazeker

een reset zou dan niet nodig hoeven zijn

klopt, maar het kan geen kwaad en verzekert me ervan dat de cyclus van in het begin met set-up en al doorlopen wordt.

 

[Herby63]

Zoals beloofd heb ik de proefopstelling getest met meerdere externe travelextenders.
Zonder werkt de code uit post 108 perfect en blijft stabiel, ook bij de tests vandaag.
Met 1 travelextender werkt het ook stabiel, op kanaal 5, 6 of 7, maar niet op het laatste kanaal (8)
Met 2, 3 of 4 travelextenders is het niet stabiel, en draaien alle servo's volgens hun eigen willetje.
Ook een test met 1 travelextender waaraan 2 servo's met een Y-kabel verbonden, zijn was niet stabiel.

Zonder travelextenders haalt de code met doorgegeven puls van 650 tot 2350 maar 125° in elke richting, wat ik een beetje weinig vind (in theorie zou een pulslengtevariatie van 850 een beweging van 153° moeten geven), en de beweging is schokkerig.
Met travelextender haalt de aangesloten servo ongeveer 135° in elke richting, waar ik mee kan leven, de beweging is iets sneller dan zonder travelextender, en niet meer schokkerig.
Meer dan 1 servo hiermee uitrusten is echter niet mogelijk (zie testresultaat hierboven).

De huidige opstelling neemt bovendien 8 uitgangen van de Uno in beslag.
Ik heb een module aangeschaft die toelaat tot 16 servo's aan te sturen, met maar 2 verbindingen naar de Uno, namelijk de Adafruit PCA9685.

Blijkbaar kan je in de code ook de draaisnelheid en draaihoek instellen van elke servo afzonderlijk.
Ik zie echter niet hoe ik de uitgelezen code kan integreren in de code om deze aan te sturen.

Hulp is dus weer eens meer dan welkom.

 

[Ernst Grundmann]

Gek dat ik er niet eerder aan heb gedacht maar "vroeger" was de standaard methode om bij een gewone servo de slag te vergroten een weerstand opnemen in de beide buitenste aansluitingen van de potmeter in de servo of er instelpotmetertjes tussen solderen. Het probleem is alleen, dat bij de meeste servo's tegenwoordig de potmeter vast is gesoldeerd op de print. Daarnaast moet je vaak experimenteren met de weerstandswaarden om aan de gewenste uitslag te komen. Een goede beginwaarde is 1 kiloOhm (voor beide weerstanden).