Hi, Ich habe vor einen relativ kleinen und möglichst günstigen Roboter mit mechanum-wheels zu bauen und wenn er funktioniert noch ein oder zwei Kopien davon zu bauen und meiner ehemaligen Schule zur Spenden. Dafür hab ich vor einen "Motion Controller" zu bauen, der auf einem Fpga beruht. Ich hab vor die motortreiber (wahrscheinlich relativ einfache H-Brücken) für alle 4 Motoren zu steuern, deren encoder zu lesen und daten aus einer imu zu lesen. Außerdem sollen die ganze Berechnungen und die regelung direkt im fpga laufen. Meine Idee war so ungefähr, dass man Strecke, Richtung, Geschwindigkeit und Drehung und was noch rein gibt und die aktuellen Daten, sowie Bewegung fertig auslesen kann. Genaue Schnittstelle bin ich flexibel. (ich hab noch nichts viel Richtung kinematic und sensoren gemacht, da ich noch nicht entschieden habe welches Chassis ich haben will) Habt ihr eine Empfehlung was ich für ein möglichst günstiges entwicklungsboard benutzen könnte und welcher fpga sich eignet? Ein einsteigerfreundliches Buch über fpgas wäre auch schön, aber das find ich zur Not schon.
Willst du das Projekt aus Gruenden komplett im FPGA, also in programmierbarer Logik machen, oder kannst du auch die Berechnungen auf einem Microprozessor ausfuehren der im Chip integriert ist? Damit wuerdest du dir erhebliche Vorteile in der Implementierung verschaffen.
Stefan S. schrieb: > Habt ihr eine Empfehlung was ich für ein möglichst günstiges > entwicklungsboard benutzen könnte und welcher fpga sich eignet? Nein, da du dich zwanghaft für die Steuerung einer trägen Mechanik auf die Verwendung eines ffenschnellen FPGA festgelegt hast, gibt es wohl keine Lösung. (Nicht nur) Im Lehrbetrieb schon über viele Jahre verbreitet zur Roboteransteuerung ist das Handy-Board, weil es so einfach mit interactive C programmierbar ist https://de.wikipedia.org/wiki/Handy_Board https://www.cs.uml.edu/~fredm/handyboard.com/ Das kann mit drittem und vierten Motortreiber sicher auch mechanum-wheels ansteuern.
Klar könnte das auch ein integrierter Kern machen. Mein erster Gedanke war, dass auf vielen embedded Systemen trigonometriefunktionen relativ langsam sind (kann auch mein unzureichende weltbild von avr sein) Mir geht es hauptsächlich darum, dass der Benutzer sich nicht mit dem Kram rumschlagen muss. Immerhin sollen das später mal Schüler benutzen... Sie kriegen wahrscheinlich Panik, wenn sie was sehen, dass ihre lehrerin nicht erklären kann. Ideal wäre, wenn ich es sogar schaffen würde direkt trajectories auf dem pfga oder Prozessor zu berechnen, damit man dem nur eine Serie von Wegpunkten geben muss. Mal schauen wie viel meine expertise hergibt. Wahrscheinlich würde ich dann später auch einen ähnlichen Controller für einen Arm bauen. Aber wenn die motion funktioniert, kann das ja kaum schwer sein Außerdem will ich mal was sinnvolles mit fpgas machen, also ist der fpga Part hauptsächlich auch eine Übung für mich. Natürlich könnte ich auch alles auf einem relativ großen Arm Prozessor oder irgendwas in der Art aufbauen. Ich will aber mal was neues machen.
:
Bearbeitet durch User
Stefan S. schrieb: > Mein erster Gedanke war, dass auf vielen embedded Systemen > trigonometriefunktionen relativ langsam sind (kann auch mein > unzureichende weltbild von avr sein) Ja, wenn man die ganzen Berechnungen in einem Zahlenformat macht, das für die Zielplattform ungeeignet ist, dann passiert sowas. Wenn man z.B. erst mal auf einem 8-Bit Rechner ohne FPU mit float oder gar double rechnet. Und danach, wenn man kapiert hat, warum das natürlich langsam sein muss, auf integer umstellt und seine Berechnungen im Zehnersystem macht, weil man halt von Geburt an 10 Finger hat. So richtig schnell sind digitale Rechner (agal ob Prozessor oder FPGA), wenn man digitale Rechenverfahren anwendet und wie es dem Rechner genehm ist, in Zweierpotenzen rechnet und skaliert. Das musst du in einem FPGA für eine effiziente Implementierung noch viel mehr selbst beachten als bei einem Prozessor, wo die Bibliotheken schon für solche "Zehnerrechnungen" optimiert sind. > Mir geht es hauptsächlich darum, dass der Benutzer sich nicht mit dem > Kram rumschlagen muss. Dann kapsle die Funktionen einfach in einer Bibliothek. Das funktioniert bei allen möglichen anderen Funktionen auch tadellos. Oder hast du dir schon mal Gedanken gemacht, wie z.B. eine Addition oder eine Subtraktion implementiert ist? > Ich will aber mal was neues machen. Na gut, gegen "ich will aber" helfen keine rationalen Argumente. Mein Rat ist also: "Hör auf mit wollen, fang an zu tun!" Stefan S. schrieb: > Habt ihr eine Empfehlung was ich für ein möglichst günstiges > entwicklungsboard benutzen könnte "Möglichst günstig" ist an der falschen Stelle gespart. Und eine schlechte Voraussetzung für eine Neuentwicklung... > und welcher fpga sich eignet? Nimm ein möglichst oder wenigstens hinreichend großes. Wenn es letztlich zu groß ist, dann kannst du dein Design hinterher immmer noch verschlanken. Andersrum bist du laufend am Ressourcensparen.
:
Bearbeitet durch Moderator
Stefan S. schrieb: > Klar könnte das auch ein integrierter Kern machen. > > Mein erster Gedanke war, dass auf vielen embedded Systemen > trigonometriefunktionen relativ langsam sind (kann auch mein > unzureichende weltbild von avr sein) Dann koennte ein Zynqberry vll. das passende sein. Und wenns moeglichst guenstig sein soll, die Zynqberry Variante: https://shop.trenz-electronic.de/de/TE0727-02-41C34-ZynqBerryZero-Modul-mit-Xilinx-Zynq-7010-512-MByte-DDR3L-SDRAM-3-x-6-5-cm?c=238 Du braucht kein extra Baseboard, hast nenn Zynq mit ansehlich Rechenpower und der PL Teil sollte mehr als ausreichend sein. Waere jetzt so mein erster Kandidat ohne genauere technische Infos zu haben. Dein grosser Vorteil: Da du das privat und zum Spass und aus technischer Neugierde machst, kannst du eigentlich nicht viel falsch machen. Einfach loslegen. :-D
Au ja, über solche Dinge hab ich schon nachgedacht. Wie gesagt, ich bin kein absoluter Anfänger was prozessoren und das angeht. Außerdem geht es mir darum selbst was zu lernen. Ansonsten würde ich einfach einen raspberry pi zero benutzen, der sich dedizierte nur um die motion kümmert. Ich kenn aber meine Pappenheimer, da wird Hardware geklaut um sie in anderen Projekten zu verwenden oder einer denkt sich "Wenn ich da noch xy auf den raspberry packe kann ich z" und die betreffende Person kann so schlecht programmieren dass die motion nicht mehr richtig funktioniert, oder einer tötet ausversehen die motion komplett.... Sowas würde ich gern vermeiden. Ich werd sowieso noch python und c/c++ Bibliotheken bauen um den Transfer zwischen hauptcontroller und motion und den anderen Teilen des Systems zu vereinfachen. Auch mit Robotern an sich hab ich zumindest eingeschränkt Erfahrungen, da ich eine Zeit lang Teil eines Roboter fußballteams war. Ich weiß, dass die bei uns natürlich gewachsen sind und das in der Art wahrscheinlich nicht unbedingt bei Schülern passiert die sich mal ein oder zwei hl jahre damit beschäftigt haben. Trotzdem will ich mal beschreiben, wie das bei uns funktionierte. Ein Teil der Motion läuft auf dem PC und macht ros über udp zu einem bbb der einen anderen Teil der motion macht und dann irgendwie über einen ethcan die motortreiber steuert und sensoren liest um sie zum ersten part der Motion auf den PC zu schieben..... Ich würde auch nur ungern über die Sinnhaftigkeit eines fpga diskutieren, da meine Entscheidung fest steht sowieso einen zu benutzen. Ich hoffe aber das wären jetzt genug Hintergründe um meine Entscheidung zumindest ein bisschen plausibel zu machen und vielen Dank schon mal an alle die bisher gepostet haben
Tobias B. schrieb: > Dann koennte ein Zynqberry vll. das passende sein. Und wenns moeglichst > guenstig sein soll, die Zynqberry Variante: > > https://shop.trenz-electronic.de/de/TE0727-02-41C34-ZynqBerryZero-Modul-mit-Xilinx-Zynq-7010-512-MByte-DDR3L-SDRAM-3-x-6-5-cm?c=238 > > Du braucht kein extra Baseboard, hast nenn Zynq mit ansehlich > Rechenpower und der PL Teil sollte mehr als ausreichend sein. Das sieht ziemlich gut aus. Werd mir wahrscheinlich im Verlauf einen kaufen. Mich schreckt aber auf den ersten Blick ab, dass er anscheinend ungefähr ein raspi mit fpga drauf ist und der vielleicht geklaut wird um in anderen Projekten zu arbeiten. Dann gibt's natürlich Chaos. Für eine eventuelle Vision wäre der aber perfekt, da ich davon ausgehe, dass man Teile des maschinellen Sehens auf den fpga auslagern kann. Danke für den tollen Hinweis. Ein anderer Gedanke war, dass ein fpga ja für jeden sensor sein eigene Schnittstelle haben kann um eine art (wahrscheinlich relativ crudes) oversampling bei den sensoren zu machen... Details hab ich mir alle noch nicht überlegt, finde aber die Idee faszinierend, dass man in Hardware alles notwengdige hat um einen möglichst schnellem Update loop zu realisieren, da komplizierte umrechnungen in Hardware ja "keine" Zeit brauchen.
Der Sinn eines FPGA erschliesst sich hier nicht wirklich, aber sei's drum. Ansonsten gabs mal sowas (SRV1 Roboter mit Blackfin DSP und Kamera), darauf wurden einige Navigations-Algos implementiert. Leider ist der Erbauer des SRV1 verstorben und die Firma dicht, aber die Designs sind offen, es gibt somit Nachbauten. Würde mich daran mal etwa orientieren. Fraglich ob man an einem Zynq gemessen am Stromverbrauch so viel Spass hat. Fest steht schon: Für Schüler ist das nix, und die Ziele insgesamt deutlich zu hoch gesteckt.
Es geht um die Oberstufe. Aber dass meine Ziele ein Stück zu hoch sind, aber das wird sich zeigen. Den Roboter werd ich mir mal anschauen. Danke für den Hinweis
Für die Aufgabe reicht jedenfalls ein normaler STM32. Ein Zynq ist da wirklich Overkill und dürfte die meisten Schüler eher überfordern. Bzw. das wird dann i.d.R. auf in einem vorhandenen Projekt herumwühlen aber nix kapieren hinauslaufen. Oder es wird nur auf dem Prozessor gearbeitet - dann kann man sich den FPGA Teil aber auch sparen ;-)
Die Schüler sollen niemals irgendwas auf dem fpga ändern!!! Die sollen nur Befehle an den fpga oder zynq schicken. Die Schüler sollen dann einen Arduino, oder einen raspberry pi programmieren und anschließend und über rs422 oder rs485 fahrbefehle an den fpga senden. Ich mach alles was den fpga angeht und das wird dann hoffentlich nicht mehr verändert.
:
Bearbeitet durch User
Stefan S. schrieb: > Die Schüler sollen niemals irgendwas auf dem fpga ändern!!! Ersetze in diesem Text das FPGA durch STM32, dann hört sich das alles ganz schlüssig an. Hier bei uns schafft es so ein Zwofuffzich-uC, genau so eine Aufgabe zu lösen. Und da ist noch einiges an Reserve... Wozu ein zigfach teureres System, das ausser dir sicher keiner kapiert? Nur weil "ich will"?
Der Sinn ist zum Teil grade, dass es keiner kapiert, denn dann wird der Teil nicht zweckentfremdet. Ich weiß, dass ein stm32 das spielend schafft, aber dann wollen auch Leute dran rumfummeln, weil sie wissen wie man es programmiert. Und das wird nur Probleme geben. Ein arduino mega wäre auch spielend in der Lage das zu machen. Wenn dir 15Hz update intervall reichen, dann genügt auch ein normaler arduino. Ich will das gerne und ich denke es erzielt gute Ergebnisse. Da das ja nur ein Projekt ist was ich zum Spaß mache und später meiner Berufsschule ne nette Plattform zum spielen für Schüler schenke. Mein Ziel ist, dass ich hardware Programmierung mache, ein bisschen software und ein bisschen cad + 3d Druck. Ich will halt einen Roboter bauen und dann loswerden.
Stefan S. schrieb: > Mein erster Gedanke war, dass auf vielen embedded Systemen > trigonometriefunktionen relativ langsam sind (kann auch mein > unzureichende weltbild von avr sein) Bereits "kleine" STM32G4 besitzen unter Anderem einen CORDIC zur Hardwarebeschleunigung. Stefan S. schrieb: > Die Schüler sollen dann einen Arduino, oder einen raspberry pi > programmieren und anschließend und über rs422 oder rs485 fahrbefehle an > den fpga senden. Cool wird es aber erst kabellos mit Bluetooth, Wlan, etc. und gegebenenfalls (einer eigenen) Smartphone-App. Falls du sagen möchtest, dass auf deinem Roboter ein Arduino-Board huckepack mitfahren soll, würde ich einen von Arduino unterstützten µC direkt integrieren, oder als softcore implementieren. Auf Kabel würde ich so weit wie möglich verzichten. Stefan S. schrieb: > dann wollen auch > Leute dran rumfummeln, weil sie wissen wie man es programmiert. Gehäuse abschleifen, Platine vergießen, SWD/JTAG/Bootloader-enable-pins abschneiden........ Stefan S. schrieb: > Ideal wäre, wenn ich es sogar schaffen würde direkt trajectories auf dem > pfga oder Prozessor zu berechnen, damit man dem nur eine Serie von > Wegpunkten geben muss. Warum soll alles eine "Black-box" sein? Schüler profitieren doch von einer frei programmierbaren, flexiblen Platform, auf der eigene Ideen und Projekte umgesetzt werden können, deren Grenzen der Lehrer individuell festlegen kann. Falls sich ein Lehrer findet und es genügend interessierte Schüler gibt, könnte eine Art "Roboter-AG" entstehen. Die Meisten der heute hier im Forum verkehrenden hätten soetwas begrüßt. Vorschlag: Arbeite mit den Lehrern zusammen, um ein didaktisch nutzbares und auf schulische Anforderungen optimiertes Produkt zu entwickeln, ansonsten besteht die Gefahr, dass deine Roboter selbst im Schrank Staub ansetzen. Stefan S. schrieb: > Es geht um die Oberstufe. Ein Informatikkurs der Oberstufe an meiner ehemaligen Schule hat vor vielen Jahren erfolgreich mit ASURO gearbeitet. Es gab sogar eine "öffentliche" Demonstration wärend des Schulfestes. Den Höhepunkt bildete dort das Tröten eines kurzen Musikstücks mithilfe des Antriebs. Das Ganze war vor der Arduino-Zeit.
:
Bearbeitet durch User
Stefan S. (neocortex) >Dafür hab ich vor einen "Motion Controller" zu bauen, der auf einem Fpga >beruht Wie viel Erfahrung hast du schon mit der Programmierung von FPGAs und Mikrocontrollern?
Stefan S. schrieb: > Da das ja > nur ein Projekt ist was ich zum Spaß mache und später meiner > Berufsschule ne nette Plattform zum spielen für Schüler schenke. Das kann ein sehr spannendes Projekt für einen selber sein aber hast du deine Berufsschule schon gefragt ob sie das überhaupt haben wollen? Denn ich sehe da einen großen Betreuungsaufwand seitens der Lehrer.
Stefan S. schrieb: > Ich weiß, dass ein stm32 das spielend schafft, aber dann wollen auch > Leute dran rumfummeln, weil sie wissen wie man es programmiert. Vergiss diese Argumentationsschiene. Die läuft nicht. Warum sollte ein RPi-ler oder ein Arduinist unbedingt Software für den STM32 schreiben wollen? > Ich will Das und nur das zählt hier. Also mach. Im Sinne von "da darf ein anderer nichts ändern können" gleich mit einem FPGA, für das man nicht so leicht oder gar umsonst an eine Toolchain kommt.
Genau deswegen hatte ich meine Frage überhaupt gestellt. Ich hab keine Ahnung von fpgas und wollte wissen, ob ihr ein Board kennt, das halbwegs günstig ist und ein gutes Buch für fpgas. Mehr wollte ich nicht wissen. Ich habe die ganzen Details ja nur erwähnt, weil ich dachte, vielleicht gibt es ja eine Produktlinie die für numerische Berechnungen besser geeignet wäre. Jetzt hab ich selbst gelesen und werde wahrscheinlich einen fpga mit integrierem Prozessor Kern suchen. Ich sehe den Nutzen von einem zusätzlichen Prozessor. Aber mehr oder weniger nur als io Maschine. Parsen von Zeichenketten ist wahrscheinlich nicht so einfach in einem fpga zu implementieren. Ansonsten kauf ich einfach einen billigen clon von einem Board mit cyclone oder spartan6
Stefan S. schrieb: > Parsen von Zeichenketten ist wahrscheinlich nicht so einfach in einem > fpga zu implementieren Das kommt auf die Zeichenketten an :-)
Lothar M. schrieb: > Vergiss diese Argumentationsschiene. Die läuft nicht. Warum sollte ein > RPi-ler oder ein Arduinist unbedingt Software für den STM32 schreiben > wollen? Zum Beispiel wei Die alle arduino in der Schule lernen, denn die Lehrer haben das zur Plattform der wahr gemacht. Und den stm kann man ja weitgehend auch mit arduino programmieren und nichts ändert sich. Ich werde natürlich den Code und alle anderen Infos der Schule zur Verfügung stellen, falls irgendwas kaputt geht und die das reparieren können. Und wenn da ein Board vorhanden ist, dass wunderbar mit arduino funktioniert, wird das aus dem robi geklaut.
Duke Scarring schrieb: > Das kommt auf die Zeichenketten an :-) Natürlich, aber ich hab kaum Ahnung von fpgas, weswegen ich mir kaum eine effiniente Implementierung zutrauen kann ohne ziemlich viel Platz einzunehmen. Ich trau mir allerdings zu binärdaten und bitcodierte Daten relativ einfach zu parsen, deswegen würde ich das auslesen der sensoren direkt vom fpga machen lassen. In meinem Kopf ist der prozessoren hauptsächlich da um zum Beispiel debugging zu machen, Infos aus zum Fortschritt, etc oder Positionen und kalibierungen rausziehen zu können, wenn der Benutzer das will. Oder zum Beispiel die selbstkalibrierung zu starten.
Stefan S. schrieb: > Und wenn da ein Board vorhanden ist, dass wunderbar mit arduino > funktioniert, wird das aus dem robi geklaut. Du versuchst ein soziales Problem mit technischen Mitteln zu lösen. Nach meiner Erfahrung hat das noch nie gut funktioniert. Warum stellt man nicht einfach genügend Arduinos zur Verfügung? In Asien kosten die Dinger 2,50... Duke
Stefan S. schrieb: > Ich werde natürlich den Code und alle anderen Infos der Schule zur > Verfügung stellen, falls irgendwas kaputt geht und die das reparieren > können. Weil die ja logischerweise einen VHDL-Spezi in der Tasche haben, der Lust hat, sich in deinen Anfänger-VHDL-Code einzuhacken. Und natürlich ist dieser Ansatz mit dem FPGA auch in der Ersatzbeschaffung immer teuerer als der mit dem µC. > Und wenn da ein Board vorhanden ist, dass wunderbar mit arduino > funktioniert, wird das aus dem robi geklaut. Gibts da überhaupt was? Und wenn ja, dann nimm ein STM32-Board, das nicht "wunderbar" mit Arduino funktioniert. Oder nimm einen Teensy mit 600MHz für den schmalen Taler. Stefan S. schrieb: > Ansonsten kauf ich einfach einen billigen clon von einem Board mit > cyclone oder spartan6 Wovon ein Clon? Weil es da keine Standards gibt, gibts auch keinen Clon. Nimm einfach irgendein FPGA. Zum Entwickeln nimm ein großes FPGA. Kleiner kann man es dann wählen, wenns hinterher nicht voll ist. Mit weniger als sowas würde ich nicht beginnen: https://www.xilinx.com/products/boards-and-kits/1-w51quh.html Stefan S. schrieb: > aber ich hab kaum Ahnung von fpgas Ich mach gern was mit FPGAs, aber dein Ansatz ist wie mit dem Spaceshuttle in den Urlaub nach Malle zu fliegen. Und zwar nur deshalb mit dem Spaceshuttle, damit kein anderer mitfliegen kann. Kann sein, dass das geht. Es ist aber echt umständlich.
Ich stelle zumindest den Bitstream zur Verfügung, dann ist es aber einfacher den vhdl Code im gut direkt daneben zu legen. Mit clon meinte ich einen von den 30x clonen von beispielsweise einem DE0 nano, der je nach Quelle zwischen 120 und 80€ kosten soll. Das Problem ist, dass es mittlerweile arduino ports für alle halbwegs bekannten Architekturen gibt (glücklicherweise) Außerdem war das mit dem "Dann fummeln die nicht unnötig dran rum" nicht Hauptgrund sondern eher ein Bonus.
@Stefan: Was geheizuhalten schaffst Du nicht! Egal was Du tust! ;-P Mal zu Deinem Projekt: Warum schaffst Du auf Deinem Robot keinen einfache Kommandosprache, die deine Schüler verstehen? Dein Rover kann nämlich dann zum Beispiel kommandiert werden aber hat auch eigenmächtige Möglichleiten selbst zu entscheiden. Der Befehl heißt dan zum Beispiel "Fahre von Koordinate a zur Koordinate b" sucht sich dann den Weg eigenständig, er kann dann Hindernissen ausweichen, das dann nicht alles vom Schüler pingelig ausprogrammiert werden muß. So wie beim Marsrover!! mfg
Teile davon hab ich vor. Ich habe vor eine Motion zu entwickeln, die Fahrbefehle relativ zur Startposition ausführen kann. Außerdem einen manipulator, der sich in seinen eigenen Koordinaten absolut bewegen kann oder absolut in Roboter Koordinaten. Außerdem will ich für eine eventuelle Vision mit Kamera und slam die fertigen ros Pakete verwenden. Zusätzlich soll es eine art Roboter Konsole geben, von der aus Befehle über Netzwerk an den robi geschickt werden können und dann mit ros und dem Chassis bus interagieren können. Das sind für mich so die basics, die eine mobile Plattform braucht. Wenn ich dann noch Bock hab, bau ich eine einfache Logik engine, die die Schüler als Basis benutzen können. Außerdem hatte ich vor diesen Chassis bus so semi zu standardisierten, damit Schüler zum Beispiel den fertigen Arm nehmen und allein benutzen oder auf eine eigene Basis Schrauben können. Ich weiß, dass das Projekt riesig klingt, aber ich hab Hilfe von einem Elektroniker und einem Maschinenbauer und kein zeitlimit. Ich als Informatiker bin ja für den software Part prädestiniert. Vielleicht bau ich anstatt Ros auch ne primitive, eigene Middleware (da hab ich schon mal was in die Richtung implementiert und Erfahrung) Mal schauen wie viel Bock ich hab. Bei einer eigenen Middleware wäre es viel einfacher autoconfig mit dem Chassisbus zu bauen und alles transparent zu machen. Muss nur nach ner Bibliothek suchen die dynamisch beliebige Datenstrukturen de-/serialisieren kann. Als Sprachen mit denen Schüler interagieren sollten werden python und c++/c (das letzte weil es sich einfach mit anderen Sprachen wrappen kann Die robotershell soll dann einfache Befehle zum Senden von Befehlen, abfragen von Werten können. Logik in der robotshell hab ich keine vor, dafür aber dass man Befehle direkt von der shell ausführen kann, also Logik dann als bash Script oder mittels Programmiersprache. Die shell repl Funktionen sind dabei eher debugging und testen vorbehalten
:
Bearbeitet durch User
Absolut geil!! Dann würd ich zum Rechnen ne BCD library nehmen, wie bereits oben angesprochen, denn float macht Rundungsfehler. Alles auf nem 32 Bit Prozzi mit nem RTOS müßte also schnell genug laufen. Da brauchst Du dann keinen FPA, die außerdem viel zu viel Strom braucht. Lerne von den alten Männern (OM's) hier, es lohnt sich! :-) Nen FPGA benutz ich dann um hinter Deine Geheimnisse zu kommen, wenn ich den FPA erstmal "gepackt" hab. ;-D Respekt! ~Lolita~
Mit stm32 hab ich das schon probiert. Ich hab leider kein oversampling der sensoren (zwei mal lesen und Mittelwert bilden) geschafft. Momentane Liste der sensoren und Aktoren ist folgende: 1. Mindestens eine 9dof imu per spi 2. 4x motor encoder 3. 4x motor temperatursensoren 4. 4x motor Strom sensoren für stale erkennung 5. 2x tof sensor also vorne und hinten 6. 2x Ultraschall sensor ebenso vorne und hinten 7. Mindestens 10x bumper schalter würde aber ggf mehr oder weniger nehmen damit es genau auf bytes passt. Akku management macht ein stm32 der direkt auf das power Board gelötet wird. Einen potischen flow sensor han ich mir mal geschenkt, weil die encoder zusammen mit der imu das ganz gut schaffen. Könnte aber ggf noch einen mit spi anklemmen (kenne da einen sensor von der Uni) Weil da so viel abgeht dachte ich es sei effizienter eine fpga zu nehmen der die sensoren liest und über eine schnelle Schnittstelle an einen Mikrocontroller weitergibt. Später ist daraus geworden, dass die ganze Mathematik zum Fahren auch im fpga laufen kann und nur die Parameter und messerwerte als eine Art register zum Prozessor geschickt werden müssen. Ein netter Gedanke war, dass ein 65xx Bus ausgeführt wird und eine spi oder i2c Schnittstelle. Denn einen kleinen 6502 computer hab ich schon. Wäre doch geil einen Roboter zu haben, der von einem selbstgebauten computer gesteuert wird. Noch bin ich am überlegen, ob ich anstatt einem normalen dc Motor einen billigen closed loop stepper benutze und die Motoren über die spi Schnittstelle des steppers steuere. Hab davon aber noch nichts getestet. Alternativ bau ich intelligente Motor Treiber mit atmega328 und i2c die alle auf einen pin die neuen Werte übernehmen. Da bin ich aber nicht sicher wie cool das ist.
Stefan meinte: > Alternativ bau ich intelligente Motor Treiber mit atmega328 und i2c die > alle auf einen pin die neuen Werte übernehmen. Da bin ich aber nicht > sicher wie cool das ist. Lass den FPGA weg. Microsoft hat mit Azure RTOS was in der Mache, das Dein Projekt geil macht. Das RTOS soll kostenlos sein für Amateure. Beschäftige Dich damit! Dein Motortreiber ist ne gute Idee, denn es entlastet den Hauptprozessor von dem "PWM" - Kram (ja, ich weiß was Du meinst). Und zur Mittelwertbildung addierst Du deine beiden Werte einfach und teilst das Ergebnis durch zwei, Schiebebefehl nutzen! Und das Wichtigste Stell dein Projekt unbedingt hier im Board vor, auch Lolita's müssen noch lernen!! mfg
Meine tests sagen, zwei komplette sensor Zyklen pro pid Zyklus sind nicht drin. Selbst mit einem stm32f103. Das Chassis reagiert dann manchmal mit ziemlich deutlichem überschwingen, weil der pid regler nicht schnell genug ist. Ich würde wahrscheinlich freertos benutzen das kann ich schon und es ist komplett open source. Die motortreiber in der Uni haben canopen gesprochen, aber ich bin mir sicher can ist kein besonders guter Chassisbus. Ein fpga hat den Vorteil, dass er beliebig viele pwms hat die komplett in Hardware laufen. Und dass Dinge komplett unabhängig von einander laufen können. Das powerboard soll monitoring für jede einzelne Zelle machen und mit buck-/boostwandlern je stabile 5 und 12V ausgeben. Außerdem soll es hotswap zwischen zwei akkupacks erlauben - vorausgesetzt wir kriegen sowas entworfen. Mal schauen, ob ich es schaffe so ne chinesische balancer schaltung nachbauen und mit Monitoring ausstatten kann. Spannungsversorgung sollen zwei 11.1v lithium packs in Reihe sein, zumindest wahrscheinlich. Ich gebe zu, man könnte sowas wie Temperatur und Strom für das blockieren von Motoren analog machen, so dass am stm dann nur noch ein Interrupt gebraucht werden, ich find das aber doof. Genau weil dann eine arme Sau das komplett analog manuell abstimmen muss (nicht nur die strom Messung, sondern auch die Schwelle ab wann ein blockiert erkannt werden soll. Mit dem Controller würde sich das zu einem einigen manuell Strom ablesen und korrekten Messwert in die Kommandozeile tippen vereinfachen lassen. Temperatur genau das gleiche. Auch das wäre wieder ein wunderbarer Job für einen fpga. Der könnte dir den Wert schon korrigiert und mit einem pin zum feststellen ob er blockiert ausgeben. Mal abgesehen, könnte ich ja (ich will eh mindestens zwei Exemplare spenden) einen bauen, wo die kontrollstruktur weiter aufgebrochen ist. Zum Beispiel ein stm32 der nur die vier pwm channels und encoder macht, einen der Strom und Temperatur für die Motoren macht und ein Dritter, der nur dazu da ist um die neuen Kommandos für die anderen zu machen. Oder man lagert die sensoren komplett auf ein eigenes Board zu den sensoren aus, die nichts mit der motion zu tun haben. Momentan ist nur ein Bus auf dem Chassis vorgesehen, aber es sieht aus, als sein mehrere sinnvoll. Beispielsweise can für die Motoren, rs422 für den Haupt bis und weiß nicht can oder rs485 für das sensor Netz. Hab mir mittlerweile überlegt, rs422 sei ja ein cooler Bus für den Chassis Bus, wenn der kein Problem mit arbitrierung hätte. Ideal wäre can-fd, weil man da 64 bte Daten anstatt 8 am Stück übertragen kann, aber can-fd chips sind Sau teuer. Normales can fällt aus quasi jedem stm hinten raus. Kann man einen thread umbenennen, oder sollte ich lieber einen neuen auf machen und hier drauf verweisen, wenn es jetzt eher um die direkte umsetzunrg geht?
:
Bearbeitet durch User
Ein interessanter Thread. Ähnliche Probleme hatte ich schon, wenn ein 5 jähriges Kind einem beim Schach spielen zusieht, dann herkommt und einfach nicht verstehen kann, dass man die Figuren nicht so einfach auf dem Brett rumschieben kann.
Welchen spekt meinst du jetzt? Mein beharren auf dem fpga oder die Diskussion über das Projekt?
Stefan S. schrieb: > Welchen spekt meinst du jetzt? Aspekt Bitte erleichtere uns das Lesen deiner Beiträge: 1) Bitte schreibe Wörter aus. 2) Verzichte auf Denglisch, fremdsprachliche (Fach-)Begriffe verwendet man nur, wenn keine äquivalenten deutschen existieren, oder diese ungebräuchlich sind. Falls das für dich unmöglich ist, empfehle ich dir gleich alle deine Beiträge auf englisch zu verfassen. 3) verzichte auf "Jugendsprache"
Stefan S. schrieb: > Meine tests sagen, zwei komplette sensor Zyklen pro pid Zyklus sind > nicht drin. Selbst mit einem stm32f103. Das Chassis reagiert dann > manchmal mit ziemlich deutlichem überschwingen, weil der pid regler > nicht schnell genug ist. Meine Interprätation: Dein Projekt ist eigentlich fertig, funktioniert aber nicht wie erwartet. Darum möchtest du eine neue Steuerung auf Basis eines FPGAs aufbauen, weil du µCs und CPUs grundsätzlich für ungeeignet hältst, weil der stm32F103 nicht ausgereicht hat. Poste doch mal den Sourcecode und Schaltpläne. Stefan S. schrieb: > Außerdem geht es mir darum selbst was zu lernen. Das ist natürlich ein Argument. Stefan S. schrieb: > Meine tests sagen, zwei komplette sensor Zyklen pro pid Zyklus sind > nicht drin. Selbst mit einem stm32f103. Wie hast du das getestet? Wieviel Overhead hast du? Ist die PLL konfiguriert? Welche Zykluszeit erwartest du / erreichst du aktuell? Der F103 hat keine FPU. Der F103 ist alles Andere als leistungsstark. Wenn du etwas maximal leistungsfähiges haben möchtest, dann schaue dir die stm32h7 und i.mx rt1xxx an. Stefan S. schrieb: > 2x tof sensor also vorne und hinten > 2x Ultraschall sensor ebenso vorne und hinten Stefan S. schrieb: > mechanum-wheels Da sich dein Roboter dank der "Mechanum-Räder" in "alle Richtungen" bewegen kann, sollten mindestens an die "Seiten" ebenfalls Sensoren. Ein Lidar wäre eine sinnvolle Ergänzung. Stefan S. schrieb: > Ich habe vor eine Motion zu entwickeln, die Fahrbefehle relativ zur > Startposition ausführen kann. Problem: Der Nutzer hebt deinen Roboter an, dreht ihn ein paar mal um alle Achsen und setzt ihn an einem beliebigen Ort wieder ab. Was, wenn dein Roboter zeitweise die Traktion verliert, wegrutscht oder sich irgendwo verhakt? Wie ermittelst du die Startposition? Außerdem musst du mit Sensordrift rechnen. Eine IMU wie du sie verwenden möchtest, wird alleine kaum ausreichen um die Startposition ausreichend genau wiederzufinden. Schaue mal hier: https://www.dronecode.org/ https://pixhawk.org/ https://ardupilot.org/ https://px4.io/ etc.. Als Ausgangspunkt sicherlich zu gebrauchen, nicht zuletzt, da sämtliche Arten von Land- und Luftfahrzeugen bereits implementiert wurden.
:
Bearbeitet durch User
>Welchen spekt meinst du jetzt? >Mein beharren auf dem fpga oder die Diskussion über das Projekt? Grundsätzlich bin ich immer für Diskussionen offen. Wenn ich es richtig verstanden habe, hast du noch keine Erfahrungen mit FPGAs und relativ wenig Erfahrungen mit Mikrocontrollern. Ich mache mal eine Abschätzung des Zeitaufwands für dich. 1. VHDL oder Verilog lernen: 12 Wochen 2. FPGA Entwicklungsumgebung lauffähig und bedienbar installieren: 3 Tage 3. Realisierbarkeit von Schaltungsstrukturen im FPGA verstehen: 6 Wochen 4. Algorithmikentwicklung für die Motorsteuerung auf dem FPGA: 6 Wochen Das Ganze gilt für Vollzeit und schneller Auffasungsgabe. Hast du so viel Zeit und Durchhaltevermögen? Meiner Einschätzung nach ist der Aufwand, ein Problem im FPGA zu lösen, wenn man es auch auf einem Mikrocontroller lösen könnte mit dem Faktor 5 an Zeitaufwand verbunden.
chris_ schrieb: > Meiner Einschätzung nach ist der Aufwand, ein Problem im FPGA zu lösen, > wenn man es auch auf einem Mikrocontroller lösen könnte mit dem Faktor 5 > an Zeitaufwand verbunden. Du bist ein Optimist...
@chris_ Ich will nicht alle Probleme der Navigation in der reinen motion engine lösen. Dinge wie globale Positionierung werden auf einer anderen Ebene realisiert. A. M. schrieb: > Wenn du etwas maximal leistungsfähiges haben möchtest, dann schaue dir > die stm32h7 und i.mx rt1xxx an. Die entwicklungsboards für die Produktfamilie wären in dem Preisbereich von dem Fpga den ich verwenden wollte und der fpga ist wahrscheinlich viel leistungsfähiger. A. M. schrieb: > Da sich dein Roboter dank der "Mechanum-Räder" in "alle Richtungen" > bewegen kann, sollten mindestens an die "Seiten" ebenfalls Sensoren. Ein > Lidar wäre eine sinnvolle Ergänzung. An den Seiten sind bumper angebracht. Aber ich überlege ob ich die Seiten auch sinnvoll mit welchen ausstatten kann. A. M. schrieb: > Problem: Der Nutzer hebt deinen Roboter an, dreht ihn ein paar mal um > alle Achsen und setzt ihn an einem beliebigen Ort wieder ab. Was, wenn > dein Roboter zeitweise die Traktion verliert, wegrutscht oder sich > irgendwo verhakt? Wie ermittelst du die Startposition? Außerdem musst du > mit Sensordrift rechnen. Eine IMU wie du sie verwenden möchtest, wird > alleine kaum ausreichen um die Startposition ausreichend genau > wiederzufinden. Aus meiner sicht ist das kein Problem der Motion engine, also will ich Lokalisierung auf einer anderen Ebene bauen. QQ schrieb: > Bitte schreibe Wörter aus. Versuche ich normalerweise. Ich poste nur grade von meinen Telefon und das ersetzt mir manchmal Worte mit nonsense. In der Regel lese ich meine Beiträge vor dem Abschicken nochmal und korriere alles was mir auffällt, leider übersehe ich hin und wieder welche. QQ schrieb: > Verzichte auf Denglisch, fremdsprachliche (Fach-)Begriffe verwendet man > nur, wenn keine äquivalenten deutschen existieren, oder diese > ungebräuchlich sind. > Falls das für dich unmöglich ist, empfehle ich dir gleich alle deine > Beiträge auf englisch zu verfassen. Sa ich relativ viel auf englisch lese und höre, wenn ich mich mit Elektronik, Robotern und Programmierung beschäftige sind die englischen Begriffe mir leichter geläufig. Ich kann aber gerne demnächst alle englischen Begriffe, die ich nicht spontan auf deutsch weiß erstmal durch Google Übersetzer jagen. QQ schrieb: > verzichte auf "Jugendsprache" Du meinst meinen Slang? Okay, dann versuche ich das abzustellen. chris_ schrieb: > Grundsätzlich bin ich immer für Diskussionen offen. > Wenn ich es richtig verstanden habe, hast du noch keine Erfahrungen mit > FPGAs und relativ wenig Erfahrungen mit Mikrocontrollern. Über die Fpgas hast du vollkommen Recht, aber bei Mikrocontrollern - denke ich zumindest - dass ich halbwegs kompetent bin. Ich habe mich hier nicht mit der genauen Umsetzung des Codes befasst, da sie nur als test gedacht war und keine vollständige Umsetzung des Projekts ist. Wenn ich als einziges Programm den Code für sensoren und den Motor pwm habe, ist auch der stm32f103 völlig ausreichend. Wenn ich aber die Teile des Codes in eigenständige Tasks in freertos aufteile, bekomme ich Probleme. Probleme in der Art, dass die Updates für das pwm nicht mehr in vorhersehbaren Zeitabschnitt kommen oder sensoren nicht regelmäßig ausgelesen werden. Allerdings habe ich noch keine Kommunikation mit einem Bus implementiert. Ich habe mir als Update rate ungefähr 120Hz vorgestellt. Auch wenn mein Code jetzt vielleicht nicht das optimale ist, was man theoretisch erreichen kann, bin ich mir sicher, dass er trotzdem passabel ist. chris_ schrieb: > Ich mache mal eine Abschätzung des Zeitaufwands für dich. Vielen Dank für die Einschätzung. So ungefähr hätte ich auch geplant. Da das aber ein Hobby Projekt ist und mich Zeitaufwand nicht schreckt stört mich persönlich das jetzt nicht. Hauptaspekt des Projektes war es den Umgang mit fpgas zu lernen und eine anspruchsvolle Aufgabe zu lösen, damit ich direkt lerne ordentliches und effizientes Vhdl/Verilog zu schreiben. Ich hätte ja stattdessen auch wunderbar ein vga pong Spiel bauen können, fand das aber relativ langweilig.
Duke Scarring schrieb: > chris_ schrieb: >> Meiner Einschätzung nach ist der Aufwand, ein Problem im FPGA zu lösen, >> wenn man es auch auf einem Mikrocontroller lösen könnte mit dem Faktor 5 >> an Zeitaufwand verbunden. > Du bist ein Optimist... Mag ja sein, aber momentan sind noch Semesterferien und ich habe nicht viel anderes zu tun. Selbst wenn es der Faktor 100 wäre schreckt mich das konzeptionell noch nicht ab. Das Lernen dabei ist mir persönlich wichtiger, als das Projekt schnell abzuschließen. Ich würde nur gern irgendwann in den nächsten 10 Jahren fertig werden, damit meine ehemalige Lehrerin das noch vor ihrer Pension zu sehen bekommt.
Der F103 ist halt der älteste STM32 den es gibt. Den H7 gibts mit 2 Kernen mit 480 und 240 MHz und ist Pi mal Daumen 20x schneller. PWM Hardware ist da auch deutlich besser als beim F103. Aber egal - Du kannst das natürlich auch mit nem FPGA machen, aber es wird wie gesagt deutlich schwieriger - und auch da hast Du mehr als genug Timing Probleme mit denen Du Dich herumschlagen musst...
Ich würde mich bald mal für eins der beiden Ziele entscheiden: - FPGA (SoC-Designs) lernen wollen - Roboter (nach)bauen wollen Beides zusammen funktioniert nur in sinnvoller Zeit (1-2 Jahre), wenn du auf bestehendes aufbauen kannst oder min. 5 Jahre detailliertes Wissen über das Verhalten der Synthesetools, Details komplexer Sprachen (wie VHDL), usw. ansammeln konntest. Der einzige Grund für mich, ein FPGA für sowas herzunehmen: Möglichst viel und stromsparend auf EINEM Chip zu machen. Für einen Kalmanfilter mit dickeren Matrizen gibt es da durchaus einen berechtigten Anspruch (been there). Ein weiterer Grund ist allenfalls noch, das System komplett für gesteigerte Safety-Ansprüche durchsimulieren zu können. Ansonsten gibt es unzähliche me-too-Lösungen dieser Art, besagte SRV1-Hardware kann das alles schon seit 2008 und ist längst nicht mehr der letzte Schrei. Mein Credo: Nicht träumen, machen (einfach mal anfangen). Dann offenbart sich sehr schnell, wo man Abstriche machen muss. Und zudem gilt immer wieder: Für FPGA-Entwicklung braucht man erst mal keine Hardware, sondern nur eine brauchbare Simulationsumgebung (kostenlos und gut: iverilog, GHDL).
Fitzebutze schrieb: > Der einzige Grund für mich, ein FPGA für sowas herzunehmen: Möglichst > viel und stromsparend auf EINEM Chip zu machen. Für einen Kalmanfilter > mit dickeren Matrizen gibt es da durchaus einen berechtigten Anspruch > (been there). Sowas war der Grund, wieso ich das machen wollte. Fitzebutze schrieb: > Für FPGA-Entwicklung braucht man erst mal keine Hardware, sondern nur > eine brauchbare Simulationsumgebung (kostenlos und gut: iverilog, GHDL). Das sollte ich mir eindeutig mal anschauen. Ich hab mir den Roboter als großes Überprojekt für das Lernen mit fpgas ausgesucht. Ich kann teilweise auch auf resourcen von einem Robocup Team zugreifen, die zumindest mal mit sowas rumprobiert haben (ob die das aktuell noch verwenden weiß ich grad nicht genau) Hast du/ habt ihr zufällig einen Tipp, was ich als zielplatform verwenden könnte, wenn ich einen Prozessor als "echte Hardware" haben will? Ich meine also den Prozessor nicht als softcpu... Wenn ich das mit dem simulieren richtig verstehe, muss ich ja wissen welchen Chip ich verwenden will, oder?
Stefan S. schrieb: > Hast du/ habt ihr zufällig einen Tipp, was ich als zielplatform > verwenden könnte, wenn ich einen Prozessor als "echte Hardware" haben > will? Ich meine also den Prozessor nicht als softcpu... A. M. schrieb: > https://pixhawk.org/ aktuell nutzen die einen STM32F765 und STM32F100 Ursprünglich für Drohnen entwickelt, gibt es Umsetzungen für sämtliche Land und Wasserfahrzeuge. Du müsstest nur eien weiteres Fahrzeug implementieren. Unterstützt sämtliche Schnittstellen und besitzt LL Treiber für Sensoren. Eine IMU ist bereits vorhanden. Nur die Motorsteuerung musst du zusätzlich lösen. Im einfachsten Fall könnten das Regler aus dem Modellbaubereich leisten oder du nutzt die vorhandenen PWM Ausgänge. weitere Resourcen: > https://www.dronecode.org/ > https://ardupilot.org/ > https://px4.io/ Wenn du selbst etwas zusammenstecken möchtest, sollten folgende Dual-cores ausreichend sein. A. M. schrieb: > Wenn du etwas maximal leistungsfähiges haben möchtest, dann schaue dir > die stm32h7 und i.mx rt1xxx an. Alle im QFP Gehäuse kann man mit dem Lötkolben auf eine selbst erstellte Platine löten. Stefan S. schrieb: > Wenn ich als einziges Programm den Code für sensoren und den Motor pwm > habe, ist auch der stm32f103 völlig ausreichend. Wenn ich aber die Teile > des Codes in eigenständige Tasks in freertos aufteile, bekomme ich > Probleme. Freertos auf einem stm32f103? Nicht dein Ernst? kein Wunder dass du da Probleme bekommst.
:
Bearbeitet durch User
Stefan S. schrieb: > Wenn ich das mit dem simulieren richtig verstehe, muss ich ja wissen > welchen Chip ich verwenden will, oder? Nein, eben nicht. Die Verhaltenssimulation ist erst mal völlig abstrakt ohne Pins und Gehäuse. Nur, wenn du dann bauteilspezifische Komponenten einbindest, musst du dir um die Zielhardware Gedanken machen. Aber bis dahin kannst du (und solltest es auch) ausgiebig mit LUTs und Flipflops üben. Und wenn dann die Simulation läuft, dann lässt man mal den Synthesizer mit einem großen FPGA-Typ drauf los und schaut, ob der mit dem Design zu 5% oder zu 95% gefüllt und auch noch schnell genug ist.
Stefan S. schrieb: > Hast du/ habt ihr zufällig einen Tipp, was ich als zielplatform > verwenden könnte, wenn ich einen Prozessor als "echte Hardware" haben > will? Ich meine also den Prozessor nicht als softcpu... Wenn ich richtig informiert bin, fährt dort ein vollwertiger PC mit. https://www.youtube.com/watch?v=_tmiu1wpp_E http://wiki.ros.org/
:
Bearbeitet durch User
Stefan S. schrieb: > Hast du/ habt ihr zufällig einen Tipp, was ich als zielplatform > verwenden könnte, wenn ich einen Prozessor als "echte Hardware" haben > will? Ich meine also den Prozessor nicht als softcpu... > > Wenn ich das mit dem simulieren richtig verstehe, muss ich ja wissen > welchen Chip ich verwenden will, oder? Für den ZynQ brauchst du eine passende ARM-Cosimulation. Das könnte aufwendiger werden, es selbst aufzusetzen (und die Cadence-Tools dazu kosten ordentlich). Mit RISC-V machen das einige in der Opensource-Szene (renode, qemu, ...). Da gibt's nur deutlich weniger FPGAs mit entsprechendem harten Kern. Ein Soft-Core muss bei Einsatz von Beschleunigern (was ja grade der Gag am FPGA ist) nicht schlechter sein. Zumindest kannst du den, sofern Source vorhanden, zyklengenau mit deiner Software simulieren.
Lothar M. schrieb: > Nur, wenn du dann bauteilspezifische Komponenten einbindest, musst du > dir um die Zielhardware Gedanken machen. Aber bis dahin kannst du (und > solltest es auch) ausgiebig mit LUTs und Flipflops üben. Wäre ein adc so ein hardwarspezifisches Bauteil? Ic brauch das mindestens um den Strom durch die Motoren zu messen. Fitzebutze schrieb: > Ein Soft-Core muss bei Einsatz von Beschleunigern (was ja grade der Gag > am FPGA ist) nicht schlechter sein. Ich war besorgt, dass der soft core ziemlich viele blocks braucht.
Stefan S. schrieb: > Wäre ein adc so ein hardwarspezifisches Bauteil? Ic brauch das > mindestens um den Strom durch die Motoren zu messen. Der ADC wäre wiederum ein externes Modell / Teil der Testbench. Auch das kannst du natürlich für die Simulation modellieren. Stefan S. schrieb: > Ich war besorgt, dass der soft core ziemlich viele blocks braucht. Meinst du BlockRAM oder Slices? Wie auch immer: "it depends". Das kannst du alles im Trockendock der Simulation mal aussen vor lassen und danach per Test-Synthese mit den Tools deiner Wahl den passenden Chip aussuchen. PWM-Motorensteuerung, div. Interfaces (SPI, UART, Ethernet) und RISC-V-Core passt z.B. locker in einen Spartan6 LX9, wenn Kameranavigation mit reinsoll, wird's eher ein LX45 und allenfalls bisschen DDRAM.
Ich meinte logik blocks (falls das so heißt). Du hast sie wahrscheinlich slices genannt. Fitzebutze schrieb: > Der ADC wäre wiederum ein externes Modell / Teil der Testbench. Auch das > kannst du natürlich für die Simulation modellieren. Das ist schön. Dann sollte ich mich mal mit simulation beschäftigen und mal bauen.
Stefan S. schrieb: > Dann sollte ich mich mal mit simulation beschäftigen und mal bauen. Und fang ganz vorn an mit elementaren Funktionen. Die wichtigsten Funktionen, die du im Schlaf kennen musst, sind Multiplexer und Schieberegister. Einer meiner Praktikanten meine mal nach einer ausgiebigen Exkursion: "The whole world is a shift register, isn't it?"
Stefan S. schrieb: > Wäre ein adc so ein hardwarspezifisches Bauteil? Ic brauch das > mindestens um den Strom durch die Motoren zu messen. Ein ADC im FPGA wäre evtl. so ein Bauteil. Allerdings kann man den meist auch einfach als BFM (Bus Functional Model) abstrahieren und nur sein Interface modellieren. Ein richtig hardwarespezifisches Bauteil ist ein Takterzeuger/-verteiler oder ein DSP-Block oder ein RAM-Block. Denn wenn man die optimal ausnutzen will, dann muss man sie herstellerabhängig ansteuern.
Lothar M. schrieb: > Und fang ganz vorn an mit elementaren Funktionen. Dank meinem Prof in digital Technik kann ich die meisten gängigen Baugruppen im Schlaf. Zumindest multiplexer, Logik Gatter und schieberegister. Aber ich schau mir das an und richte die Tage eine simulation ein. Lothar M. schrieb: > Ein richtig hardwarespezifisches Bauteil ist ein Takterzeuger/-verteiler > oder ein DSP-Block oder ein RAM-Block. Denn wenn man die optimal > ausnutzen will, dann muss man sie herstellerabhängig ansteuern. Ah, okay. Dann weiß ich jetzt zumindest genug Bescheid um anfangen zu können
A. M. schrieb: > Freertos auf einem stm32f103? Nicht dein Ernst? kein Wunder dass du da > Probleme bekommst. Das hat bisher super funktioniert zumindest in den bisherigen Projekten. Sehr stolz bin ich auf meinen "custom rs485" auf dmx converter. Da rennt freertos auf einem f103 ohne Probleme und parst sogar komplexere strings. Ist aber eine Geschichte für ein anderes subforum und eine Vorstellung.
:
Bearbeitet durch User
Mal ne dumme Frage: Gibt es smarte Motortreiber, die kommandiert werden können und an sonste alles selbst machen (Rampen und so) Die man also wie ein PIO mit nem paar Steuerbefehlen füttern kann? Oder muß wirklich alles sein Prozessor machen? mfg
~Mercedes~ schrieb: > Mal ne dumme Frage: > Gibt es smarte Motortreiber, die kommandiert werden können > und an sonste alles selbst machen (Rampen und so) > Die man also wie ein PIO mit nem paar Steuerbefehlen > füttern kann? > Oder muß wirklich alles sein Prozessor machen? > > mfg Gibt es, aber die sind entweder ein stm32 mit den Sensoren, oder extrem teuer und auch nur ein kleiner Mikrocontroller mit nem Treiberschip. Außerdem sind die die ich kenne alle entweder über spi bzw step direction steuerbar oder die teuren über rs232 oder canopen. Mit den canopen treibern habe ich persönliche Erfahrungen, dass die can Leitungen den Einsatz auf einer mobilen Roboter Plattform nicht so gerne mögen. Mfg
Ich kann bestätigen, dass FreeRTOS auf einem F103 problemlos läuft. Warum auch nicht, das gibts sogar für 8 Bit Mikrocontroller wie AVR. STM32 gabs noch gar nicht als FreeRTOS entwickelt wurde... Stefan S. schrieb: > dass die can > Leitungen den Einsatz auf einer mobilen Roboter Plattform nicht so gerne > mögen. Das dürfte dann aber eher ein Konstruktionsfehler sein. CAN ist i.d.R. sehr robust (ist in so ziemlich jedem PKW / LKW drin der in den letzten 25 Jahren gebaut wurde - also an CAN ansich liegts nicht).
Das liegt an den ekelhaft en steckverbindern, die zumindest unsere motortreiber hatten. Nicht am Protokoll an sich. Diese Treiber sind ja dafür gemacht, dass sie genau ein Mal bewegt werden. Zum einbauen und zum ausbauen. Die steckverbinder haben Stöße und schläge stellenweise nicht gut vertragen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.