Stuurtechniek (electronica)

[MJM]

Iemand andere suggesties?

Robot bouwen en rijden. Daar leer je van en merk je of er gevoelige elektronische gadgets nodig zijn. Ervaring: een fantastische gyro is in gevechtssituaties onbetrouwbaar en niets is zo flexibel als een mens; ik heb robots met aandrijving aan maar 1 zijde toch "rechtuit" door de arena zien rijden en overleven. Een stukje elektronica ertussen en het zou over en uit zijn.

[WJ]

hehe, met feedback zou ik tegen tornado helemaal nergens meer geweest zijn met die 2 lekke banden en in de banden ronddraaiende velgen, dus idd. hoe minder electronische snufjes hoe beter. Daarom stuur een kart bijvoorbeeld ook zo fijn

[peter]

MJM schreef:

Een stukje elektronica ertussen en het zou over en uit zijn

WJ schreef:

met feedback zou ik tegen tornado helemaal nergens meer geweest zijn

Ik wil graag leren dus, waarom zou extra elektronica niet werken? Waarom, "hoe minder electronische snufjes hoe beter"?

Peter

[WJ]

Als je electronica probeert te compenseren terwijl je electronica niet weet dat een motor stuk is, een wiel aanloopt of wat dan ook, dan werkt dat niet. En als het allemaal zo lo tech mogelijk is kun jij met je rijstijl compenseren.

[KASAP]

MJM schreef:

Een stukje elektronica ertussen en het zou over en uit zijn

WJ schreef:

met feedback zou ik tegen tornado helemaal nergens meer geweest zijn

Ik wil graag leren dus, waarom zou extra elektronica niet werken? Waarom, "hoe minder electronische snufjes hoe beter"?

Peter

Alles dat er niet in zit gaat ook niet stuk. Klinkt wat flauw, werkt wel zo te zien.
En idd wat WJ zegt, je electronica reageert op een van te voren ingestelde verwachting, en die is meestal dat alles werkt. Je programeert je spullen niet zo dat ze goed werken als er bepaalde andere delen stuk zijn.

[leo-rcc]

Daarbij komen we dus op het andere topic: Keep it simple.

Hoe meer basic je ontwerp, hoe minder er fout kan gaan. Dat geld zeker ook voor je electronica.

[Bugs]

Da's natuurlijk voor een deel onzin. Er zijn tegenwoordig prima systemen die een uigevallen motor beter kunnen compenseren als jij kan met je kunppeltje.
Daarbij is het eenvoudig om het regelsysteem met een schakelaartje uit te zetten. Dan blijft nog het argument over van alles wat je toe voegt stuk kan. Op zich kan je alles in de interface proppen, dus gaat die argumentatie ook niet op. Je moet echter wel extra sensoren toe voegen en dat kan natuurlijk wel stuk. Hopelijk heb ik zo rond Juni de boel uitgewerkt in de vorm van nieuwe hardare voor TAN Voordat de software volledig uitgekristaliseerd is zijn we wat verder, maar ik denk dat het tegen de tijd van de WK behoorlijk zal werken.
Ohjah.. en ook hier geld, de juiste materialen zijn alles. Dus ik heb een gyro geregeld die tot 2000G aan klappen kan opvangen. Da's wel andere koek vergeleken met de gemiddelde helicopter gyro.

[maddox]

Bugs, je vergeet wel effe te vermelden dat jouw interface idee ook een manier behelst om de hele boel uit te schakelen en op een basisstand zonder foefjes en snufjes verder te gaan.Net om te vermijden dat dat ene losse draadje de machine feilloos de put in gaat rijden.

[peter]

WJ schreef:"Als je electronica probeert te compenseren terwijl je electronica niet weet dat een motor stuk is, een wiel aanloopt of wat dan ook, dan werkt dat niet."
Waarom niet? Als je electronica merkt dat bij aansturen van je linker motor je robot links niet genoeg beweegt wordt de linker motor harder aangestuurd. Dat werkt dan toch? Zo compenseer je dat zelf toch ook?

Ik probeer niet in een nietes-welles spelletje te komen want wat KASAP schrijft is waar:"Je programeert je spullen niet zo dat ze goed werken als er bepaalde andere delen stuk zijn."
Nee, je programmeert je spullen zo dat ze goed werken onder zo veel mogelijk omstandigheden (dus ook als onderdelen uitvallen). Ik probeer nu zoveel mogelijk achter die andere omstandigheden te komen of om iemand aan te citeren: "beter nu geleerd, dan in de wars gecrepeerd"

Zo is een knopje om terug te schakelen naar tankbesturing geen slechte optie.

Peter

[docproc]

Zo is een knopje om terug te schakelen naar tankbesturing geen slechte optie.

Nog beter is gewoon iets ontwerpen dat niet kapot gaat KISS gaat helemaal bij RobotWars op, Keep It Simple Stupid. Dat kun je tenminste makkelijk testen en dan weet je waar de problemen zitten en kun je die oplossen. Complexe systemen kun je nooit volledig testen en dat is vragen om problemen.

Daarbij is het eenvoudig om het regelsysteem met een schakelaartje uit te zetten. Dan blijft nog het argument over van alles wat je toe voegt stuk kan. Op zich kan je alles in de interface proppen, dus gaat die argumentatie ook niet op. Je moet echter wel extra sensoren toe voegen en dat kan natuurlijk wel stuk.

Hoe meer je in je interfaceje stopt, hoe groter de kans is dat de software op z'n bek gaat. Dan heb je ook niets meer aan je schakelaartje die de software omzeilt, omdat je interface gewoon simpelweg niet meer reageert. (tuurlijk snap ik dat je dit met bv een watchdog kunt omzeilen).

Als je al die foefjes wilt gaan gebruiken moet je volgens mij echt erg modulair gaan werken waarbij er een soort van supervisor module is die controleert of alles binnen het te verwachten patroon werkt.

[peter]

Nog beter is gewoon iets ontwerpen dat niet kapot gaat

Dat is een fout uitgangspunt (zie Murphy). Overigens, "This is robotwars!" dan moet het kapot

hoe groter de kans is dat de software op z'n bek gaat

Je moet het wel goed doen natuurlijk en hoe complex je dit vindt hangt af van wat je gewend bent.

Peter

[docproc]

hoe groter de kans is dat de software op z'n bek gaat

Je moet het wel goed doen natuurlijk en hoe complex je dit vindt hangt af van wat je gewend bent.

Ik vind het alleen maar mooi als je het allemaal voor elkaar krijgt, maar het is geen goed uitgangspunt om mechanische tekortkomingen op proberen te lossen via software/elektronica. Tenzij er natuurlijk al alles aan is gedaan om de mechanische tekortkomingen op te lossen door het mechanische ontwerp te verbeteren, ik weet niet in hoeverre dit het geval is.

Bijvoorbeeld:

- traction control: kijk eerst eens of je de grip kunt verbeteren door bv ander rubber te gebruiken, grotere wielen, 4WD etc.
- gyro: wijkt de robot van een rechte lijn af? Kijk eerst eens naar het verschil tussen de twee aandrijfhelften, wielen die niet helemaal gelijk zijn, een motor die net iets minder presteert dan de ander etc.

Dit zijn slechts opmerkingen in het algemeen, niet op deze discussie specifiek. Kan iemand dit lijstje nog aanvullen?

[Bugs]

Het kan een voordeel zijn om een instabiele robot te bouwen die je met wat electronica stabiliseerd. Kijk maar naar de gemiddelde straaljager van tegnewoordig. Die zijn niet meer te besturen zonder computer, maar met computer erbij zijn ze super wendbaar.
Alleen al omdat er een aantal mensen niet aan druven is het een goede rede om het juist te proberen. Als je het goed voor elkaar hebt dan krijg je weer een voorsprong op je tegenstander. Overigens hebben gyro's zich al lang bewezen in Robotwars. Menig robot kan niet recht rijden zonder. Dat is geen fout in de aandrijving of iets dergelijks, dat zit in het ontwerp van de robot en de gewichts verdeling. Die zijn meestal niet meer aan te passen nadat de robot gebouwd is

[leo-rcc]

Ik ken echter ook diverse roboteers die de gyro er weer zo snel mogelijk uit gehaald hebben.

[Team Twister]

Ik denk ook dat een gyro teveel last heeft van de impacts en andere vibraties. Een beter systeem zou zijn met een encoder op de as van de wielen en dan ook nog voor de vertraging.

Roboteq heeft nu een encoder module op de markt voor hun controller.

Op die manier krijf je een soort servo motor. En zou je theoretisch dus een perfekt sturende robot moeten hebben.

Weet alleen niet ( nog) hoe hij reageren gaat als een encoder signal wegvalt.

Sjaak