Archiv verlassen und diese Seite im Standarddesign anzeigen : Modellsegelboot & Roboter & Zukunftsprojekte
Hallo Freunde
Ich bastle jetzt seit über 2 Jahren an meinem Modellsegelboot und bin jetzt an der Stelle wo der Einbau der Mechanik dran ist. Da ich Langzeitsarbeitsloser bin, seit über 3 Jahren und mit 47 Jahren zu alt um vermittelt zu werden muß ich meine Zeit in sinnvolle Tätigkeiten investieren. Mein Modellsegelboot mit Intelligenz zu versehen war für mich, ich komme aus der Halbleiter und Telekommunikation, eine logische Richtung. Mir schwebte deshalb ein Mikrocontroller vor, und nach einigen Recherchen traf ich auf die AVR's, auf Robotikhardware und auf dieses Forum. Das RN-Control hat die richtige Größe, eine Version mit dem mega128 wäre mir lieber gewesen, da Erfahrungsgemäß mit der Praxis der Apettit wächst. Soweit zu meiner Vorstellung als Neuling hier. Vielleicht noch ein letztes, ich bin stur und mache gerne Lösungen auf meine Art. Das bringt viele Herausforderungen aber auch so manche gute Lösung. Hier mein Projekt:
Eine Langkielsegelyacht, 153cm lang, soll als Technologieplatform dienen, um damit zumindest im Schiffsmodellbau neue Wege zu beschreiten. Also was ihr als Roboter auf Rädern und Raupen macht ist bei mir ein Segelboot.
1. Zuerst soll der Controller die regelbaren Spannungsregler steuern und so sicher stellen das die 12V, 16Ah der NimH-Akkus, immer die Spannungen 12V; 7,2 bis 8,4V; 6V und 4,8V liefert und bei sich leerenden Akkus mich warnt und die 4,8V, 6V und 7,2V jeweils solange wie möglich nachregelt und so den Spannungsabfall ausgleicht.
2. Der Controller soll die Winsche, das sind "Trommeln" auf Deck und die dazugehörige Mechanik steuern, überwachen und im Schadensfall ein fail-safe Verhalten sicherstellen. Dazu sind Endstellungsüberwachungen nötig, Ausfälle der Mechanik zu erkennen, z.B. wenn sich Schote verheddern und die kräftigen Getriebemotoren Dunker GR42x40 drohen das Boot zu beschädigen, und auf Seilspannung achten um ein aus der Trommel springen und sich verheddern möglichst zu vermeiden.
3. Es sind gewisse Bedienfehler zu erkennen und zu verhindern. Hierzu muß der Controller die Signale vom Empfänger dekodieren, auswerten und an die Servos weiterleiten. Ein Beispiel ist z.B. zu verhindern das der Spinnaker, das ist ein großes Vorsegel das sich wie in Luftsack öffnet und nur bei "achterlichen" Winden, also von hinten kommend eingesetzt werden darf. Solle das Boot also eine Wende fahren, also eine Kurve darf dieses nicht betätigt werden.
4. Es soll gewisse Manöver fahren, so was kennt man vom Flugmodellbau.
5. Es soll in Zusammenarbeit mit GPS und anderer Sensorik eines Tages auch selber einen Kurs fahren können und dabei seinen Kurs auf Zeit optimieren.
6. Es soll Kolllisionen verhindern. Hier ist an den Einsatz von Sensoren für Einparkhilfen aus dem Automobilbau gedacht. Vielleicht sogar dabei die Regatta-Vorfahrt regeln beachten.
Um diese alles im Laufe der Zukunft zu realisieren denke ich an ein modulares dezentrales Steuersystem. Der "Zentralrechner" sollte dabei zwar sehr klein sein, aber die nötigen Resourcen bereithalten. Zum Anfangen denke ich dabei an die RN-Control-Karte von Robotikhardware als Zentralrechner, die würde man dann im Laufe der Zeit und bei Bedarf durch leistungsfähigere Hardware ersetzen. Um Synergien zu erreichen möchte ich mich daher an die Spezifikationen dieses Forums halten um so Unterstützung zu finden und vorhandenes zu nutzen. Auf dem Forum Schiffsmodell.net möchte ich diese Platform für den Schiffsmodellbau promoten und das Spezialwissen der Mitglieder nutzen. Ich glaube der Schiffsmodellbau kann hiervon profitieren.
Nun meine Fragen, die ich "Frank" bereits bei Robotikhardware gestellt hatte, dabei möchte ich hervorheben mit Assembler programmieren zu wollen:
1. Welche Entwicklungsumgebung ist hier zu empfehlen?
Studio 4, das scheint die "golden release" von Atmel zu sein, oder Bascom oder PonyProg?
2. Wenn ich es richtig verstanden habe kommunizieren die Entwicklungsumgebungen alle mit RN-Control über die RS232 und laden Daten und Programme über die ISP-Schnittstelle. Beim Einsatz von Studio 4 soll das ISP-Kabel von Robotikhardware das an das lpt im pc angeschlossen wird nicht geeignet sein, gibt es Unterlagen wie ein passendes Kabel wäre, oder müßte man eines direkt von Atmel beziehen? Wenn ja, welches und ist das auch bei Conrad zu erwerben?
3. Die Spanungsversorgung des RN-Controlls kann beliebig zwischen 7V und 18V liegen, die Karte erzeugt daraus ihre benötigten 5V und stellt diese auch an einem Ausgang für andere Module zur Verfügung? Frage dazu ist das korrekt und gleicht die Logik auf der Karte auch einen Spannungsabfall am NimH-Akkus aus? Voll geladen hat ein Akku-Pack aus 10 Mono-D-Zellen 14V und kann bis auf leicht über 10V abfallen! Habe das richtig verstanden, die RN-Control kann die Akku-Spannung überwachen und trotz Spannungsabfall die 5V bereitstelllen soweit die Spannungsquelle nicht unter 7V fällt?
4. Gibt es auch die Möglichkeit die Schaltung der RN-Control elektronisch zu bekommen um diese für einen mega128 im QFP-Gehäuse anzupassen? ich denke da an die eagle oder Target 3003 Software. Die Frage ist auch deshalb von Interesse da ich in so einem Fall gerne die Möglichkeit nutzen würde eventuelle Anforderungen aus dem Schiffsmodellbau aufzunehmen und eventuell zusätzlichen externen Datenspeicher hinzu zu fügen. Natürlich soll die Karte sehr kompakt bleiben, das macht die RN-Control gegenüber ihrem großen Bruder so interessant für den Schiffsmodellbau.
5. Gibt es Erfahrungen mit der Implementation von WLAN?
6. Wie lange dauerst es von der Bestellung bis zum Erhalt der RN-Control? Was sollte man außer der reinen karte hinzu bestellen?
Soweit erstmals meine mich drückenden Fragen und bitte um Nachsicht zu diesem umfangreichen Erstbeitrag.
Mit freundlichem Gruß
Hellmut
1. Welche Entwicklungsumgebung ist hier zu empfehlen?
Studio 4, das scheint die "golden release" von Atmel zu sein, oder Bascom oder PonyProg?
Bascom ist eine Entwicklungsumgebung für Basic und Ponyprog ist soweit ich weiss gar keine Entwicklungsumgebung für irgendeine Programmiersprache sondern (nur) ein Programm mit dem man fertig kompilierte Programme über einen ISP-Adapter in den Controler hochladen kann.
Wenn du wirklich ausschliesslich in Assembler programmieren willst, ist AVR Studio am naheliegensten.
Ausser den von dir genannten Programmen wird noch WinAVR häufig genutzt - das ist eine Compiler für die Programmiersprache C.
WinAVR, AVR Studio und Ponyprog kannst du dir kostenlos herunterladen, von Bascom gibt es eine Demo-Version die als einzige Einschränkung hat, dass sie auf 2kB Programmgrösse beschränkt ist.
Ich würde mir an deiner Stelle einfach alle Programme mal herunterladen und ansehen, da auch Kombinationen sinnvoll sind.
Du kannst z.B. mit Bascom in Basic oder mit WinAVR in C programmieren, dort zeitkritische Routinen als Assembler-Code einbinden, das Ganze dann in AVR-Studio simulieren und anschliessend mit Ponyprog in den Controller hochladen.
Bascom und WinAVR sind übrigens Compiler, d.h. was da nach dem Kompilieren rauskommt ist nicht unbedingt wesentlich langsamer oder schlechter als wenn du direkt in Assembler schreibst und auserdem kannst du wie gesagt Assembler-Routinen einbinden.
Ich glaube, wenn dein Programm umfangreicher wird, könnte es schon sinnvoll sein, wenn du nicht alles komplett in Assembler machen musst - aber das ist vielleicht auch nur Geschmacksache.
2. Wenn ich es richtig verstanden habe kommunizieren die Entwicklungsumgebungen alle mit RN-Control über die RS232 und laden Daten und Programme über die ISP-Schnittstelle.
Die Entwicklungsumgebungen erstellen aus deinem Programm ein File, dass dann über die ISP-Schittstelle in den Controller übertragen wird. AVR-Studio und Bascom enthalten die Möglichkeit dieses File direkt aus der Entwicklungsumgebung hochzuladen, du kannst das File aber auch mit einem anderen Programm hochladen.
Die Kommunikation über die RS232 hat eigentlich gar nichts mit der Enwicklungsumgebung zu tun.
In den Entwicklungsumgebungen sind teilweise Terminal-Programme enthalten, aber du kannst mit jedem beliebigen Terminal-Programm über die RS232 mit deinem Controller kommunizieren.
Beim Einsatz von Studio 4 soll das ISP-Kabel von Robotikhardware das an das lpt im pc angeschlossen wird nicht geeignet sein, gibt es Unterlagen wie ein passendes Kabel wäre, oder müßte man eines direkt von Atmel beziehen? Wenn ja, welches und ist das auch bei Conrad zu erwerben?
Es gibt im Netz Schaltpläne für eine ganze Menge verschiedene ISP-Adapter. Da findest du bestimmt auch irgendeinen der mit AVR-Studio zusammenarbeitet. Fertig kaufen kann man einen entsprechenden Adapter sicherlich nicht nur bei Atmel direkt. Ich weiss allerdings nicht, ob man ihn bei Conrad bekommt oder wo sonst.
Guck dich mal auf www.mikrocontroller.net im Forum um. Dort treiben sich eine Menge Leute rum die offensichtlich auch beruflich mit der Programmierung von Controllern zu tun haben. Da kann dir bestimmt jemand sagen, welcher ISP Adapter mit AVR-Studio funktioniert, wo man ihn herbekommt und vor allem - was überhaupt die Vorteile von einem solchen komplzierteren und teureren ISP-Adapter sind.
Im Prinzip kannst du wie gesagt auch in AVR-Studio programmieren und das Programm dann mit Ponyprog, Yaap oder irgendeinem anderen Tool das mit dem ISP-Adapter von Robotik-Hardware zurechtkommt in den Controller hochladen.
3. Die Spanungsversorgung des RN-Controlls kann beliebig zwischen 7V und 18V liegen, die Karte erzeugt daraus ihre benötigten 5V und stellt diese auch an einem Ausgang für andere Module zur Verfügung?
Auf dem RN-Control ist ein Spannungsregler drauf, der mit Eingangsspannungen von 7 - 18V zurechtkommt. Eventuell kannst du den auch gegen einen Low-Drop Regler der noch bis 6V klarkommt austauschen.
Die geregelte 5V Spannung kannst du für andere Module am RN-Control entnehmen und es dabei insgesamt bis 2 Ampere belasten.
Frage dazu ist das korrekt und gleicht die Logik auf der Karte auch einen Spannungsabfall am NimH-Akkus aus? Voll geladen hat ein Akku-Pack aus 10 Mono-D-Zellen 14V und kann bis auf leicht über 10V abfallen! Habe das richtig verstanden, die RN-Control kann die Akku-Spannung überwachen und trotz Spannungsabfall die 5V bereitstelllen soweit die Spannungsquelle nicht unter 7V fällt?
Der Spannungsregler (ein einfaches simples Bauteil mit 3 Pinnen) auf dem RN-Control und macht aus jeder Spannung zwischen 18V und 7Volt eine geregelte 5V Spannung die für die Versorgung des RN-Control geeignet ist. Solange dein Akku noch 7 Volt und genug Strom liefert hat das RN-Control also keine Probleme.
Zusätzlich besteht beim RN-Control die Möglichkeit die Batteriespannung per Software zu überwachen.
Wenn du 14 NiMH Akkus verwendest, stehen die bei 7 Volt ja schon kurz vor der Tiefentladung und je nachdem was alles dran hängt, liefern die vermutlich nicht mehr genug Strom um einen einwandfreien Betrieb zu gewährleisten. (auserdem nehmen NiMH Akkus einem das auf Dauer vermutlich auch übel).
Über die Spannungsüberwachung des RN-Control könntest du in deinem Programm z.B. dafür sorgen, dass das Boot bei einem Spannungsabfall auf 12 Volt die Sonnenkollektoren ausfährt oder sich auf den schnellsten Weg ans nächste Ufer begibt.
4. Gibt es auch die Möglichkeit die Schaltung der RN-Control elektronisch zu bekommen um diese für einen mega128 im QFP-Gehäuse anzupassen?
Ob du das Eagle-Layout bekommen kannst weiss ich nicht.
So wie ich deine Frage verstehe würde dir das aber auch nicht so viel nutzen.
Das RN-Control wurde nach Wünschen und Anregungen der User hier im Forum entwickelt. Dabei hat man sich zuerst für die Platinengrösse und den Controller entschieden. Anschliessend wurde dann der freie Platz auf der Platine mit Features die sich viele Leute gewünscht haben gefüllt.
D.h. auf dem Board sind viele Dinge drauf, die man als Einsteiger für erste Experimente nutzen kann, die man aber auf einer reinen Steuerplatine bei der man auch noch Platz sparen will eher weglässt.
In deinem Segelboot wird ja vermutlich niemand sitzen, der später LEDs abliest und Taster bedient ;-)
Ich glaube um dich einzuarbeiten, und Programmteile zu entwickeln ist das RN-Control so wie es ist bestens geeignet.
Wenn du eine eigene Platine für einen anderen Controller und ganz speziell für deine Bedürfnisse entwickeln willst, ist es glaube ich einfacher das Layout komplett selber zu entwickeln.
Die Grundschaltung für die AVRs findet man zig-fach im Netz (auch hier im Forum), spezielle Features der einzelnen AVR-Typen sind in den Datenblättern dokumentiert und einzelne Teile des RN-Controls kann man auch aus dem Schaltplan in ein eigenes Layout übernehmen.
5. Gibt es Erfahrungen mit der Implementation von WLAN?
Soweit ich den Überblick habe, würde hier im Forum mehrfach von verschiedenen Leuten die Meinung geäussert, dass WLAN nicht besonders gut in eine Microcontroller-Schaltung zu implementieren ist.
Irgendwie ist aber fast alles möglich. Besonders gut vorstellen kann ich mir das allerdings nicht. WLAN ist ja nicht nur Hardware, sondern auch viel "Protokoll". Die WLAN-Treiber für die diversen PC-OS dürften einen Microcontroller alleine von der Speichergrösse schon überfordern (falls man das überhaupt vergleichen kann).
Der niedrigste WLAN-Standard ist soweit ich weiss 11MBit/s, das dürfte selbst bei einem mit 16Mhz getakteten ATMega eng werden, vor allem wenn der die Daten auch noch irgendwie erfassen und verarbeiten soll.
Die meisten WLAN Adapter schliesst man über USB oder PCI-Bus an, das irgendwie auf Microcontroller umzusetzen dürfte auch nicht ganz einfach sein.
Ich habe allerdings zwei WLAN-USB Adapter und eine WLAN PCMCIA-Karte die auf einen Atmel-Chip aufbauen. Da Atmel auch der Hersteller der AVRs ist, gibt es da vielleicht schon "irgendwas". Vielleicht findest du ja auf www.atmel.com irgendwelche Infos und Hinweise.
Alternativ reicht vielleicht auch erst mal eine serielle Funkverbindung, z.B. über Addlink Module.
WLAN ist ja eigentlich mehr was für die schnelle Übertragung von grossen Datenmengen.
6. Wie lange dauerst es von der Bestellung bis zum Erhalt der RN-Control?
Das dürfte davon abhängen, ob die Teile vorrätig sind. Robotik-Hardware lässt die Platinen ja extra nach Bedarf in Kleinserie anfertigen und stellt die Bauteile entsprechend zusammen.
Wenn die Sachen vorrätig sind, gehts schnell. Ich habe 2 mal bestellt und per Überweisung gezahlt. Da hat Robotik-Hardware die Ware noch an dem Tag an dem das Geld einging rausgeschickt.
Was sollte man außer der reinen karte hinzu bestellen?
Auch wenn er in AVR-Studio nicht funktioniert, würde ich mir erst mal den ISP-Adapter dazubestellen. So teuer ist der ja nicht und wenn du Ponyprog, Yaap oder irgendein anders Programm zum hochladen benutzt, kannst du damit jedenfalls schon mal gleich loslegen.
Ob du dir später dann noch einen anderen ISP-Adapter kaufst oder baust, kannst du dann ja immer noch überlegen.
Akkus zur Stromversorgung hast du offensichtlich ja schon, ansonsten könntest du dir auch erst mal noch das Steckernetzteil bestellen.
Das serielle Kabel würde ich mir eventuell auch noch bestellen, da da der 3-polige Stecker für das RN-Control schon dran ist.
Die Räder sind für eine Segelbot vermutlich nicht so interessant, ein paar Neigungsschalter vielleicht schon eher ;-)
Beim Einsatz von Studio 4 soll das ISP-Kabel von Robotikhardware das an das lpt im pc angeschlossen wird nicht geeignet sein, gibt es Unterlagen wie ein passendes Kabel wäre, oder müßte man eines direkt von Atmel beziehen? Wenn ja, welches und ist das auch bei Conrad zu erwerben?
Es gibt im Netz Schaltpläne für eine ganze Menge verschiedene ISP-Adapter. Da findest du bestimmt auch irgendeinen der mit AVR-Studio zusammenarbeitet. Fertig kaufen kann man einen entsprechenden Adapter sicherlich nicht nur bei Atmel direkt. Ich weiss allerdings nicht, ob man ihn bei Conrad bekommt oder wo sonst.
Genau. Den Original Atmel-ISP-Adapter gibt es als Appnote auf der Atmelhompage. Allerdings stecken da ein 8535 und ein 1200 drin. Die müssen auch erst mal programmiert werden. Henne-Ei Problem.
Aber es gibt im Netz zig verschiedene ISP-Adater von der Schaltung mit 3 o. 4 Widerständen, bis zum komplizierterem mit uC.
Ich benutze die Version mit einem 74244HCT am LPT, 10pol. Version. Funktioniert prächtig. Allerdings auch nicht mit dem AVR-Studio. Aber die Hexfiles brenne ich eh mit Ponyprgog.
Schaltung für den ISP-Adapter http://rumil.de/hardware/avrisp.html
Statt des 74244HC unbedingt den 74244HCT nehmen!
3. Die Spanungsversorgung des RN-Controlls kann beliebig zwischen 7V und 18V liegen, die Karte erzeugt daraus ihre benötigten 5V und stellt diese auch an einem Ausgang für andere Module zur Verfügung?
Korrekt. Allerdings haben die "Drop"-Regler die Eigenschaft nicht besonders wirtschaftlich mit Energie umzugehen. Bei einem RC-Modell kann das die Fahrzeit ziemlich heruntersetzen. Je nach dem könnte es sich lohnen einen Schaltwandler mit besserem Wirkungsgrad zu verwenden.
Frage dazu ist das korrekt und gleicht die Logik auf der Karte auch einen Spannungsabfall am NimH-Akkus aus?
Jaein. Auf dem Board sitzt ein Spannungsregler. Das ist ein kleines Bauteil. Eine Logik hat das nicht. Die Spannung wird soweit ich weiß auf 5V geregelt. Dazu braucht es am Eingang aber immer ein bisschen mehr. so ca. 7V. Bei besseren Reglern vielleicht auch blos 6V.
Die Überschüssige Energie fällt aber voll als Verlustleistung über dem Regler ab. Bsp. Voller Akku 12V, benötigter Strom 500mA, bisschen was angeschlossen, dann fallen über dem Regler 12V-5V = 7V ab. 7V*0,5A = 3,5W Verlust. Wobei das eigentliche Board nur 5V*0,5A = 2,5W benötigt.
Bei 7Vakku sind's dann nur noch 2V*0,5A = 1W über dem Regler.
4. Gibt es auch die Möglichkeit die Schaltung der RN-Control elektronisch zu bekommen um diese für einen mega128 im QFP-Gehäuse anzupassen?
Ob du das Eagle-Layout bekommen kannst weiss ich nicht.
Glaube ich auch nicht, wäre auch unfair Frank gegenüber. Der hat ja schließlich den ganzen Streß. Aber die Grundschaltung der AVR's ist wirklich sehr simpel. Die besteht eigentlich nur aus Spannungsversorgung und Takt, plus ISP-Stecker, +Resetknopf. Insgesamt vielleicht 10 Bauteile.
Echt nicht kompliziert.
Alles andere hängt von der Anwendung ab. Das ist aber auch nicht schwerer.
5. Gibt es Erfahrungen mit der Implementation von WLAN?
Soweit ich den Überblick habe, würde hier im Forum mehrfach von verschiedenen Leuten die Meinung geäussert, dass WLAN nicht besonders gut in eine Microcontroller-Schaltung zu implementieren ist.
[..]
Alternativ reicht vielleicht auch erst mal eine serielle Funkverbindung, z.B. über Addlink Module.
WLAN ist ja eigentlich mehr was für die schnelle Übertragung von grossen Datenmengen.
Würd ich auch sagen. WLAN ist nicht sehr sinnvoll bzw. oversized für die Aufgabe. Addlink könnte eine Lösung sein. Allerdings weiß ich nichts über die Reichweite.
Gruß, Sonic
Hallo Freunde
ich möchte mich für die ausführlichen Antworten auf meine Fragen bedanken. Hier dazu:
betr. "recycle"
Deiner Antwort entnehme ich das das Studio 4 und PonyProg als Entwicklungsumgebung für Assembler Programmierung passen. Es gibt auch bei Atmel noch den GCC C- Compiler als Demo
Wenn man beim "debuggen" die Inhalte der Register ansehen möchte, bieten die Entwicklungsumgebungen hierfür das Werkzeug? Dafür müßte doch auf dem mega16/32 doch ein Monitor Programm sein welches auf Befehle der Entwicklungsumgebung Registerinhalte und/oder Memory Dumps an die Entwicklungsumgebung schickt? Das scheint doch nicht der Fall zu sein, oder? Das würde bedeuten das solche Funktionen nur in der Simulationsumgebung bereit stünden, richtig?
Was den sinnvollen Bestellumfang angeht entnehme ich folgendes:
1. RN-Control
2. ISP-Kabel
3. Falls ich kein Netzteil mit Gleichspannung zwischen 7V und 18V habe, dann das dort angebotene Netzteil was sicher den richtigen Stecker fürs RN-Control hat.
WLAN macht keinen Sinn da zu komplex. Wie kann man dann Telemetriedaten ans Ufer schicken? Entfernung bis 100m?
Betr. "sonic"
Hinweis auf das "verbraten" der Leistung in den "Drop"-Reglern klingt sehr überzeugend. Wozu viel Geld für leistungsstarke Akku-Packs wenn dann doch ein Großteil nur verheizt wird.
Frage zum Thema Schaltwandler, sind die hier entstehenden DC-Spannungen nicht arg wellig? Das würde also bedeuten um die Wandlung effizient zu gestalten das man mit einem Schaltwandler die 12V auf 4,8V plus z.B.1,5-2v zum Kompensieren des Drop bei einem Linearwandler wie den LT1083, also Schaltwandler auf circa 7V und dann mit LT1083 auf z.B 4,8V. Entsprechen für meine 6V und meine 7,2V?
Soweit zu Euren Antworten, hier noch eine Zusatzfrage: Wenn ich extern "memory mapped" Adressen haben wollte für Peripherie-Funktionen so gibt es bei den mega16/32 keinen herausgeführten Adressbus?
Sprich man müßte Digital I/O-Ports benutzen um diese extern wie Adressen zu dekodieren? Richtig? Beim mega64/128 sind ja welche vorhanden da er externes adressieren explizit unterstützt! Wobei die Behelfslösung für die mega16/32 zwar langsamer wären aber vom externen timing idiotensicher. In beiden Fällen werden ja alternativ benutzbare Ports eingesetzt. Beim mega 64/128 PA0-7 bei den kleinen Benutzer definiert plus Steuer Leitungen.
Wenn Frank einen RN-Control für den mega128 im Herbst hätte wäre das sicher kein Beinbruch jetzt mit dem Gegenwärtigen zu beginnen.
Ich gebe zu ich scheue mich selber eine solche Karte zu machen wenn bis zum Winter eine mit dem mega128 zu ähnlichen Konditionen wie die RN-Control bereit stehen könnte. Ich könnte mich dann dem Vertraut machen und dem Entwerfen des Codes widmen. Da geht die Zeit lokker vorüber. ich muß Frank recht geben das kleine Karten mit der mega8 absolut sinn machen, die man dann dezentral für spezialisierte Funktionen nutzt.
Übrigens ist das Interesse im Forum Schiffsmodellbau konkretisiert und ich habe bereits mit Kollegen Kontakt aufgenommen. Dabei verfechte ich den Standpunkt uns an die hier erstellten Definitionen anzuhängen um gegenseitig Synergien zu ermöglichen. Das ist doch hoffentlich hier OK?
Übrigens als Mitglied des Forums und "Bauernder" von "schwimmenden" Robotern danke ich für die Hinweise betreffs Nutzungsmmöglichkeiten anderer hier entwickelter Funktionen. Ernsthaft, habt Ihr hier schon mit GPS gearbeitet? Es gibt ja immer mehr anbieter von GPS IC`s.
Mit freundlichem Gruß
Hellmut
Hallo Freunde
ich möchte mich für die ausführlichen Antworten auf meine Fragen bedanken. Hier dazu:
kein Ding ;-)
[..]
Betr. "sonic"
Hinweis auf das "verbraten" der Leistung in den "Drop"-Reglern klingt sehr überzeugend. Wozu viel Geld für leistungsstarke Akku-Packs wenn dann doch ein Großteil nur verheizt wird.
Frage zum Thema Schaltwandler, sind die hier entstehenden DC-Spannungen nicht arg wellig? Das würde also bedeuten um die Wandlung effizient zu gestalten das man mit einem Schaltwandler die 12V auf 4,8V plus z.B.1,5-2v zum Kompensieren des Drop bei einem Linearwandler wie den LT1083, also Schaltwandler auf circa 7V und dann mit LT1083 auf z.B 4,8V. Entsprechen für meine 6V und meine 7,2V?
Sollte funktionieren, aber normalerweise ist im DC-Wandler ja auch ne Regelung.
Restwelligkeit ist natürlich immer vorhanden, aber ich schätze mal bei angemessener Last so irgendwas um die 1mV, je nach Schaltung.
Bei LT auf der Homepage gibt's ne Seite auf der man sich nen "Simple Switcher" berechnen lassen kann. Schau mal mit der Suche auf deren Homepage nach "simple switcher".
Soweit zu Euren Antworten, hier noch eine Zusatzfrage: Wenn ich extern "memory mapped" Adressen haben wollte für Peripherie-Funktionen so gibt es bei den mega16/32 keinen herausgeführten Adressbus?
Sprich man müßte Digital I/O-Ports benutzen um diese extern wie Adressen zu dekodieren? Richtig? Beim mega64/128 sind ja welche vorhanden da er externes adressieren explizit unterstützt! Wobei die Behelfslösung für die mega16/32 zwar langsamer wären aber vom externen timing idiotensicher. In beiden Fällen werden ja alternativ benutzbare Ports eingesetzt. Beim mega 64/128 PA0-7 bei den kleinen Benutzer definiert plus Steuer Leitungen.
Hab noch nix mit externem Speicher gemacht, aber ich glaube es gibt auch Speicher-IC's die per I²C angesprochen werden. Wäre vielleicht was.
Alternativ gibt's auch Seiten über die Anbindung von CFlash-Karten an uC von Atmel, usw.
[..]
Übrigens ist das Interesse im Forum Schiffsmodellbau konkretisiert und ich habe bereits mit Kollegen Kontakt aufgenommen. Dabei verfechte ich den Standpunkt uns an die hier erstellten Definitionen anzuhängen um gegenseitig Synergien zu ermöglichen. Das ist doch hoffentlich hier OK?
Glaube nicht das jemand was dagegen hat ;-) Frank freut sich bestimmt über einen neuen Markt für die RN-Boards.
Übrigens als Mitglied des Forums und "Bauernder" von "schwimmenden" Robotern danke ich für die Hinweise betreffs Nutzungsmmöglichkeiten anderer hier entwickelter Funktionen. Ernsthaft, habt Ihr hier schon mit GPS gearbeitet? Es gibt ja immer mehr anbieter von GPS IC`s.
Mit freundlichem Gruß
Hellmut
GPS ist relativ einfach wenn:
1. ein fertiges Gerät/Modul mit serieller Schnittstelle verwendet wird.
2. und man das NMEA-Protokoll im uC implementieren kann.
Ist fast schon Klartext ;-)
Gruß, Sonic
Hallo sonic
muß deine Antwort erst durcharbeiten, hier aber nur betreffs des Adressbusses. Mir geht es hierbei nicht um Speicherzugriff sondern um Zugriff auf ein Peripherie IC. Praktisch ist es so wenn eine bestimmte Adresse vom Controller an den Adressbus gelegt wird, so wird diese durch ein PAL z.B. dekodiert und ein Chip-Select ausgelöst. Dadurch kann man dann den Inhalt von "Registern" am Datenbus vorfinden und rein laden. vergiss nicht, als ehemaliger MC6809 fan bin ich "memory mapped I/O gewöhnt.
Hallo sonic
muß deine Antwort erst durcharbeiten, hier aber nur betreffs des Adressbusses. Mir geht es hierbei nicht um Speicherzugriff sondern um Zugriff auf ein Peripherie IC. Praktisch ist es so wenn eine bestimmte Adresse vom Controller an den Adressbus gelegt wird, so wird diese durch ein PAL z.B. dekodiert und ein Chip-Select ausgelöst. Dadurch kann man dann den Inhalt von "Registern" am Datenbus vorfinden und rein laden. vergiss nicht, als ehemaliger MC6809 fan bin ich "memory mapped I/O gewöhnt.
Ok, ich hab gedacht dir geht es nur um extra Speicher. An was hast du da gedacht das du sogar extra ein Pal einsetzen willst? PAL klingt nach großem Bus + viel Kabel + GlueLogic ;-)
By the Way, ich kann zwar schon verstehen das du Asembler benutzen möchtest - Aber schau dir trotzdem mal auf alle Fälle die Doku von Bascom an. Da sind wirklich schon viele Sachen implementiert die dir einen Haufen Zeit sparen könnten. Als ich gesehen hab das es sogar nen Befehl gibt um einen Servo an einem Pin anzusteuern habe ich schon ein bisschen gestaunt. Ich weis, Basic...aber in dem Fall zu empfehlen ;-)
Bez. Stromversorgung - Gerade gefunden und genau das Richtige:
http://horst-lehner.mausnet.de/efaq/kapitel/Stromversorgung.html
Gut's Nächdele,
Sonic
betr. "recycle"
Deiner Antwort entnehme ich das das Studio 4 und PonyProg als Entwicklungsumgebung für Assembler Programmierung passen. Es gibt auch bei Atmel noch den GCC C- Compiler als Demo
Ja, AVR Studio kannst du für die Programmentwicklung in Assembler nutzen und Ponyprog um das Programm in den Controller hochzuladen.
Es gibt auch bei Atmel noch den GCC C- Compiler als Demo
Das dürfte dasselbe sein, das ich in meinem vorherigen Post als WinAVR bezeichnet haben.
GCC ist der "GNU C Compiler" ein Opensource Compiler für C .
WinAVR ist eine Opensource Entwicklungsumgebung für AVR Controller auf Basis des GCC.
Wenn bei Atmel was von "GCC-Demo" steht, verstehe ich das allerdings nicht ganz, wer will schon eine Demo, wenn die Vollversion Opensource und kostenlos ist.
Wenn man beim "debuggen" die Inhalte der Register ansehen möchte, bieten die Entwicklungsumgebungen hierfür das Werkzeug? Dafür müßte doch auf dem mega16/32 doch ein Monitor Programm sein welches auf Befehle der Entwicklungsumgebung Registerinhalte und/oder Memory Dumps an die Entwicklungsumgebung schickt? Das scheint doch nicht der Fall zu sein, oder? Das würde bedeuten das solche Funktionen nur in der Simulationsumgebung bereit stünden, richtig?
Erst mal vorweg - besonders gut kenn ich mich damit nicht aus und ich habe mir die Simulationen auch noch nie genauer angesehen.
Es handelt sich dabei aber um eine reine Software-Simulation die du auch ohne Controller verwenden kannst. Folglich kommst du natürlich nicht an die echten Registerinhalte ran, sondern die sind auch nur Teil der Simulation.
Einige AVRs kann man über einen speziellen Adapter aber auch zur Laufzeit direkt im Controller debuggen. Da kommst du dann an die echten Registerinhalte ran. Genaueres kann ich dir da nicht zu sagen, aber du kannst ja mal nach "avr jtag" googeln.
Was den sinnvollen Bestellumfang angeht entnehme ich folgendes:
1. RN-Control
2. ISP-Kabel
3. Falls ich kein Netzteil mit Gleichspannung zwischen 7V und 18V habe, dann das dort angebotene Netzteil was sicher den richtigen Stecker fürs RN-Control hat.
Der Stecker vom Netzteil passt nicht, den kannst du aber einfach abschneiden. Das RN-Control hat Schraubklemmen für die Spannungsversorgung.
Das Netzeil würde ich natürlich nur kaufen, wenn du nichts vergleichbares hast. Da reicht ja auch alles, was zwischen 7 und 18 Volt Gleichspannung und genug Strom liefert.
Theoretisch kannst du auch deine Akkus nehmen. Das würde ich aber nicht machen. Beim Experimentieren baut man (ich jedenfalls) immer mal einen Kurzschluss. So ein Akkupack aus dem Modellbau liefert dann aber soviel Kurzschlussstrom, dass von deiner Schaltung nur noch Asche übrig bleibt.
Bei meinem Steckernetzteil habe ich es bisher immer noch rechtzeitig gerochen und und konnte den Stecker ziehen bevor was kaputt ging.
Man könnte natürlich auch eine Sicherung einbauen ;-)
WLAN macht keinen Sinn da zu komplex. Wie kann man dann Telemetriedaten ans Ufer schicken? Entfernung bis 100m?
Die Addlink Module von Conrad kosten im 2er Set kanpp 50 Euro, funktionieren im Prinzip wie ein drahtloses serielles Kabel und haben laut Herstellerinfo eine Reichweite von 300m und eine Datenübertragungsrate von 10kbit/s.
Für Telemetriedaten und 100m Reichweite auf dem Wasser könnte das doch reichen. (zu den Addlink Modulen gibt es hier einen eigenen Thread)
Was Spannungswandler und Energierverschwendung angeht:
Her gibt es einen Schaltplan mit Beschreibung für eine Schaltnetzteil: http://www.kreatives-chaos.com/index.php?seite=schaltnetzteil
Ich habe aber schon von Leuten gehört, die Probleme wegen hochfrequenten Störungen in der Spannungsversorgung durch Schaltnetzteile hatten.
Ich würde auf jeden Fall 2 getrennte Spannungsversorgungen für Motoren und Elektronik in Betracht ziehen.
Wenn Elektromotoren mal blockieren, z.B. weil sie sich verheddern, kommt je nach Motor zu grossen Stromspitzen und Spannungseinbrüchen. Wenn der Controller dann wegen so einen kurzzeitigen Spannungseinbruch abstürzt wäre das etwas ungünstig, denn der soll ja eigentlich reagieren und schlimmeres verhindern wenn sich ein Motor verheddert.
Wenn Platz genug da ist, könnte man für die Elektronik z.B. 6 Mignon Akkus nehmen. Da kommt man auf ca. 7,2 Volt und die Verlustleistung im Spannungsregler hält sich in Grenzen.
Solange die Versorungsakkus für die Elektronik länger halten als die Hauptversorgung für Motoren usw. machts eigentlich auch nichts, wenn die ein bischen Energie verschwenden.
Was externen Speicher angeht, habe ich leider überhaupt keine Ahnung. Ich habe aber bisher auch noch nie gehört, dass jemand bei den ATMegas Probleme hatte, weil der Speicher zu klein für das Programm war.
Daten die einfach nur erfasst und abgespeichert werden sollen, könnte man z.B. auch über Addlink-Module an ein Notebook schicken.
Ich habe hier im Forum zwar auch schon gelesen, dass man an einige AVR-Controller recht einfach Speichererweiterungen anschliessen kann, aber das bewegte sich dann meist auch nur in Grössen von einigen kB.
Ich glaube da könnte man auch einfach einen weiteren Controller als Speichererweiterung missbrauchen - irgendwann findet sich dann wahrscheinlich auch noch was womit man ihn beschäftigen kann.
An deiner Stelle würde ich mir erst mal das RN-Control kaufen.
Um den Einstieg zu finden und die einzelnen Komponenten zu entwickeln reicht ein ATMega16 oder 32 sicherlich erst mal aus.
An dem RN-Control hast du wenigstens auch schon Taster, LEDs, Summer, Motortreiber usw. D.h. selbst wenn du für dein eigentliches Projekt später eine andere Platine mit einem anderen Controller verwendest wirst du es zum Entwickeln und Testen weiterverwenden können.
Wenn man erst mal was in den Fingern hat mit dem man rumexperimentieren und ausprobieren kann, lässt sich auch viel besser weiterplanen.
Hallo Freunde
habe gerade bei Roboterhardware meine Bestellung eingeben wollen. Beim drücken auf absenden kam "Seite kann nicht erreicht werden" und dann kam ich garnicht mehr ins Internet. Alte Microsoft Erfahrung, Neustart und bin wieder drin.
Da Frank hier ja auch vorbei kommt, nochmals bestellen oder was?
habe gerade bei Roboterhardware meine Bestellung eingeben wollen. Beim drücken auf absenden kam "Seite kann nicht erreicht werden" und dann kam ich garnicht mehr ins Internet. Alte Microsoft Erfahrung, Neustart und bin wieder drin.
Da Frank hier ja auch vorbei kommt, nochmals bestellen oder was?
Bei der Fehlermeldung "Seite kann nicht erreicht werden" würde ich davon ausgehen, dass deine Bestellung nicht bei Robotik-Hardware angekommen ist.
Schreib Frank doch einfach eine PN, er wird dir dann schon sagen wie du am besten fortfährst.
Hi,
hab den Thread gerade erst gesehen. Jetzt kann ich Helmuts Fragen per PM auch etwas besser zuordnen. Da hat Helmut ja ein mächtiges Schiffsprojekt vor. Das dürfte ganz schön aufwendig werden. Im Endeffekt wird man vermutlich sogar mehrere Controller brauchen um das alles auf die Reihe zu bringen.
Ich denke man muss bei den Controllern eh etwas von den Gedanken weg kommen das ein Controller alles macht. Wesentlich günstiger sind oft mehrere kleine bis mittlere Controller. Dann hat man echtes Multitasking!
Hab gerade noch eine Art RN-Control mit Mega8 gebastelt. Das wird dann aber simpel RN-Mega8 heißen und wird mehr für kleinere spezielle Aufgaben Verwendung finden. Man kann es als Master oder Slave betreiben (wie auch RN-Control), kann also auch gut mit den bestehenden Boards kombiniert werden. Wenn alles ausgetestet ist stelle ich es kurz vor. Ist glaub ganz gut geworden.
Gruß Frank
Hallo Hellmut!
Ich hab ein wenig in euerm Modellbau-Forum gelesen.
Respekt das du als absoluter Nichtsegler dir solche Gedanken machst (z.B. Holepunkt der Fock).
Ich bin Jollensegler und will mir ein Modellsegelboot bauen und es ebenfalls mit einem Controller steuern.
------------------
Ich will aber etwas wie das M-Boot bauen, evtl. grösser. (kein Langkieler)
Ich denke, das ich eine Fernlenkanlage zusätslich einbauen will, um nicht ständig in ein grosses Boot springen zu müssen, wenn sich der Controller aufhängt.
Wie ich das realisieren kann, weiss ich noch nicht.
Wenn du Tips aus der Praxis zum Trimm brauchst, kannst du mir ne PM schicken (denke da werde ich per Mail benachrichtigt).
-----------------
Inzwischen bin ich vom programmieren einer Controll mit Delphi abgekommen.
Ich denke ich werde Bascom nehmen.
Und die RN-Controll mit dem Mega 32.
@Frank
Ist es evtl. geplant einen Mega 128 in eine RN-Controll zu packen?
Bzw. wie kompliziert ist es zwei oder mehrere RN-Controlls (Mega 32) parallel laufen zu lassen?
(Ich will da einen GPS, einen Elektronischen Kompass, eine Windfahne, einen Speedometer (evtl. über GPS), einen Neigungsmesser/Krängungsmesser, einen Windgeschwindigkeitsanzeiger einbauen.
Evtl. eine Optik um Regattatonnen zu finden, bzw. Ausweichmanöver fahren zu können.
Ich vermute das da so viel an Daten zusammenkommt, das da eine ganze Reihe von Mega 32 arbeiten muss.
-------------------
Ach ja: Meine 'Vorbildung': ich kann einigermassen in Delphi programieren. Regattasegler auf Jollen und Jachten.
Keine Ahnung von Elektronik.
Und gebaut habe ich das Modellboot auch noch nicht.
Danke!
Gruss!
mir mich
@Frank
Ist es evtl. geplant einen Mega 128 in eine RN-Controll zu packen?
Bzw. wie kompliziert ist es zwei oder mehrere RN-Controlls (Mega 32) parallel laufen zu lassen?
(Ich will da einen GPS, einen Elektronischen Kompass, eine Windfahne, einen Speedometer (evtl. über GPS), einen Neigungsmesser/Krängungsmesser, einen Windgeschwindigkeitsanzeiger einbauen.
Evtl. eine Optik um Regattatonnen zu finden, bzw. Ausweichmanöver fahren zu können.
Ich vermute das da so viel an Daten zusammenkommt, das da eine ganze Reihe von Mega 32 arbeiten muss.
Hi mirmich,
ja als vervollständigung der Boardauswahl soll auch noch ein kompatibles Mega128 Board kommen. Insbesondere für erfahrenere User die schon den Einsteig in die Atmel Welt gefunden haben, dürfte dieses Board dann sicher interessant werden. Controller hab ich schon für Experimente besorgt. Aber das dauert vermutlich noch ein paar Monate weil ich erst noch ein paar andere Zusatzboards fertig mache und auch erst ein paar mehr praktische Erfahrungen von RN-Control machen und bobachten möchte. Das kann man dann immer beim nächsten Board berücksichtigen.
Das parallel laufen von mehreren Boards ist in den meisten Fällen unkompliziert. Die Kommunikation kann per RS232 oder I2C erfolgen. Das i2C Kabel ist oft ganz hilfreich, da hier auch die Stromversorgung drüber laufen kann (spart oft Kabelsalat).
Das Board das Daten empfängt mus bei I2C als Slave programmiert werden. Da gibt es noch nicht so sehr viel Programmcode für. Aber daran arbeiten derzeit viele und Routinen werden sicher bald in Bascom (Basic) bereitstehen. Für C gibt es nach meinem Wissen schon fertige Libarys. Da wird dann einfach eine Interrupt-Routine aufgerufen wenn ein oder mehrere Bytes ankommen. Also nicht weiter schwierig.
Mehrere Controller sind immer dann sinnvoll, wenn mehrere Prozesse ein ganz genaues enges Timing benötigen. Ein simples Beispiel ist die Ansteuerung von 10 oder mehr Servos. Zwar kann man das mit jedem AVR Controller, aber das Timing belastet den Controller schon erheblich, er kann nebenher nicht mehr schnell genug andere Interupts ausführen ohne das dieses Timing gestört wird. Daher ist es bei solchen Dingen sinnvoll die Servosteuerung einem eigenen Controller zu überlassen und ihm nur die Befehle für die Positionierung per I2C oder RS232 zu übergeben. So wurde es ja bei unserem RNBFRA-Board gemacht, wo der Co-Controller diese Servoaufgabe übernommen hat.
Aber man kann ja immer erst mit einem Controller beginnen und wird schon selbst merken wenn es an einer Stelle harkt. Das kann man dann immer noch auslagern.
Gruß Frank
Hallo Frank
planst Du die Funktionalität der Rn-Control X mit mega128 hier im Forum zu diskutieren? Du weist über mein spezielles Thema herausgeführten Adressbus bescheid. Ich möchte dabei hervorheben das ich nicht genügend Erfahrung habe um zu sagen wie man das sinnvoll implementiert. Da die RN-Control möglichst kompakt bleiben soll, einfach Europakartenformat ist schon das höchste der Gefühle, müßte man Piggyback-Karten die man selber macht auf Steckern verbinden können. Dabei kommt das von mir hier schon woanders angesprochene Thema Störstrahlungen und Verlustwärmeableitungen auf. Wie siehst du das? Ansonsten finde ich es, obwöhl ich auf eine solche Karte warte, richtig und wichtig auf die Felderfahrungen der jetzigen zu warten.
Betreff "verteiltes Processing", also nicht alles auf einer Controllerkarte machen hab ich noch Bemerkungen und Fragen:
1. Kann man, und wenn wie, Bidirektional I2C-Buskommunikation mit den megaxxx machen? Das heißt, angenommen, default ist die "Zentrale" RN-Karte Master, die Daughterboards Slave, was wenn eine Slave-Karte eine Kommunikation anstoßen will? Gibt es im I2C-Protokoll Verahren durch welche die Busmasterposition von einer anderen Karte übernommen werden kann?
Der Grund für diese Frage kommt auch aus der Perspektive Ausfallsicherheit und Fail-Safe.
Ich würde hier gerne einen weiteres wichtiges Argument für "verteilte" Aufgaben im System vorbringen. In meinem Boot kann es ja ohne weiteres passieren das etwas aus Gründen von Feuchtigkeit, mechanischer Fehlfunktion oder Kurzschluß ausfällt. Um in diesem Fall das Boot sicher ans Ufer zu bringen ist es sehr hilfreich Subsysteme möglichst von einander unabhängig zumachen.
Übrigens, ein Mega8 RN-Control halte ich mit verlaub gesagt nicht sehr sinnvoll. Das RN-Control hat einen Preis und eine Größe bei welcher der Controller-Preis eine marginale Bedeutung hat. Produktvielfalt möglichst gering zu halten ist aus vielen Gründen, technischer wie kaufmännischer Sicht, weise. Der Mega8 ist jedoch als I2C-Subsystem ideal. Und natürlich muss man auch dort RS232 und ISP zur Verfügung haben. Aber die Mega 8 Karten sollten jedoch Funktionsoptimiert sein.
Wie ich an anderer Stelle schon dokumentiert habe plane ich in meinem Boot stark dezentral aus den genannten Gründen zu arbeiten. Ich habe dort bereits einige I2C-Karten genannt:
1. Eine geregelte möglichst geringwellige einstellbare Buck-Schaltreglerkarte mit Linearregler zur Glättung. Der Mega 8 soll dort Überwachungsfunktionen und Failsafefunktionen ausführen und Statusmeldungen für die "Zentrale" bereitstellen. Weiterhin muß diese Karte programmierbar sein. Kurz hierzu:
Der Schiffsmodellbauer, und das ist für den Roboterfreak sicher auch zutreffend, der muß am See, Roboter irgendwo sonst, doch an seinem Gerät rumtrimmen und justieren. Hierzu schwebt mir vor die RN-Karte über eine I2C-Karte mit LCD I/F bedienbar wie ein Geldautomat zu machen. Alle Funktionen einer I2C-Karte sollten Parameter gesteuert sein. Ein GUI auf der RN Karte würde beim Hochfahren des Systems die angeschlossenen I2C-Karten erkennen und an das Display, kann ganz eff sein, die Optionen anzeigen und über die Tasten des RN Control kann der Benutzer wie am Geld Automat seine Eingaben machen. Bei der hier genannten Schaltregelkarte, die IC's von National Semiconductor haben häufig 2 Ausgänge, könnte man die einzelnen Ausgänge Ein- oder Ausschalten, man könnte die Ausgangsspannungen einstellen und man könnte fail-Safe Optionen selektieren und Spannungsüberwachung haben.
2. Eine I2C-Boost-Schaltreglerkarte ohne Linearregler Glättung, aber mit monolytischem Fahrtregler von IRF3220 für Getriebemotorsteuerung. Neben der oben genannten Steuer-Funktionalität der Buckregler Karte könne man hier die Ausgangsspannung bis 40V einstellen, der Fahrtregler von International Rectifier hat neben den Funktionen Vorwärts- und Rückwärts-Fahrtregelung auch noch die Funktionen Stop und Stop mit EMK-Bremse und aus der Anwendung Fensterhebebung auch noch die Schutzfunktion gegen "Einquetschen". Ihr habt davon wohl schon gehört, früher sind Kinder erwürgt worden weil der Fensterheber nicht reagierte wen er den Hals eines Kindes oder seine Finger beim Hochfahren einklemmte. Stellt euch vor, das ist für uns doch die ideale Überwachungsfunktion wenn eine Mechanik verklemmt und Gefahr droht der ganze Roboter, oder das Boot weren dadurch stark beschädigt. Das meiste hiervon wird über 2 5V Steuerleitungen selektiert!
3. Die oben schon genannte I2C-LCD Treiberkarte. So wie die RN-Control über das Print commando und die RS232 ausgaben auf dem PC Schirm machen kann, so würde man Anzeigen auf ein 5 zeilen x 40 Zeichen LCD-Display anzeigen?!
Soweit hier erst einmal als Anregung. Übrigens ich bin glücklich je mehr das sinnvoll finden und an der Implementation mit arbeiten. Die hier beschreibene Funktionalität ist ein erster Diskussionsbeitrag, keine Finale Funktionsbeschreibung.
Hi Hellmut,
da es bis zur "RN-Control Typ 128" eigentlich noch ein paar Monate hin ist, ist es vielleicht noch etwas früh ein Diskussionsthread zu eröffnen. Aber wer schon ein paar Anregungen dazu los werden will, kann das gerne schon machen.
Ich denke an ein ähnlichen Aufbau wie RN-Control. Ich würde vorschlagen das gleiche Format beizubehalten. Aber letzlich muß man natürlich sehen wie das alles paßt. So ein kleine vorhandener Motortreiber und Taster sind sicher auch wieder sinnvoll.
Die LED´s würde ich wie bei dem demnächst erscheinenden RN-Control Mega8 durch Balkendisplay im DIP Format ersetzt werden. Spart Platz und Aufbauzeit und sieht schön aus ;-)
Anregungen sind willkommen.
Noch ne Anmerkung zum kommenden RN-Mega8 Board. Da hast du sicher Recht Helmut, von den Kosten her bringt das nicht viel. Es wird vermutlich kaum billiger als RN-Control sein, aber weniger Features besitzen. Dennoch macht so ein Board Sinn. Denn für bestimmte Aufgaben ist es manchmal sinnvoll einen Mega8 vorzuziehen. Zum Beispiel wenn es nur um steuerung von Servos oder anderen speziellen Aufgaben geht. Und irgendwie muss man ja erst mal ein Board haben wo man den Mega8 programmiert und für viele spezielle Aufgaben austesten kann. Im Endeffekt nimmt man dann vielleicht dann ne ganze andere Platine für diese spezielle Aufgabe. Also es ist mehr ein Entwicklungsboard. Es enthält dafür auch Display- und Servoanschlüsse und zahlreiche Steckklemmen.
Was den I2C-Bus betrifft, so kann nur der Master die Kommunikation anstossen. Allerdings kann jeder Teilnehmer jederzeit die Masterrolle übernehmen. Immer wenn beide Leitungen High sind, ist der Bus frei. In diesem Fall kann jeder Teilnehmer beginnen zu senden. Auch der unglückliche Fall das zwei Teilnehmer gleichzeitig zu senden beginnen ist im Protokoll geregelt. Denn jeder Teilnehmer muss prüfen ob die Leitung auch High ist wenn er ein High Bit sendet. Sobald dies nicht der Fall ist, weiss der Master das noch jemand gleichzeitig sendet und zieht sich einfach zurück. EIn einfaches Verfahren das so von Philips definiert wurde. Allerdings ob dies in jeder Libary schon korrekt berücksichtigt wird ist fraglich, da der Master Master Betrieb (wie man dies nennt) nicht so gebräuchlich ist.
Gruß Frank
Hallo Frank
es war nicht böse oder kritisch negativ gemeint betreff mega8 rn. Und sicher war auch etwas egoistisches von mir dabei.
Zu meinem Verständnis, das mega8 RN-Control Board soll der Software Entwicklung die "reale" mega8 Controller Umgebung bieten und gleichzeitig ein Spektrum an Funktionen wie man es von der heutigen RN-Control kennt. Zweckmäßige Zielsetzung also eventuell aus den Erfahrungen dedizierte Karten zzu realisieren. mmh, OK.
I2C Protokoll code ist sicher im Internet zu finden. Ist dom CAN-Bus der Automobilzulieferer?
MfG
Hellmut
Hi Helmut,
nein nein, hab das nicht böse aufgefaßt ;-) Ursprünglich wollte ich ja selbst kein Mega8 Board auflegen, da ich auch der Meinung war das es nicht lohnenswert ist. Musste abe rdann doch feststellen das man mit dem Mega8 schon viele andere Digitalschaltungen ersetzen kann wenn man den Controller entsprechend programmiert. Vorteil gegenüber Mega16 ist die geringere Baugröße des IC´s! Und für diesen Zweck brauchte ich dann eine Experimentierumgebung. Das ist in erster Linie der Grund. Und wenn ich es brauche, dann geht es bestimmt einigen ebenso.
Ja das I2C Protokoll wird ja im Internet gut beschrieben. Code findet man an jeder Ecke im Internet. Nur an gutem Hardware Slave Code habert es noch etwas. Für Bascom wird es bald was gutes geben, da steh ich mit dem Entwickler in Kontakt.
Deine letzte Frage zum CAN-Bus hab ich nicht verstanden? Bzgl. CAN-Bus kenn ich mich auch bislang nicht näher aus.
Gruß frank
Hallo Hellmut,
bei dem grossen Roboternetz-Board und später bei dem RN-Control hatten wir hier im Forum das Glück, dass jeder der Lust hatte eigene Vorschläge und Wünsche äussern konnte, die Frank dann bei der Entwicklung soweit eben möglich berücksichtigt hat.
Bei dem RN-Control haben sich die meisten Leute gewünscht, dass es möglichst viele Dinge wie LEDs, Taster, Summer, Motortreiber usw. mitbringt.
Das dürfte daran liegen, dass die meisten Leute die sich hier im Forum nach Boards erkundingen eine völlig andere Ausgangssituation als du haben.
Die fangen bei Null an, haben oft kaum Vorkenntnisse von Elektronik, Mikrocontrollern und Programmierung und auch noch kein konkretes Robotergerüst (oder Segelboot).
Damit sie möglichst schnell etwas sehen und ausprobieren können, haben sie sich deswegen gewünscht, dass das RN-Control mehr Richtung Experimentierplatine geht und möglichst viele LEDs, Taster usw. mitbringt.
Damit kann man sich dann in die Programmierung einarbeiten ohne erst mal weitere Hardware und Elektronik zusamenzubasteln und anschliessen zu müssen.
Bei dir ist die Situation völlig anders.
Du hast ja schon ganz konkrete Vorstellungen und jede Menge Vorkenntnisse in Elektronik, Microcontrollern, deren Programmierung usw. und machst dir Gedanken über eine möglichst optimale Platine für den praktischen Einsatz.
Vom Grundgedanken her geht das grosse Roboternetz-Board eigentlich mehr in diese Richtung. Da wurde damals möglichst alles berücksichtigt was man nachher im praktischen Einsatz für den Roboter braucht.
Das hilft dir natürlich wenig, da eine Segelboot recht wenig mit einem Roboter auf 2 oder drei Rädern an dem hier viele basteln gemeinsam hat.
Ein anderes wichtiges Kriterium bei beiden Roboternetz-Boards war, dass Frank und die Leute die sich mit Vorschlägen beteiligt haben, nichts entwickeln wollten, das es eigentlich schon gibt.
Einfache Platinen mit Grundschaltungen für ATMega8, ATMega16, ATMega32 gibt es aber bereits von verschiedenen Herstellern.
Das RN-Control hatte also eigentlich nur eine Chance, wenn es für einen vergleichbaren Preis wesentlich mehr bietet, was ja auch gelungen ist.
Wenn du z.B. mal auf http://shop.mikrocontroller.net nachsiehst, findest du dort z.B. zwei Entwicklungsplatinen für ATMega8 und ATMega16.
Auf der selben Webseite findest du übrigens auch eine ATmega128 Adapterplatine. Ich glaube wenn du den ATMega128 für dein Projekt einsetzen willst, könnte die recht interessant sein.
Hallo!
@Frank
ja als vervollständigung der Boardauswahl soll auch noch ein kompatibles Mega128 Board kommen. Insbesondere für erfahrenere User die schon den Einsteig in die Atmel Welt gefunden haben, dürfte dieses Board dann sicher interessant werden. Controller hab ich schon für Experimente besorgt. Aber das dauert vermutlich noch ein paar Monate weil ich erst noch ein paar andere Zusatzboards fertig mache und auch erst ein paar mehr praktische Erfahrungen von RN-Control machen und bobachten möchte. Das kann man dann immer beim nächsten Board berücksichtigen.
Ok, das hiesse erstmal das vorhandene RN-Controll Mega 32 bestellen.
Und vorher lesen lesen lesen!
Danke!
Gruss!
mir mich
Hallo recycle
bitte mißverstehe mich nicht, das RN-Control Board ist so spitze das ich es postwendend bestellt habe. Es ist genau wie du sagst eine Umgebung die viel bietet und das zu einem sehr günstigen Preis. In meinem Fall wird die RN-Control zur Zentraleinheit meines schwimmenden Roboters. Was ich gerne gehabt hätte ist genau dieses RN-Control mit dem mega128, da als Zentraleinheit ich möglichst viele Reserven haben möchte. Sobald es die RN-Control mit dem mega128 gibt werde ich mir diese zusätzlich erwerben. Nur der dort verfügbare Adressbus müßte noch rausgeführt werden.
Einer der Gründe, nein der entscheidende Punkt, als 68k und PPC Prozessorfan, also Motorlaner, mich für den AVR zu entscheiden ist dieses Forum und damit jeder von Euch. Ich bin begeistert und zur Zeit dabei die Tragweite dieser Entscheidung für meinen schwimmenden Roboter zu erfassen. Ich baue seit Juni 2002 an dem Boot und die Möglichkeiten die sich hier eröffnen sind großartig. Sobald meine Konzeptionsphase weiter fortgeschritten ist werden meine Fragen Konkret und hoffentlich seltener. Wenn ich darf würde ich gerne meine Erfahrungen als quasi Baubericht hier verfügbar machen.
Was sich jetzt heraus kristalisiert als 1. Priorität ist es eine I2C-Karte mit Ansi-LCD Terminal-Display zu machen, die Butterfly-Karte von Atmel scheint ja vieles davon breits zu beinhalten. Dieses Display und die Tasten der RN-Control erlauben vor Ort Programmierung.
Weiterhin werde ich eine I2C-Karte mit Boost-Schaltregler und Fahrtregler Karte machen um die bereits begonnene Anwendung einer Getriebemotorschaltung mit Motorumkehr und Endlagenschalter begrenzte Funktion durch einen mega8 gesteuert zu ersetzen. Mit dem Boost-Schaltregler 40V zu erzeugen und ich brauche statt 24A bei 12V nur noch knappe 6A Strom bei 40V! Im Schiffsmodell.net Forum steht einiges hierzu.
Die Schrittmotorsteuerung wird gleichfalls mein Problem lösen das Vorstag beim Verschieben der Befestigung an Deck gespannt zu halten. Frage, welches Drehmoment kann ein Schrittmotor der durch die RN-Control gesteuert wird maximal aufbringen? ich muß eine schot, also eine Schnur die mit bis zu 50kg Zug belastet sein kann so aufwickeln das es immer gespannt bleibt. Die Schot bildet die Hypothenuse eines Dreiecks wo die eine Kathete, der Mast etwa 180cm lang ist, die andere Kathete durch Verlegen des Befestigungspunktes von 57cm auf 34cm verkürzt wird. Parallel zur Verschiebung muß das Vorstag verkürzt werden um die Spannung konstant zu halten. Ich meine gelernt zu haben das hierfür ein Schrittmotor ideal ist da die Längenänderung nicht linear ist. Dieser Vorgang dauert nur 0,5 Sekunden.
Last, but nor Least wird die 5V Spannung zur Versorgung des Empfängers der Fernsteuerung und der I2C-Karten verwendet. So habe ich praktisch für jede Funktion der RN-Control eine Verwendung!
Damit zeigt sich, gut definiert und die Lösung ist unglaublich vielfältig einzusetzen!
Hallo Frank
Ich wollte nur sagen das hier im Roboterbau offensichtlich der I2C-Bus die Funktion erfüllt die der CAN-Bus im Automobil erfüllt.
Ich verstehe auch nicht warum meine Orthographie so schlecht ankommt, obwohl ich immer über die Vorschau den Text nachbearbeite. Ich hoffe ich bekomme keine Alzheimer?!
Hi Helmut,
ist ja fein das das RN-Control so gut in dein Projekt paßt. Aber stimmt schon, ich hab auch festgestellt das so ein kleines Board doch sehr flexibel ist. So bastele ich mir z.B. gerade einen sprechenden Funkwecker mit RN-Control ;-)
Ein paar Taster und Led´s auf einem Board haben sich als sehr nützlich beim programmieren herausgestellt. Ich glaube es gibt kaum eine Anwendung wo man nicht irgend eine Verwendung dafür findet und wenn es nur für bestimmte Test´s ist.
Was dein Projekt betrifft - das ist ja der Begriff "Segelbot-Roboter" etwas gewagt :-) Aber immerhin, wenn es sich irgendwann mit GPS autonom bewegen sollte, oder dies das Ziel ist, dann könnte man es ja durchaus als Roboter betrachten ;-)
Aber ein Austausch mit Leuten von Eurem Modellbau-Forum ist sicher ganz nützlich für beide Seiten, von daher kannst du gerne deine elektronsichen Fortschritte/Ideen hier posten. Es gibt ohnehin doch schon erhebliche Überscheidungen dieser beiden Intressensgruppen. Vielleicht könnt ihr uns mal in dem ein oder anderen Thread bei der Mechanik etc. aushelfen, da sind die Modellbauer doch immer fit.
Gruß
Frank
Hallo Frank
jederzeit könnt ihr im anderen Forum Nachfragen. Dort ist man genauso professionell und unterstützt gerne. Es lernen ja alle dabei. Was dort denke ich noch problematischer ist als hier, das sind die off-topic threads und die die nicht erst nachschauen ob es zu einer Fragestellung schon was gibt.
Zu meinen Aussagen zum Nutzen der RN-Control, ich hatte den Eindruck das sich da jemand auf den Schlips getreten fühlte und wollte daher diesem Eindruck entgegentreten. Aber wenn ich hier den Thread zum dem 6-beinigen Roboter lese, dann wird eigentlich deutlich wie sinnvoll die Wiederverwendung von ganz einfachen dedizierten I2C-Karten ist. Entscheidend ist dabei die Flexibilität hinreichend gr0ß zu haben ohne Komplexität zu groß werden zu lassen. Die RN ist da ein sehr gutes Beispiel, die "einfache" und elegante Implementation ist aber das Ergebnis einer excellenten Planung, ein Lob dir und dem Forum.
Damit bin auch bei meinem Problem mit den von mir benötigten I2C-Karten. Je mehr ich darüber weiter grüble desdo unausgegorener erscheinen mir manche Implementationsideen. Hier ein Beispiel dazu:
Im Schiffsmodellbau gibt es Spannungsversorgungen zwischen 4,8V und 12V. Da so ein Akku mit hoher Kapazität nicht billig ist baut man sich einen oder kauft einen und möchte den dann immer einsetzen. Ich habe mir 2 Akku-Packs 12V mit 8Ah Mono-D NimH Zellen aufgebaut. Diese schalte ich in meinem Boot parallel um so irgendwo zwischen 14Ah &16Ah Kapazität zu haben.
Jetzt brauche ich einerseits 4,8V, 6,0V, 7,2V und 12V, anderer seits um beim Fahrtregler des Motors nich so hohe Ströme zu haben möchte ich 40V Motoren einsetzen. Was mache ich nun als "flexible" I2C Reglerkarten?
Einen Buckschaltergeler mit einem LOD Regler zur Glättung für die Versorgung von Empfänger, Servos und Winden (5V, 6V und 7,V? Oder nehme ich die 5V von der RN-Karte für Empfänger und die AVR's auf den I2C Karten und Mache den Regler mit 2 einstellbaren Ausgängen je zwischen 5V und etwa 11V? Sollte aber dabei die Eingangsspannung aber nicht doch lieber auch den 6V Bleiakku unterstützen? Dann aber müßte ich einen Boostregler davor setzen!
Das hätte dann aber wieder den Vorteil ick könnte Grundsätzlich die Eingangsspannung auf einen hohen Wert, z.B. 24V oder 40V, siehe Spannungswert E-Motor, mit einem Boost-Regler heben um dann von diesem Wert über einen Buck-Regler die volle Flexibilität der Ausgangsspannungen zu haben.
Wäre das aber überhaupt sinnvoll?
Natürlich muß ich ein großes Augenmerk auf ESD-Vermeidung und Abschirmung legen.
Ich hoffe ich habe hier aufzeigen können wie ich mich schwer tuhe vom möglichen das sinnvolle zu trennen. Da habt ihr bei der Definition des RN einen guten Job gemacht. Was würdet ihr denn dazu sagen?
Hallo Frank, meinen Segler sehe ich als Technologieplatform. Mein Ziel ist nicht das Segeln des Bootes, sondern das Bauen und Entwicklen zum Zwecke der geistigen Betätigung. Segeln soll ein angenehmer Nebeneffekt sein. Wenn das Boot die richtige Elektronik-Infrastruktur hat, dann kann auch autonomes Segeln möglich werden. Das ist wie im Automobilbau. Eure Roboter werden in der Regel mit keinen anderen Verkehrsteilnehmern und ihren menschlichen Stärken und Schwächen rechnen müßen. Wenn mein Segler bei einem autonomen Segeln ein anderes Boot mit dem Bug trifft, so sinkt das andere Schiff und meine nicht vorhandene Haftungsversicherung muß blechen.
Deshalb habe ich auch das Thema Kollisionsvermeidung auf meiner Agenda. Programmiertechnisch aber reizt mich die Aufgabe das Boot einen Regatta-Dreieckskurs autonom fahren zu lassen und das Boot selber nach dem herrschenden Wind Kurs und Segel so zu steuern das die schnellste Fahrzeit entsteht. Ich denke da ist auf Jahre für mich ein Betätigungsfeld offen und dann darf sich das Boot auch Segelroboter im bau nennen, oder?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.