Hindert mich allerdings jetzt auch nicht ernsthaft daran, beim Zusammenbau eines zweiten Exemplars mal einen Baubericht zu verfassen.
Ohhh. Wirklich? Ich fahre meinen archie mit der Platine RN-VNH2Dualmotor (Motortreiber-IC VNH2SP30) mit nem Huckepack der RN-Motorcontrol, Code à la L293/L298-Logik. Die kann ohne Kühlkörper bis etwa 4A je Motor bzw. Chip, mit Kühlung sind mit dem IC laut Datenblatt 40V/30A möglich. Das sollte doch für viele Fälle reichen. Gibts jeweils ohne Kühlkörper für einen Motor im Land des Lächelns für dreieinhalb Steine, für zwei Motoren für knapp sieben.
Ciao sagt der JoeamBerg
in diesem Topic wurde das bisher nie erwähnt, obwohl dieses Thema angesprochen wurde - danke für die Links!
Dann fehlen jetzt für den Super-Nachfolger nur noch die passenden Getriebemotoren mit Rotationsencodern für die angepeilte Fahrgeschwindigkeit.
Da hast du doch sicher auch was in petto?
Man tut was man kann... danke für die Links! ..
Jein. Fahrgeschwindigkeit Fußgängertempo ja (gestoppt bei aktuell ca. 7,3 kmh auf Turnhallenparkett), Drehmoment nein. Archie braucht bis max. 30% Steigung nicht so viel Drehmoment... Dann fehlen jetzt .. nur noch .. Getriebemotoren mit Rotationsencodern für die angepeilte Fahrgeschwindigkeit. Da hast du doch sicher auch was in petto?
Ciao sagt der JoeamBerg
Hallo zusammen,
sorry, wenn ich den Thread kapere.
Ich möchte da mal unseren JECCbot mini ins Rennen werfen: https://github.com/generationmake/JECCbot_mini
Darüber habe ich auch im anderen Forum geschrieben: https://www.roboternetz.de/community...Cr-3D-Druck%29
Den Roboter haben wir in den letzten Monaten unabhängig. Der ist zwar etwas kleiner als das ursprüngliche Konzept vorsah, dafür lässt er sich gut mit einem 3D-Drucker herstellen.
Leider haben wir auch keine besseren Motoren gefunden. Deshalb sind wir bei den RB35-Getriebemotoren geblieben. Mit 1:200 hat er sehr viel Kraft und kann wohl auch so 3 kg Ladung rumfahren, allerdings ist er sehr langsam. Mit 1:50 ist er schneller aber hat eben weniger Kraft.
Ein MotorShield für Adafruit Feather habe ich auch entworfen: https://github.com/generationmake/Hi...torFeatherWing
Die hat auf jeden Fall genug Leistung aber leider noch keinen Anschluss für einen Encoder.
Was haltet ihr davon?
Bernhard
An sich schon eine recht gute Idee, ein Feather-Shield anzubieten!
zum Konzept:
ich halte wegen des chronischen GPIO-Mangels auf Pis und Arduinos (wenn nicht im Mega/Due-Pinout) das Konzept von BrickPi3 am besten:
4 H-Brücken (+ 4 zusätzliche, z.B. analoge Sensorports, auf die man hier ntl verzichten könnte), samt 4 Rotationsencoder-Doppelpins, alles über SPI angebunden:
https://www.dexterindustries.com/bri...documentation/
C-driver:
https://www.dexterindustries.com/Bri.../program-it/c/
https://github.com/DexterInd/BrickPi_C
Für Arduino wird SPI für diese Zwecke schwierig werden, weil zeitkritisch und weil zusätzlich TFT, Touchcreen- und SD-Controller darüber laufen, und I2C ist hier eh zu langsam.
Ein schnelles UART wäre da VIELLEICHT eine Alternative, insb. auch in Verbindung mit dem ESP32-eigenen RTOS-pthread (std::thread).
Für den Pi allerdings wäre etwas BrickPi3-ähnliches mit mehr Motorpower sehr gut denkbar, auch Leistungs-Booster-Adapter-Endstufen dafür wären eine Idee.
021aet04 war mal so nett, mir nach meinen eigenen Angaben einen solchen Booster-Adapter für BrickPi3 zusammenzulöten, an dem man dann stärkere H-Brücken für stärkere Motoren betreiben kann - hat anfangs gut funktioniert, doch auf die Dauer hat wohl der BrickPi diese Methode nicht toleriert - 2 BrickPi Motorendstufen sind mit viel magic smoke durchgebrannt, seit dem habe ich diese Idee nicht mehr weiter verfolgt :-/
Unterm Strich ist der ESP32 aber immer noch sehr experimentell und unausgegoren, Adafruit Feather wird bei Treiber- und Programmierproblemen von Adafruit hundsmiserabel (!!) supportet, auch das ESP32 github repo scheint ein Sammelpunkt für überkandidelte Tech-Freaks zu sein, denen "normale" Arduino-Progger bei auftretenden Problemen am Ar*** vorbeigehen - und es gibt einfach keine vernünftigen Tutorials wie den Arduino Playground für ESP. Durch die ESP-eigenen Libs. die sich stark von den original-Arduino-Libs unterscheiden (Wifi- und webserver, SPI, SD) ist auch oft keine cross-Platform-Kompatibilität zu original-Arduinos mehr gegeben, die kochen da total ihr eigenes unkompatibles Süppchen.
Daher nutze ich die ESPs nur noch für meine bereits bestehenden iot Projekte (smart home etc) in sehr engen Grenzen.
Die Pis allerdings sind nach wie vor eine sinnvolle Plattform, da sie nur zu sich selber und zu Linux kompatibel sein müssen (das katastrophale wiringPi-Desaster außen vor), und über Zusatzports (HDMI, Audio, Cam, USB, WiFi, LAN) die 26-40 GPIOs nicht weiter tangieren.
Was für euer Konzept interessant wäre, wären aber in jedem Falle auch fertige Chassis zum Verkauf, denn z.B ich selber werde mir garantiert keinen 3D-Drucker kaufen oder es irgendwo fremd-drucken lassen. Und mit 4x 12V/10A-Motoren (rated current) mit Rotationsencodern im passenden Bausatz.
Geändert von HaWe (10.01.2020 um 18:28 Uhr) Grund: typo
Hallo HaWe,
gerne würden wir ein fertiges Chassis anbieten. Leider geht das aufgrund der voraussichtlich geringen Stückzahlen nicht bzw. wird unverhältnismäßig teuer.
Deshalb haben wir uns dazu entschlossen, das Ganze als 3D-Druck zu realisieren. Es kann auch mit günstigen 3D-Druckern wie zum Beispiel dem Creality Ender V3, der unter 200 Euro kostet, hergestellt werden.
Außerdem wollen wir ja gerade die Weiterentwicklung fördern, indem wir die Source Daten zur Verfügung stellen.
Beim Motortreiber hatten wir das Problem, dass die verfügbaren einfach zu wenig Leistung haben und damit zum Beispiel nur Getriebemotoren mit 1:200 Untersetzung angetrieben werden können und der Roboter damit sehr langsam ist. Es gibt zwar noch andere Motorshields, aber die sind meistens nur für einen Motor und dann muss man wieder basteln, wenn man die zwei Motoren eines Roboters antreiben will. Deshalb haben wir eben das FeatherWing entworfen, wo alles auf einer Platine ist. Generell bleibt aber das Problem bestehen, dass sämtliche Arduino Boards und ähnliche einefach zu wenig Pins haben, dass man da alle Funktionen sinnvoll unterbringt.
Mittelfristig ist unser Ziel, das wir die Arduino-Platinen mit einem Raspberry Pi verbinden und da dann die komplexeren Funktionen laufen lassen und den Arduino wirklich nur noch zur Ansteuerung der Motoren verwenden.
Bernhard
ja, im Prinzip bestätigst du ja meine Bedenken:
- zu wenige Pins insgesamt
- zu schwache Motoren
- zu wenig Motorports
- zu wenig Encoderpins
- keine kaufbaren fertigen Chassis (z.B. auch per Einzel-Druckauftrag via Shop, on-demand)
Hinzu kommen bei Adafruit Feather ESP32 (oder auch Feather M4!) und den dazu erhältlichen Featherwings Treiber/Lib- und Support-Probleme.
Raspi + Huckepack-HAT wie beim Brickpi3 (via SPI, mit 2 SAMD21 M0-cpus) - sogar stapelbar zur Vervielfachung der Ports!! - halte ich da für das bisher beste Konzept, doch auch hier fehlt es an Motor-Leistung.
Wenn Ihr dann so etwas alternativ anbietet, dann müsste man das ntl auch fertig kaufen können.
Geändert von HaWe (11.01.2020 um 11:46 Uhr)
Lesezeichen