Mein erster Roboter

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Mein erster Roboter

      Hi,

      erst mal hallo. Ich bin neu hier im Forum und hoffe, möglichst wenig Fragen zu stellen, die schon irgendwo beantwortet wurden. Falls doch - schon mal Sorry :)

      Ich baue also gerade mit meinem Sohn einen Raptor der im September in Bochum MMM antreten soll. Er sieht schon ganz gut aus und fährt auch schon recht zuverlässig. Mir fehlt eigentlich nur noch eine Waffe und ein Name, aber da fällt uns sicher noch was lustiges ein :)

      In den Regeln habe ich gelesen, dass Motoren bis zu einer bestimmten Größe erlaubt sind. Im Forum lese ich aber oft von Akkuschrauber-Motoren. Sind die alle in der Größenordnung oder oder gibt es da eine Sonderregelung?

      Meine zweite und viel wichtigere Frage betrifft die Fernsteuerung. Ich habe statt einer handelsüblichen Fernsteuerung etwas anderes verbaut. Zum Einsatz kommt hier das IOIO Board (1br.de/ioio), das über 2.4 GHz Bluetooth angesteuert wird. Als Fernsteuerung verwende ich einfach ein Android Handy oder Tablet. Die Fernsteuer Software habe ich selber programmiert und da Bluetooth bidirektional ist, kann ich Sensoren (z. B. für Stromverbrauch, Lage etc.) direkt im Tablet PC abfragen und die Werte direkt in der Fernsteuerung nutzen (Z. B. für die Fahrtrichtung oder überbrückbare Motor-Notabschaltung). Außerdem kann ich hier einfach alles in Java programmieren und das mache ich ja sonst auch den ganzen Tag :-). Nach meinem Verständnis der Regeln ist Bluetooth OK, aber ich wollte doch noch mal nachfragen.

      So, das war es erst mal.
      Gruß Michael
    • Hallo Michael,

      willkommen hier im Forum!
      Es freut mich, dass euer Raptor schon lebt. Damit dürftte es am 21./22.September mit der Jungfernfahrt in der Arena bestimmt klappen.

      Die Akkuschraubermotoren sind in der Regel relativ baugleich. Die Motoren sollten eine bestimmte Größe nicht überschreiten, damit die Raptor-Klasse nicht ein "Wettrüsten" der finanzstarken Spezialmotor-Käufern wird.
      Die Motoren an sich wären für ein paar Euros zu kaufen, aber die Getriebe sind der Gag. Und die zweistufigen Planetengetriebe sind für das Geld, das ein billiger Akkuschrauber kostet (waren vor ein paar Jahren nicht mal 10 Euro) unschlagbar.
      Die Motoren haben in der Regel auch 12V Nennspannung (man verbessere mich, wenn ich nicht mehr auf dem Laufenden bin!).
      Die Betriebsspannung ist 12V, also noch für 10 Zellen NiCd oder NiMh ausgelegt. Mittlerweile dürfen auch drei Zellen LiPo (mit je 3.7V) oder vier Zellen mit LiFePO4 (mit je 3.3V Nennspannung) verwendet werden.
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Hallo Michael,
      willkommen im Forum.
      Ich finde im Regelwerk keine Argumente gegen deine Fernsteuerlösung, ist meiner Meinung nach O.K..
      Wichtig ist dass alle Antriebe stehen bleiben wenn dein Handy ausfällt. Das wird beim TechCheck überprüft.
      Normalerweise wird dazu an der FB Vollgas gegeben und der Ausfall der FB simuliert indem sie währenddessen ausgeschaltet wird. Wie könnten wir das bei einem Android Gerät machen?

      Die Motoren sind bei den Raptoren, wie Reiner schon erwähnte, limitiert.
      Hier in den Raptorregeln Im Absatz 3.1. steht mehr dazu.
      Die maximalen Abmessungen findest du auf der letzten Seite im Anhang.
      Die "üblichen" preisgünstigen Baumarktakkuschrauber passen von der Motorisierung alle da rein. Die einzige Ausnahme die ich bisher gefunden habe steckte in einem Hilti-Akkuschrauber, aber die verwenden wir wohl seltener bei den Raptoren :D

      Möchtest du vielleicht ein paar Fotos von deinem Bot posten?

      Gruß Dirk
      haben ist besser als brauchen
    • Erst mal danke für die vielen Anregungen und Tipps. Das Thema wird aktuell in 2 sep. Threads diskutiert (forum.roboteers.org/thread.php?threadid=5242&sid=). Sorry, mein Fehler :) habe gestern auch schon mal per Mail nachgefragt und so .... naja - pech.

      Aber nun zum Thema. Failsafe ist im IOIO Board inclusive. Da das Board nur arbeitet, wenn die App läuft. Testen kann man das z.B. indem man das Handy in einen faradayschen käfig legt oder einfach die App im laufenden Berrieb (Vollgas) beendet. Habe das selbst schon getestet und es funktioniert wunderbar.

      Bisher habe ich die Failsafe Funktion als "hold last known position" verstanden. Was währe denn besser? Vermutlich ein Mechanismus, der den Raptor in den Ruhezustand zurück bringt. Das geht auch. Ich könnte noch einen Arduino mit einbauen, der den Verbindungsabbruch erkennt und dann alles in Ruheposition bringt. Das schaffe ich aber vermutlich nicht mehr bis September :(

      CU
      Michael
    • Beim Failsave muss alles gefahenbringendes deaktiviert werden das heißt fahrantrieb und waffen aus, den letzten zustand zu halten wäre relertiv schlecht da er bei voller fahrt dann einfach in die bande heizt und da gegenfährt bis entweder der akku leer ist oder der bot abraucht. Sinn vom failsave ist ja das der bot ohne gefahr dann nach dem kampf gefahrenlos spannungsfrei geschalten werden kann
    • Wilkommen im Forum (nachträglich),
      ich war im Urlaub, daher erst jetzt.

      Mein Input zu dem Thema,
      wenn kein anderer Bot durch die Sendeart beeinflusst wird,
      denke ich, ist es in ordnung.
      ABER, ich weiß nicht (wegen Failsave) ob die App beim
      ausschalten vielleicht noch einen "Stop" oder so sendet.

      Ich denke man sollte beim Failsave-test den "Ernstfall"
      ausprobieren und den Akku vom Gerät ziehen,
      bei allem anderem könnte das Handy noch Daten übermitteln.
      (Das dauert dann mit Handy wieder anmachen etc.
      aber sollte etwas passieren, ist es ja auch erstmal wirklich aus.)

      Ist auch die Fragen um was es für ein Gerät geht,
      Handy = Akku zieh bar, außer Ei_phones.
      Bei Tablets sind die ja meist eingebaut.

      Aber es findet sich schon eine Lösung, ich kenn mich da
      nicht so aus, vielleicht reicht ja wirklich ein App beenden / Task manager-kill, da können andere drüber urteilen,
      ansonsten viel Erfolg / Spaß mit dem Projekt! ;)
      Warum einfach?
      Wenns auch kompliziert geht??? ;)
    • Ich finde euer Projekt echt interessant. Auch mit den eingebauten Sensoren... auf sowas steh ich :D

      Aber das einzige was auch mir Kopfzerbrechen macht ist der Failsafe. Die App beenden ist eine Sache, das ist definiert. Z.B. die App weiss, ok ich werde beendet, eben noch ein Stop-Signal raus hauen.

      Was aber wenn das Handy/Tablet hängenbleibt, neu startet (wegen Updates etc.) oder warum auch immer aus geht. (alles schon gehabt mit meinen Gerätschaften. ;) ).

      Letzte Position halten ist auch ungeschickt. Denn es geht ja auch darum, wenn jemand in der Arena ist, muss jeder die Finger von der Funke halten. Wenn dann die App beendet wird oder so, fährt das Teil los... ;)


      Wegen der Waffe. Die würde ich u.U. erstmal weg lassen. Der Bot sollte robust gebaut werden und dann schonmal ordentlich getestet werden. Das bringt mehr als die Zeit stattdessen für eine Waffe zu nutzen. Wenn der Bot dann in der ersten Runde schon alle Viere von sich streckt ist auch nichts gewonnen. :)


      Auf jeden Fall viel Erfolg und man sieht sich auf dem Event!!
      Da musst du mir aber mal alles genau zeigen "interessiert ist" :)
    • Zum Testen zuhause wäre als die Vorgehensweise:
      - Bot auf den Prüfstand (=aufgebockt)
      - Vollgas geben und halten
      - Mit dem Smartphone weit weg gehen (viele Betondecken und Wände..)
      - bleiben die Motoren stehen? Wenn ja: ok; wenn nein: Failsafe einprogrammieren. => Von der Software her wirst Du das als Software-Architekt locker können. Wenn es an einer kleinen Hardware scheitert, dann melde Dich kurz. ;)
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Wie könnte man denn so eine Failsafe Hardware am besten umsetzen? Kanäle habe ich noch genug frei. Ich könnte z. B. ein Rechteck (PWM) Signal auf dem Tablet erzeugen. Bei einem Verbindungsabbruch bleibt das Signal am Port dann entweder bei einem positiven Signal oder 0 Volt stehen. Das dann durch einen hochpass jagen. Da kommt dann ja nur noch was raus, wenn ein Rechteck Signal anliegt. Das Signal kann ich dann nutzen um damit ein Relais zu Schalten, das meine H-Brücken für die Motoren mit Strom versorgt.
      Das hat Zur Folge, dass die Motoren nur Strom bekommen, wenn ein Signal anliegt.
      Bin aber auch offen für andere (einfachere) Vorschläge :)
    • Ich verstehe die Beschreibung von dem IOIO-Modul so, dass Du die Software selber schreibst und über den Bootloader in das Board hineinpresst? Ebenso schreibst Du die Java-App für das Smartphone selber?

      Dann würde mal vorschlagen:
      Programmiere in der Smartphone-App einen zusätzlichen Kanal (z.B. Kanal 5; => ich habe keine Ahnung, ob das jetzt geht, aber einfach mal als Anregung....). Dieser Kanal 5 wird nicht durch Aktionen am Display getriggert, sondern über einen zyklischen Timer. Der wechselt den Zustand dann z.B. alle 50ms von 0 auf 1 bzw. umgekehrt. Diese Toggle-Funktion wird als eine Art "Heartbeat" zu Deinem IOIO-Board übertragen. Wenn die Funkverbindung abreißen sollte, dann ändert sich somit der letzte Zustand nicht mehr.

      Jetzt kommt die Software für das IOIO in's Spiel. Der Toggle-Kanal wird aufgefangen und triggert einen Timer. Der Timer hat z.B. eine Laufzeit von 210ms. Wenn also das Signal für mehr als 200ms ausfällt, dann schlägt der Timer zu, setzt ein Flag und das disabled dann sämtliche Fahr-/Waffenkanäle. "Disabled" heißt, alle Motoren mit PWM=0 setzen.

      Sobald ein gültiges Funksignal da ist, würde das Toggeln wieder einsetzen die Fahrkanäle übernehmen wieder den Wert, der ihnen bei Kanal 1 bis 4 vorgegeben wurde.

      Wie gesagt, ich habe keine Ahnung, wie weit Du in die Java-App eingreifen kannst, um mit einem Timer zyklisch Telegramme mit wechselndem Inhalt versenden zu können.

      Das IOIO-Board verwendet einen PIC, da dürfte das kein Problem sein, einen Software-Timer über einen der verfügbaren Hardwaretimer auf eine Zykluszeit von mehr als 200ms abzuleiten.

      Nach meiner bescheidenen Einschätzung brauchst Du also gar keine zusätzliche Hardware, das geht locker mit dem PIC .

      Deine Idee von dem Sägezahn würde in gewissen Grenzen auch funktionieren. Aber ein Hochpass wird anfangs wohl etwas Zeit benötigen, bis er eingeschwungen ist und Du damit genügend Sensitivität kriegst. Die Abfrage über einen Analogkanal kostet aber leider etwas zusätzliche Zeit (geht natürlich!), ich würde das also nicht so machen. Wichtig ist ganz einfach, dass Du eine Unterbrechung (Flankenwechsel des Heartbeats) vom SM mitkriegst.

      Bei der Smartphone-App kann ich Dir leider nicht helfen, hab' da keinen Einstieg geschafft (keine Ahnung wie man das macht und wo man ein Programm dafür herkriegt...) beim PIC könnte ich Dir helfen. Allerdings mache ich die Failsafe-Überwachung in meinen Fahrtreglern etwas anders als hier beschrieben.
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • @IBF: Danke für die Infos. Allerdings ist es beim IOIO Board so, dass man die komplette Logik des PIC in die Android App verschiebt. Daher ist es sehr leicht den Heartbeat vom Tablet PC aus zu senden, aber die Logik die den Heartbeat erkennt. Müsste in die Firmware des IOIO Boards integriert werden. Das IOIO Board enthält eigentlich nur die Kommunikations-Software, die dafür sorgt, dass die Signale an den 48 IO-Ports richtig verarbeitet werden (Details dazu unter github.com/ytai/ioio/wiki/The-IOIO-Manager-Application). Ich werde es auf jeden Fall mal probieren, aber eigentlich wollte ich nicht unbedingt die Firmware des Bords anfassen. Gibt es keine einfache Schaltung/Hardware, die so einen Heartbeat nutzt?
    • Danke für den Link zu der Beschreibungsseite. Entweder liege ich total falsch oder ich interpretiere den Text anders.

      Mein Verständnis:
      - Bootloader ist fix
      - Die neue Applikation für den PIC ist im SM.
      - IOIO und SM nehmen Kontakt auf
      - IOIO stellt ein neues Applikationsprogramm fest, lädt es und installiert es über den Bootloader.
      - => hier wäre also der Knackpunkt zwischen Deinem und meinem Verständnis.
      - Neue Firmware ist geladen und läuft.

      Wenn sich die Firmware im PIC nicht ändern würde, hätte ich schwere Bedenken, wie sich das Programm (Application) beim Start initialisieren sollte. Die ganzen Datenrichtungsregister usw können sich je nach Anwendung ändern, die Ports können mal Digital sein oder mal ein Analogeingang,....

      Mag sein, dass ich hier auf dem Holzweg bin und ein falsches Verständnis von dem Board bzw. dem System habe! Das mit der Toggle-Funktion und dem Heartbeat liesse sich aber ganz einfach ausprobieren, oder? (IM SM eine App schreiben, die einfach alle 1 Sekunde einen Portausgang ändert. An dem Portausgang eine LED anschließen. Die muss dann blinken. Wenn das Smartphon abgeschaltet wird und die LED blinkt immer noch: bingo. Wenn nicht, dann hast Du recht, dass tatsächlich immer eine bidirektionale Verbindung zwischem SM und IOIO notwendig ist und das System mit dem Heartbeat hier nicht so einfach funktionieren kann.

      Ich bin derzeit im Urlaub und kann nicht an meine Papier-Unterlagen ran. Aber ich denke, mit dem Feld-Wald-Wiesen-Timer NE555 müßte sich eine kleine Schaltung realisieren lassen, bei dem dann ein fehlendes Toggle-Signal von einem PIC-Portausgang dazu führt, ein Gatter (UND-Gatter zwischen PWM-Ausgang und Fahrtregler-Eingang) zu sperren.

      I
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • @IBF: Wie schon gesagt. Die IOIO Software (Sowohl Booloader als auch die Firmware) möchte ich lieber nicht anfassen. Da ich das IOIO Board auch für andere Zwecke nutze und die Firmware nicht jedes mal austauschen möchte. Daher ist es genau so wie Du schreibst. Wenn die Verbindung beendet wird, hört die LED auf zu blinken. :(

      Auf die Schaltung mit dem NE555 bin ich schon gespannt. Habe mittlerweile mal selbst was im Simulator zusammengeklickt und dabei ist folgender Aufbau heraus gekommen. (Siehe Anhang)

      Zur Erklärung der Schaltung: Links simuliere ich einen IOIO Port im Open Drain Modus. Dann ein Hochpass und noch ein NPN Transistor als Inverter. Ist die Eingangsfrequenz höher als ca. 10 Hz. ist die Ausgangsspannung am R6 nur noch ca. 0.7 V was als TTL Low gilt. Sinkt die Frequenz unter 10 Hz steigt die Ausgangsspannung in weniger als 0.3 sec. auf über 2.2 V was als TTL High gilt. Damit kann ich eine 0815 Relais Steuerung (1br.de/rel - Sowas habe ich noch rumliegen) ansprechen. Was hältst Du davon?
    • hoi michael, auch von mir ein (verspätetes...) willkommen im forum.

      prinzipiell wird die schaltung arbeiten, allerdings nicht mit dem angegebenen relais-modul! (das verwendet KEINE TTL-Pegel)

      die cny17-optokoppler benötigen normalerweise 5-15mA
      "Pro Kanal braucht man 15-20mA für die Optokopler Led."

      bei einer belastung von mehr als 1mA dürfte deine schaltung in der derzeitigen konfiguration nicht mehr das machen, was die simulation verspricht (dort ist die last ein 10k-widerstand).

      weitere anmerkung:
      beim ansteigen/abfallen der ausgangsspannung läuft diese durch die "welligkeit" (um die 10Hz) mehrmals durch die "schaltschwelle" des relais-moduls, was zu einem flattern des relais führen kann.
      wenn du mit dem relais eine induktive last (z.b. motor) ansteuerst, wird es einige nette kontaktfunken geben. zwar nur kurz, aber lange leben werden die kontakte eventuell nicht! (muss nicht passieren, kann aber...)


      EDIT (ca. 16:05):
      ich würde als ansatz ein retriggerbares monoflop vorschlagen. eine flanke des 10Hz-rechtecks (sagen wir mal steigende flanke) als trigger für das monoflop nehmen (monoflop schaltet "ein") und mit jeder weiteren steigenden flanke das monoflop retriggern (monoflop bleibt "ein"). treffen vor ablauf der monoflop-zeit (zeitkonstante ist über ein RC-Glied einstellbar) keine steigenden flanken ein, schaltet das monoflop wieder aus.

      wir haben in diesem Replikators Hammersteuerung thread mal über monoflops diskutiert (ab der zweiten oder dritten seite). dort ist auch ein entsprechender baustein angegeben...
      Flipper??? Flipper gehört ins Wasser!!!
    • Original von UnskilledWorker


      EDIT (ca. 16:05):
      ich würde als ansatz ein retriggerbares monoflop vorschlagen. eine flanke des 10Hz-rechtecks (sagen wir mal steigende flanke) als trigger für das monoflop nehmen (monoflop schaltet "ein") und mit jeder weiteren steigenden flanke das monoflop retriggern (monoflop bleibt "ein"). treffen vor ablauf der monoflop-zeit (zeitkonstante ist über ein RC-Glied einstellbar) keine steigenden flanken ein, schaltet das monoflop wieder aus.



      yep, so war das eigentlich auch mit dem NE555 gedacht. Sollte ein retriggerbares Monoflop werden.




      Wenn die Verbindung beendet wird, hört die LED auf zu blinken. :(


      Ok, dann hatte ich die Erläuterungen auf der von Dir genannten Seite falsch interpretiert. Mit einem Heartbeat auf die IOIO-Baugruppe geht es alleine somit nicht, da muss tatsächlich ein kleines Stückchen Hardware zwischen IOIO und Fahrtregler dazwischengefrickelt werden.

      Frage: Welche Fahrtregler benutzt Du eigentlich? (vielleicht haben die sogar irgendeinen "Inhibit-Eingang". (=> solche Fahrtregler für diese Leistungsklasse kenne ich zwar nicht, aber oft spielt der Zufall eine große Rolle...)

      Ist die Eingangsfrequenz höher als ca. 10 Hz. ist die Ausgangsspannung am R6 nur noch ca. 0.7 V was als TTL Low gilt. Sinkt die Frequenz unter 10 Hz steigt die Ausgangsspannung in weniger als 0.3 sec. auf über 2.2 V was als TTL High gilt.

      Ehrlich gesagt habe ich immer etwas Skrupel, einen TTL-Pegel im "Niemandsland" zwischen 0.5V und 2.8V zu betreiben bzw zu provozieren. Der Ansatz mit einem Pulsausgang ist aber auf alle Fälle der richtige Weg.

      Mit dem NE555 muss ich ein Datenbuch konsultieren, auswändig kann ich die Schaltungen nicht. Würde aber noch über eine Woche dauern, bis ich da rankomme.
      Ich schau mal, ob ich über I-Net was für Dich finde.... (Lochraster, Lötkolben und ein paar Standard-Bauteile dürften offensichtlich kein Problem sein...?)
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Nachdem ich mich nun mal etwas intensiver mit der IOIO Firmware beschäftigt habe, ist mir in den Sourcen (C++) eine fertige Fail-Safe Funktion aufgefallen. Ein kurzer Test und siehe da - Fail-Safe ist tatsächlich schon integriert. Leider ist das ganze nicht dokumentiert :-(. Das hätte mir einiges an Arbeit erspart...

      Hier der Test: youtube.com/watch?v=uEylsUtAlYo&sns=em

      Als nächstes kommt dann jetzt die Motor Entstörung und die Ein/Aus LED.

      Die Panzerung und die Bewaffnung schaffe ich hoffentlich auch noch :)
    • Da ich das IOIO Board auch für andere Zwecke nutze und die Firmware nicht jedes mal austauschen möchte.


      Wie teuer ist das IOIO Board?
      Du musst bedenken, wir bauen Showkampfbots,
      es kann passieren das es kaput geht!
      (Von kleine abstehende Teile die abreisen bis zum kritischen Einschlag eines Spinners wo das Board fest ist
      (auch wenn etwas unwahrscheinlicher), kann alles passieren.)

      Ein Tipp zur befestigung, Es gibt so kleine "Sockel" die du zwischen schrauben kannst, die nehmen Erschütterungen auf.
      Ansonsten kann man auch überlegen das Board mit Silikon zu bedecken, verklebt die Bauteile, schützt vor Schmutz (besonders Metalischer, => Kurzschluss) etc.
      Man kann den auch abkleben oder in ne Tüte stecken, oder einfach hoffen, muss man aber nicht. ;)

      Nicht das der nacher kaputt geht und wichtig oder bersonders Teuer war.


      Ansonsten:
      und die Bewaffnung schaffe ich hoffentlich auch noch :)

      Wichtig ist an diesem Punkt zu erwähnen, wir kennen das System was du nutzen willst noch nicht und wir haben keine Erfahrung damit!
      Uns ist die Sicherheit sehr wichtig, also nur wenn keiner ein Bedenken hat (nach Tests in der Arena), kann die benutzt werden.

      Soll heißen, Failsave funktioniert nicht richtig o.ä.
      = Keine Waffe.
      (Klingt hart, aber andersrum gedacht, bei Notfällen muss einer in die Arena, wenn da eine Waffe auf Irfahrt läuft, geht das nicht.)
      Also den Waffenmotor so anschließen, das der leicht abgemacht werden kann, damit man zur not ohne Waffe fahren kann.
      (Z.B. mit einem Stecker oder direkt am Regler (wenn nicht zugebaut).


      Ansonsten schön das jemand neues wieder einen Bot baut und das auch durchzieht und hier uns Berichtet! ;)
      Knipps doch mal ein, zwei Bilder und stell die ins Forum.
      (Interesse :D )
      Warum einfach?
      Wenns auch kompliziert geht??? ;)