Interessanter Beitrag!
So etwas ähnliches hätte ich mir auch schon einmal ausgedacht, aber wieder verworfen, weil ich keine technische Lösung dafür fand. Wäre im Prinzip so gewesen, dass sich der Bot bei der Rotation die gesuchte Fahrtrichtung detektiert und dann auf beiden Rädern eine "Vorwärtsfahrt" (bzw. die gesuchte Richtung) zur Drehbewegung überlagert. Allerdings hatte ich keine Idee, wie ich feststellen kann, dass der Bot just in diesem Moment an der passenden Position ist.
Leider verstehe ich die englischen/amerikanischen Erläuterungen von den o.g. Videobeitrag nicht. So wie ich es interpretiere, synchronisiert er mit dem linken Kreuzknüppel die Drehgeschwindigkeit an eine vorgegebene Pulsausgabe der LEDs. Wenn dieser "Takt" der LEDs mit der Drehgeschwindigkeit übereinstimmt, dann ist der Fahrtregler "abgeglichen". Jede Bewegung des Fahr-Kreuzknüppels führt dann zu der gewünschten Überlagerung der Drehbewegung und der Fahrt.
"Automatisiert" wird das nicht zu machen sein, denn die Drehgeschwindigkeit ist abhängig vom Akkuzustand und dem Bodenbelag. Also muss ständig manuell mit dem linken Kreuzknüppel die Geschwindigkeit nachgeregelt werden. Das war zumindest mein erster Eindruck. Aber: ...
Auf der Homepage ist in der Stückliste ein Beschleunigungssensor aufgelistet. Hm... wie wird der eingesetzt? Wird damit vielleicht versucht, die Drehgeschwindigkeit beizubehalten, wenn das System beim Start "einkalibriert" ist? Das würde dann das manuelle Nachführen der Drehgeschwindigkeit erübrigen.
Die Lösung wäre also ein "Beschleunigungs-Sensor"?
Bleibt zum Entwickeln dieses Fahrtregler-Features nur ein Problem: Zeit .... 
Wow! Das ist ziemlich cool!
Im Wikipedia ist eine Basiserläuterung von so einem Accelerometer.
http://de.wikipedia.org/wiki/Accelerometer
Hab' bei RS-Components einen Beschleunigungssensor gefunden.
http://de.rs-online.com/web/p/beschleu…en-ics/7098439/
Hier das Datenblatt: http://docs-europe.electrocomponents.com/webdocs/0e48/0900766b80e4845a.pdf
Großes Problem: Der Chip hat keine seitlich vorstehenden Pins/Pads zum Verlöten, sondern muss wie bei der Ballgrid-Montage auf "Zinnkügelchen" aufgesetzt und dann im Reflow-Ofen gelötet werden. *Bääääh*
Reiner, mit 8g-Sensoren kommt man bei 800 bis 2000 Umdrehungen pro Minute aber nicht weit...
Sowas http://www.watterott.com/de/Breakout-Board-ADXL193 passt da schon besser...
Beschleunigung a = r * w²
r = 0.05m
n = 1000 1/min = 16,67 1/s
w = 2 * Pi * n = 104,7 1/s
a = 0,05m * (104,7 1/s)² = 548,3 m/s² (ca. 55,9g)
der ADXL001 (70g) von Analog sollte auch gehen, wenn er um 45° geneigt montiert wird...
EDIT:
Nur mal so am Rande, weil er so schön ist:
http://www.robowars.org/forum/viewtopic.php?t=1768
nochmal EDIT:
Auf der Homepage ist in der Stückliste ein Beschleunigungssensor aufgelistet. Hm... wie wird der eingesetzt? Wird damit vielleicht versucht, die Drehgeschwindigkeit beizubehalten
Die "Drehgeschwindigkeit" wird mit dem Gasknüppel (linker Knüppel im Video) vorgegeben.
Wie groß die ist ist für das System erstmal unerheblich, Sie muss nur bekannt sein, um die Motoren an den richtigen Punkten Anzusteuern.
Da man die "Drehgeschwindigkeit" nicht so einfach messen kann (Gyro würde gehen, teurer Chip von Analog) wird bei "Melty Brain" der Umweg über die Messung der Zentrifugalbeschleunigung und die Umrechnung in die "Drehgeschwindigkeit" gegangen.
Ok,... überredet 
Ich dachte eigentlich, dass die umschaltbare Maximalgrenze zwischen 2g, 4g, 8g und 16g diesen Sensor für jede "Drehzahl" des Bots flexibel macht.
1000 U/min sind zwar nach meiner Meinung sehr hoch gegriffen, denn das Ding wird nicht mehr beherrschbar sein, auch wenn es noch so gut gewuchtet bzw. die Innenteile optimal platziert wurden. (?)
//EDit...
Die "Drehgeschwindigkeit" wird mit dem Gasknüppel (linker Knüppel im Video) vorgegeben.
Wie groß die ist ist für das System erstmal unerheblich, Sie muss nur bekannt sein, um die Motoren an den richtigen Punkten Anzusteuern.
Da man die "Drehgeschwindigkeit" nicht so einfach messen kann (Gyro würde gehen, teurer Chip von Analog) wird bei "Melty Brain" der Umweg über die Messung der Zentrifugalbeschleunigung und die Umrechnung in die "Drehgeschwindigkeit" gegangen.
Wie gesagt, ich verstehe die verbalen Erläuterungen nicht, aber ich hab's so interpretiert:
a)
Der "Takt" für die Vorwärtsausrichtung ist durch die blinkende blaue LED vorgegeben. In dem schmalen Zeitfenster, bei dem die LED aufleuchtet, ist "Vorwärtsfahrt" möglich. Die Kommandos von dem rechten Knüppel werden auf die beiden Motoren aufaddiert.
b)
Jetzt geht's darum, eine Rotation zu erzeugen, bei der der Bot weis, wann "vorwärts" ist. Das wird nach dem Stroboskop-Prinzip gemacht. Also die Drehzahl des Bots (=um die eigenen Achse rotieren) so lange erhöhen, bis das Aufleuchten der blauen LED immer nur an einer Stelle erfolgt. Das ergibt dann das blaue Leuchtband an der Frontseite. Wenn die Drehzahl nicht stimmt (zu schnell oder zu langsam), dann leuchtet die blaue LED immer an einer anderen Position auf. Also gibt das (rein optisch) einen blauen Ring um den Bot.
c)
Wenn mit dem linken Kreuzknüppel die Drehzahl so eingestellt ist, dass "sie passt" (=blaues Leuchtsegment an der Frontseite des Bots), dann muss diese Drehzahl konstant gehalten werden. Dafür ist dann der Beschleunigungssensor da. Wenn die Drehzahl abfällt (z.B. Akkuspannung bricht ein bißchen ein), dann wird die Rotationsgeschwindigkeit automatisch wieder erhöht.
Mit den Begriffen hadere ich noch. Es ist ein "Beschleunigungssensor". Aber eigentlich wird damit eine konstante Kraft (Zentripedalkraft am Chassis des Bot) gehalten. Beschleunigung ist für mich immer eine Änderung von einer Geschwindigkeit. Muss aber bei dem Sensor bzw. Bot trotzdem richtig sein, denn bei der berühmten Zentrifuge, bei der Menschen mit dem Rücken nach aussen wie in einem Karrussel gedreht werden, haben auch immer die Angabe "in g".
8g und 16g
Ups... die 16g hatte ich überlesen... (sind aber trotzdem zu wenig *grins*)
Hier: http://www.spambutcher.com/meltyb.html
werden Drehzahlen von 800 bis 1600 1/min angegeben...
Original von UnskilledWorker
Ups... die 16g hatte ich überlesen... (sind aber trotzdem zu wenig *grins*)Hier: http://www.spambutcher.com/meltyb.html
werden Drehzahlen von 800 bis 1600 1/min angegeben...
Er gibt hier auch 1000 bis 1200 U/min an. Möglich sind 1600 U/min (throttle).
Seltsamerweise hat er einen Sensor verbaut, der ±18g kann. (Siehe Screenshot).
Vermutung: Der Sensor ist nicht möglichst weit an der Aussenseite verbaut, sondern "zentrumsnah".
Vermutung: Der Sensor ist nicht möglichst weit an der Aussenseite verbaut, sondern "zentrumsnah".
Ich würde auf "zentrumnah" und "geneigt" tippen.
Wenn der Sensor z.B. um 45° geneigt wird, reduziert sich die Beschleunigung, die der Sensor auf seiner Mess-Achse sieht um 50%...
Wow, das ist mal ein interessantes Konzept!!
Ich hab mir das genauso wie Reiner gedacht:
Die LED ist quasi der Sollwertgeber. Dann wird mit dem rechten Knüppel die Drehzahl solange eingestellt, bis der Bot auf diese Solldrehzahl eingestellt ist.
Mit dem linken Knüppel wird dann quasi normal gefahren...
Echt nettes Konzept. Würde ich auch am liebsten gleich mal abchecken... aber die Zeit... 
Nimm er nicht einfach diesen Kollegen: https://www.sparkfun.com/products/9332
?
Der kann doch seine 250g
Auszuwerten ist der anscheinend ja auch ganz einfach per Analog-Ausgang.
Edit:
Ich spiele grade mit dem Gedanken, das mal mit meinen Orange-Ant-FR in Ant-maß zu testen.
Bedarf ja eigendlich nicht soo viel.
Wenn der Sensor z.B. um 45° geneigt wird, reduziert sich die Beschleunigung, die der Sensor auf seiner Mess-Achse sieht um 50%...
Ja, wäre ein guter "Trick", um eine Übersteuerung des Sensors zu verhindern.
Was mich dabei für die Entwicklungsphase stört: Man kann das alles sehr schlecht nachmessen und debuggen. Denn bei einem rotierendem Bot von einem Multimeter die Meßspitzen aufsetzen, dafür ist man nicht schnell genug... => Irgendwie würde ich schon gerne wissen, welche Spannung der Sensor gerade ausspuckt.
Ich versuche jetzt mal zu beschreiben, wie ich mir das System denke, bzw wie ich es realisieren würde (Denkfehler nicht ausgeschlossen!!!!!!)
Nehmen wir einen einfachen "Test-Bot": Zwei Motoren mit Rädern (ohne Getriebe) auf einer Holzlatte befestigt.
Der Massenschwerpunkt soll jetzt einfach mal genau in der Mitte zwischen den Motoren auf der Holzlatte liegen.
Die Motoren drehen mit einer Geschwindigkeit die dazu führt, dass der gesamte Bot sich mit 600 1/min (also 10 Umdrehungen pro Sekunde) entgegen dem Uhrzeigersinn dreht.
Jetzt stellen wir uns eine Uhr vor, bei der die 12 oben liegt.
Wenn ich den Motor, der gerade bei 4Uhr ist von 4 bis 2Uhr "etwas" beschleunige und gleichzeitig den Motor der gerade bei 10Uhr ist von 10 bis 8Uhr "etwas" abbremse,
wird sich der Massenschwerpunkt (Mitte der Holzlatte) bei jeder Umdrehung "etwas" in Richtung 12Uhr bewegen.
Das Problem ist nun, die Zeitpunkte zu bestimmen, an denen die Motoren bei 4Uhr und 10Uhr und bei 2Uhr und 8Uhr sind.
Als externer Beobachter könnte ich (wenn meine Augen, mein Hirn und meine Finger schnell genug sind *grins*) bei jeder Umdrehung an den oben genannten Punkten zweimal kurz einen Taster drücken.
Der Bot würde sich dann in Richtung 12uhr bewegen.
Leider muss der Bot diese Punkte aber selber bestimmen.
Fangen wir mit der Umdrehungsgeschwindigkeit des Bots an. Diese könnte aus der Drehzahl der Motoren abgeleitet werden. Da man ein Durchrutschen der Motoren aber nicht ausschließen kann, wäre diese Drehzahl wohl sehr ungenau!
Der Beschleunigungssensor misst nun die Zentrifugalbeschleunigung. Damit kann man die Drehzahl n berechnen.
wenn n z.b. n = 600 1/min = 10 1/s ist, dann dauert eine Umdrehung T = 100ms.
n und T kennt der µC jetzt und macht folgendes: LED für 25ms (T/4) an, dann für 75ms(T*3/4) aus. Damit ist die LED für 90° einer Umdrehung an. Das 90°-Segment "LED-AN" liegt IMMER AN DER GLEICHEN STELLE auf einer gedachten Uhr, nur WO dieses Segment liegt ist erstmal unbestimmt, da es von dem Zeitpunkt abhängt, an dem der µC das erste mal die LED angemacht hat.
Wenn die Umdrehungsgeschwindigkeit etwas falsch ermittelt wird, so wird das "LED-AN" Segment anfangen sich zu bewegen (das ergibt den leuchtenden Kreis). Mann muss also die Möglichkeit haben, die tatsächliche Drehzahl mit der gemessenen Drehzahl abzugleichen bis das 90°-Segment "LED-AN" an einem Punkt stehen bleibt! (Schritt 1 der "Kalibrierung")
Ist dies geschehen, kann ich die Drehzahl ändern, das leuchtende Segment bleibt dann immer an der gleichen Stelle!!!
Natürlich wird hier vorausgesetzt, dass die aktuelle Drehzahl über den Beschleunigungssensor kontinuierlich gemessen und entsprechend oft das T angepasst wird!
Jetzt besteht noch folgendes Problem: Das LED-AN-Segment steht z.B. gerade konstant bei 7Uhr. Ich möchte in Richtung 12Uhr fahren. Als externer Beobachter kann ich mir einfach eine uhr vorstellen, bei der die 12 oben ist und dann die aktuelle 7Uhr ablesen.
Der µC kann das so erstmal nicht, da er auf dem sich drehenden System sitzt und keinen festen Bezugspunkt zur gedachten Uhr des externen Beobachters hat.
Wenn ich jetzt aber den Start von "LED-AN" so verschiebe, dass "LED-AN" auf der gedachten Uhr auf 12Uhr liegt, ist die Uhr des rotierenden Systems mit der Uhr des externen Beobachters synchronisiert. (Schritt 2 der "Kalibrierung")
Die 12 der Uhr ist (für den Beobachter UND den BOT) so immer da, wo das leuchtende Segment ist.
Dabei ist es egal, wie schnell der Bot gerade dreht!!!
Mit dem linken Knüppel (Gas) kann ich jetzt die Drehzahl vorgeben. Mit dem rechten Knüppel (Vor-Rück + Links-Rechts) kann ich die Richtung auf der synchronisierten Uhr vorgeben. Knüppel z.B. nach rechts = 3Uhr, nach unten 6Uhr.
Damit kann der µC die Motoren an den richtigen Zeitpunkten ansteuern. Je mehr ich den rechten Kreuzknüppel aus der Mitte bewege, desto mehr steuert der µC in diese Richtung. z.B.Knüppel etwas nach rechts -> Bot bewegt sich langsam Richtung 3Uhr, Knüppel ganz rechts -> Bot bewegt sich schnell Richtung 3Uhr.
Ist das verständlich??? Findet jemand einen Denkfehler??? ;-)))
Natürlich wird hier vorausgesetzt, dass die aktuelle Drehzahl über den Beschleunigungssensor kontinuierlich gemessen und entsprechend oft das T angepasst wird!
Ich denke, ich hab' verstanden, wie Du das lösen würdest. Du berechnest anhand eines "gemessenen" Signals die Drehzahl neu und stellst dann das Puls-/Pauseverhältnis der LED nach.
Ich hätte es anders probiert: Das Puls-/Pauseverhältnis der LED ist immer gleich. Nur wenn die LED an ist, wird das gewünschte Fahrsignal auf die Motoren mit hinzuaddiert.
Heißt: Die Drehzahl muss sich der LED anpassen. Bei dir passt sich die LED der mitunter variierenden Drehzahl an.
Ist dies geschehen, kann ich die Drehzahl ändern, das leuchtende Segment bleibt dann immer an der gleichen Stelle!!!
Das ist dann die Möglichkeit, die mir verschlossen bleibt.
Bei meiner (gedachten) Realisierung dient der Sensor nur dazu, in sich geschlossen einen Regelkreis aufzubauen, um die Rotation konstant zu halten. Es wird also nur ein bestimmter "Arbeitspunkt" benutzt. Du möchtest anhand des variablen Sensorsignals (direkt proportional zu den g-Kräften?) und einer Ein-Punkt-Kalibrierung aber eine relativ große Bandbreite ( ... bis 3V) des Sensorsignals ausnutzen. Das würde ich mich jetzt nicht trauen, da ich mit einer 1-Punkt-Kalibrierung einige Nicht-Linearitäten befürchte.
Das LED-AN-Segment steht z.B. gerade konstant bei 7Uhr. Ich möchte in Richtung 12Uhr fahren.
Ich denke, da brauchst Du intern keine "Verschiebung" zu machen. Wo die LED ist, ist "vorne". Also einfach den Bot auf der Stelle drehen. (= Rotationsgeschwindigkeit des rechten Motors verzögern, linken Motor beschleunigen => ganz normaler Lenkvorgang). Den Zeitpunkt von "LED An" verschieben, das wäre dann eine zusätzliche dritte Ebene, die in den Berechnungen mit einfließt. Und vor allem dann bei den nachfolgenden Lenk-/Fahrkommandos weiterhin mit berücksichtigt werden muss. ...=> Das wird kompliziert!
Einerseits würde mich so ein Projekt reizen, andererseits befürchte ich, dass ich mich dabei furchtbar ärgern muss, weil ich die aktuellen Messsignale während des Betriebs (=Rotation) nicht überprüfen kann. Ein Debugger-Betrieb des Bots ist nicht möglich. Und "simmulieren" geht auch nicht, da der Sensor ja unbedingt die Bewegung braucht, sonst geht die Regelstrecke nicht.
Hmpf... Man (in dem Fall ich, hätte ich mal lesen sollen, bevor ich poste...*grins*) sollte in den Quellcode (Credits to Rich Olson for this work!!!) schauen, da steht eigentlich alles was man wissen muss... -> Auszüge:
// "Open Melt" - Open Source Translational Drift / Melty Brain Robot
// Copyright Rich Olson - rich@spambutcher.com
// Originally developed for "Melty B" / "Melty Beetle" combat robots
// Project homepage: http://www.nothinglabs.com/openmelt/ (see for additional documentation)
// General Notes:
// This system uses an accelerometer to calculate the rate of rotation based on G-forces around a given radius.
// That data is then used to light up an LED once per rotation - giving the appearance of the "front" of the robot.
// The user can adjust the heading beacon by moving the remote control left or right.
// To move - the system turns a motor on when that motor is in the correct position to result in a net movement the direction the robot is intended to go.
// For example - if the heading beacon is on approximately between 10 o-clock and 2 o-clock it indicates movement will be towards 12 o-clock.
// Pushing "forward" on the remote causes the robot to turn on the motor(s) between 6 and 12 o-clock each rotation - the net direction of travel being towards 12 o-clock.
// When the robot is desired to be standing still - the system alternates when the motor(s) are powered to cancel out any translation.
// This description is somewhat of a simplification - see video footage at http://www.nothinglabs.com/openmelt/ for details.
// This code assumes the motors will be driving the bot counter-clockwise (...clockwise if south of the equator)
// Motors are always on or off. Throttle control is achieved by adjusting the duration the motor(s) are on each rotation.
// For instance - at low throttle - the motors may only be on in the example above between 8 and 10 o-clock)
// At high throttle - the motors may only be on between 5 and 1 o-clock
// When spinning up motor(s) will be on all the time until a certain RPM is reached (this is set in a variable in the code)
// This code will work with 1 or 2 motors without any special configuration changes (in fact - you may not immediately notice if a motor fails)
// Most references to "braking" in the code don't literally mean braking a motor. Being "in braking" refers to time during the spin in which a motor may or may not be powered to create translation
// All motors are fully powered "before" and "after" braking
// Physical Build Notes
// More weight seems to result in poorer translation
// More power seems to result in better translation
// Two-wheeled robots that are significantly out of balance seem to suffer from erratic translation
// If a one-wheeled bot is scraping - look at how it's balanced "vertically" - ie try moving weight higher / lower
// What works well small may not scale up (larger / heavier designs have generally performed poorer - even if the power seemed ample)
// Softer wheels seem to result in better translation (--foam-- works really well)
// The default LED "heading" value is correct if motor 1 is at 9 o-clock, motor 2 is at 3 o-clock (or absent) and the LED is at 6 o-clock
// Using this setup isn't mandatory - but should let you skip the "Calibrate Heading Direction" of Config Mode
// One-wheel bots with hard wheels seem specifically prone to "bounce" off floor imperfections when spinning - resulting in poor translation
// A spinning robot may see internal static G forces approaching 200G's - remember this may spike MUCH higher upon impact - expect things to fail in unexpected ways
// If something is not well-secured to the robot - expect it to become a projectile (dangerous)
// Pre-compile Calibration (optional)
// First - attempt to estimate the "radius" the accelerometer is from the center of the bot
// If you've intentionally angled the accelerometer - increase that value by some percentage (take a guess - figure 2x increase for 45 degrees)
// Place that value (in centimeters) into the "radius" variable in the code
// This is only a guess at calibration - you'll need to fine-tune things with the robot actually running
// Entering Config Mode
// Before entering config mode:
// 1. The robot needs to be spun-down and flat
// The "zero" value for the accelerometer will automatically be recorded when entering config mode
// If the robot is sitting at a slight angle - that's probably OK
// Entering config mode before the robot fully spins down will -TOTALLY MESS UP- calibration (if you do this - exit config mode - then re-enter it)
// 2. Throttle should be all the way down
// 3. Move the direction control stick -STRAIGHT- back and hold it there for 2 seconds - then release it
// The left/right center value for the stick is recorded when entering config mode (the current "trim" setting for the stick will be seen as center)
// 4. The LED will start to flash more slowly (about 3 times a second) to indicate it's in config mode
// Config Mode has three different "sub-modes" selected by the throttle control
// Low throttle - Tracking Calibration
// Mid throttle - Heading Calibration
// High throttle - Testing Mode (normal control)
// Note: actual throttle speed is always locked at 50% in configuration mode (can be changed by adjusting the associated variable)
// Calibrate Tracking:
// This process will get the robot to "track" (keep the heading LED pointing a given direction) correctly
// Increase the throttle just above the point where the robot is spinning
// Move the stick to the left or right until the heading LED tracks correctly
// When you're near calibrated - you should see a single LED streak taking up about 1/3rd of the rotation
// If the LED takes up more than 1/3rd a rotation - you're tracking too slow - hold the stick to the right to correct this
// If you see multiple LED streaks (smaller than 1/3rd a rotation) - you're tracking too fast - hold the stick to the left to correct this
// Calibration can account for accelerometer positions from as low as 0.1x up to 10x the "radius" variable
// You can also adjust tracking by directly manipulating the "radius" variable
// Calibrate Heading Direction:
// This process will help get the robot to drive "straight" - ie - not backwards / at a 35 degree angle
// 1. Spin up the robot by increasing the throttle to 100% (heading LED should not be pulsed)
// 2. Move the control stick forward briefly (this will cause the robot to translate)
// 3. Note what angle the robot is translating at - consider if you would want the LED beacon to be moved to the left or right to track properly
// 3. Reduce the throttle slightly until the LED pulses
// 4. Move the control stick left or right to move the heading LED in the same direction
// This adjustment is "non-proportional" - to make a larger change - hold the stick left or right for a longer duration
// In general - calibrating the heading is trickier than calibrating tracking - may take a few tries to get it right
// 5. Repeat steps 1-4 until moving the stick forward results in the robot tracking straight ahead
// If you don't have good luck doing the "real-time" calibration - you can just try setting the "led_adjust" variable in the code
// Exiting Config Mode
// To exit Config mode - pull the throttle down / hold it for about 2 seconds.
// LED should return to flashing quickly
// Configuration values will then be automatically be saved to ROM (saved even afer you power down).
// Configuration values are -not- saved until config mode is exited.
// Calibration values will be cleared if you re-program the chip (assuming it has the default "fuse" settings)
// If you've changed the trim on your transmitter since the last time you've entered Config Mode – the act of entering into Config Mode itself will effectively change your tracking
// (so you'll want to actually do a calibration before you exit).
// Driving Notes
// Robot will (hopefully) remain still until given throttle
// Should spin in place once throttle is applied (assuming control stick is centered)
// Move control stick left or right to adjust heading (fully proportional)
// Move stick forward or backwards to go forwards or backwards (non-proportional)
// Turning too fast can result in a bot getting "unbalanced" - if you have control problems after turning - try turning slower
// Yes - it drives kind of like a regular robot does
// Minor inaccuracies in tracking can be compensated for using steering / adjusting the trim on the transmitter
// (note this will cause the status LED to show the slower "not-centered" flash pattern when not spun-up)
// Driving constantly forward / adjusting steering to head towards the target seems to work well
// In general - best "translation" (ie movement) speed occurs at roughly half-throttle (full throttle may result in slow translation)
// The heading light will "pulse" over 50% throttle to provide feedback to the driver
Bevor der Thread hier in Vergessenheit gerät:
Für kalte Winterabende (oder um den Kater nach der WM loszuwerden... ) empfehle ich das ansehen der Videos auf dieser http://r2rcr.com/melty%20technology.htm Seite. ... *zwinker*
Double-Trouble ist übrigens ein 12lbs-Bot (entspricht einem Raptor!!!) -> Das High-Speed-Video ist sehenswert!!!
@Reiner: Wenn Du die Geschwindigkeit an die LED anpasst und nicht umgekehrt, musst Du nach jedem Kontakt mit dem Gegner oder der Arenabande neu justieren...
So war das eigentlich nicht gedacht. Ich muss dem Bot einmalig beibringen, was seine optimale Rotations-Geschwindigkeit ist. Dazu drehe ich "manuell" die Drehzahl hoch, bis die LED stabil auf einer Stelle leuchtet. Dann drücke ich den "Kalibrier-Knopf". Jetzt muss der Bot mit seinem Beschleunigungssensor den Wert messen und "sich merken".
Dann kommt der Fall, den Du o.g. beschrieben hast: Ich rempel einen anderen Bot an, das Chassis wird abgebremst. In diesem Fall ist die LED nicht mehr an einer Stelle. Fahren ist jetzt nicht mehr kontrolliert möglich.
Aber: Die Software stellt fest, dass der Wert vom Beschleunigungssensor zu gering ist, und dreht die Eigen-Rotation wieder hoch. Und zwar solange, bis der Sollwert (= bei der Kalibrierung gemerkter Wert) wieder erreicht ist. => Müßte eigentlich klappen, ausser die 10bit Auflösung vom Sensor und dem Mikrocontroller sind nicht genau genug. Ich denke aber, für unsere Zwecke müßte es reichen.
@Marten: Hab' ich einen Denkfehler drin?
(Magie schon eher ;-)),
Och, da liegst Du schon richtig. Die meisten Probleme beim Entwickeln von Hardware oder Software werden mit Knoblauch und Weihwasser gelöst. Auch ein Eichenpfahl hilft manchmal. In schwierigen Fällen dann Silberkugeln verwenden....
Das, was ich jetzt nicht beurteilen kann, ist das Verhalten vom Sensor. Jeder Messfühler hat eine gewisse "Trägheit" und Hysterese. Vor allem können auch die Störgrößen (z.B. Temperatur) eine erfolgreich durchgeführte Kalibrierung versauen.
Angenommen, man fährt die Rotationsgeschwindigkeit mit dem Stick langsam hoch, bis dann die LED einen schmalen Bogen bildet. Dann muss der "Kalibrierknopf" an der Funke gedrückt werden. Das Signal geht zum Fahrtregler. Der misst das aktuelle Signal vom Beschleunigungssensor. Dieser Wert ist der "Soll-Wert" und wird im Programm gespeichert. Beispielsweise: 2.123 Volt.
Ab dieser Übernahme des Wertes vom Beschleunigungssensor muss die Vorgabe durch den Kreuzknüppel ignoriert werden. Ab jetzt läuft der Bot in seiner Regelschleife autark vor sich hin. Liefert der Sensor zuviel Spannung (= zu hohe Rotation) muss der Regler beide Motoren synchron in der Geschwindigkeit zurücknehmen. Etc.
Wird der Bot ausgeschaltet und dann wieder eingeschaltet, ist der vorher gespeicherte Wert von z.B. 2.123 Volt immer noch vorhanden. Beim "Go"-Kommando für den Spinner läuft der Regelkreis wieder an und die beiden Motoren werden so beschleunigt, dass der Sensor wieder den Sollwert von 2.123Volt liefert.
Falls jetzt im Inneren der Bots durch die Verlustwärme der Motoren der Sensor "gestört wird, dann liefert er zwar weiterhin seine 2.123Volt. Aber die Drehzahl kann ein bißchen daneben sein. Der LED-Balaken wird dann ganz langsam zum Wandern anfangen. Also muss neu kalibriert werden.
=> Das ist jetzt der Punkt, den ich noch nicht beurteilen kann und: eine neue Kalibrierung vor jedem Kampf ist unbrauchbar. (So ein System muss funktionieren wie eine Kalaschnikov: "Schießt immer" Alles andere wäre nervig.)
