PIC-Microcontroller

Hallo zusammen!
Hat jemand Lust mit mir die programmiertechnische Problemstellung eines RobotCars per MPLAB-Assembler anzugehen?
Vielleicht ist jemand auch damit beschäftigt oder interessiert, wobei nur der letzte Anstoß zur Verwirklichung fehlt?

Hier eine knappe Übersicht

Artikel-Nr.: ROBOT CAR KIT 01 (z.B. Reichelt)
Hersteller: JOY-IT Art.Nr. ROBOT03
4-Rad Antrieb mit Getriebemotoren 9V,je 200mA
4xLiFePo4 Zellen (12,8V )

MCU*:  PIC16F1939, MPLAB 8.92, Assembler
Module: L298 als PWM-Motorsteller
1x HC-SR04 US-Modul mit Elektronik (Hindernis voraus)
2x IR-Modul Seitenabstand rechts/links (Hindernis re/li)
2x Geschwindigkeitssensor
1x Strommessung (Blockade erkennen)
1x Batteriespannung messen
1x LCD4x16/20 für Debugging, Betriebszustand
*Micro-Controller-Unit

Der Aufbau geschieht derzeit noch auf dem Breadboard. Die MCU ist vorläufig (hat Pins im Überfluss). Bluetooth, EUSART (RS232), PWM habe ich schon begonnen/implementiert.
Hier noch z.B. einige Antriebsfunktionen die verwirklicht werden sollen:
F,B,S usw  Bluetooth commands zur Antriebssteuerung:
F beide Antriebsseiten vorwärts
FL/FR  Vorwärtsfahrt Links-/Rechtskurve
S beide Antriebseite STOP
B beide Antriebsseiten rückwärts (backward)
BL/BR Rückwärtsfahrt, Links/Rechtskurve
+ / - Geschwindigkeit erhöhen/vermindern

Diese Umsetzung auf den Antrieb hakt noch gewaltig!

Anbei Bilder vom derzeitigen, vorläufigen mechanischen Stand des Cars, bzw. dem Aufbau auf Breadboard. (IR-Sensoren rechts/links) US-Sensor für Hindernisse vorn voraus)
Das Chassis und der Antriebssatz stammt von Reichelt. Gesteuert wird mit unterschiedlicher Drehzahl der Antriebsgruppe rechts/links.

Bis bald?
Grüße Ottmar

Hier noch die Bilder zum dereitigen Stand RoboCar
Ottmar

nochein Bild...

Interessieren würde mich es schon leider habe ich keine Zeit für solche Projekte. 
Und mein Wissen über pic ist 15 Jahre alt (Assembler) da werde ich dir leider nicht wirklich helfen können.
Bin aber gespannt wie es weiter geht. 
Viel Erfolg und Spaß beim Basteln 

Cobraschock

Nunja, jeder so wie er kann... ;)
Bin mir auch nicht sicher ob ich die richtige Bluetooth-App habe, Im Moment erzeugt jeder Touch nur einen einzelnen Befehl. Ok für Fahrtrichtung. Für Speed wäre koninuierlich besser, also beim Touch eine Befehlsfolge z.B. +++++++ zur Erhöhung der Fahrgeschwindigkeit. Vielleicht weiß mir jemand eine passend App?
Ottmar

Hallo Ottmar!

Tolles Projekt von dir! Wird 'ne große Bereicherung!
Mitmachen von mir? Satz mit "X", wird wohl nix! Leider!

Dabei bin ich zumindest innerlich auch auf dem Absprung, irgend so'n Karren-Bausatz zu kaufen und die Programmierung der Steuerung zu erlernen, weil ich zwei Enkel habe, von denen der "Erste" im passenden Alter von 12 Jahren ist. Aber....
- zum Einen bin ich seit einiger Zeit total überfrachtet mit meinem altem Rollladen-Projekt. Die Mucken der µC-Steuerung habe ich im Griff, aber es steht die Überarbeitung und Neufassung der bald 25 Jahre alten Hard- wie Software an. Und just jetzt verabschiedet sich die Elektronik in einem der Rollladenmotoren. Da muss der R-Laden aufgerissen, fast alle rausgerissen werden, Mot wechseln, Aufhängung wechseln, etc., etc.
Dazu kommt, das bei dem beabsichtigten eigenen Versuch nicht daran gedacht ist, bis ins Detail Hardwarekomponenten (HwK) in Assembler anzusteuern. Da schaue ich mal, was es an einfacher Prog-Sprache am Markt gibt.
Auch das sei noch gesagt, wenn auch ungerne: Etliche der Techniken fürs Ansteuern der HwK habe ich entweder noch gar nicht ausprobiert, oder es liegt noch sehr im Anfängerbereich. Bis ich mich da eingearbeitet hätte... Dafür fehlt mir in der Tat jetzt auch die Zeit.
Das bedauere ich, denn ich finde dein Projekt unheimlich gut. Werde mich aber wohl auf die Rolle des Beobachters begeben müssen.
Die MPLAB-Version ohne "X" ist doch eine inzwischen wirklich alte. Möchest du nicht wenigstens eine aus der X-Version bis Vers. 5.35 verwenden? Die Allerneuste ist quasi eine komplett neue Programmiersprache, die mit ihren beiden Vorgängerversionen nur noch den Oberbegriff gleich hat.
Grüße, picass

Nachtrag: habe gerade bei Reichelt geschaut. Das eigentliche Fahrgerät ist mit 20 € ja recht preiswert. Aber wie wird das gesteuert? Eine Art Lenkung habe ich auf die Schnelle nicht gesehen.

Hi picass,
Dein Zuspruch freut mich. Das ASM des alten MpLab 8.92 hab ich so einigermaßen drauf und die MCU's die ich verwende sind noch alle damit verwendbar. Es ist einfach spannend für mich die entsprechenden Funktionen auszutüfteln.
Gelenkt wird das RoboCar mit unterschiedlicher Drehzahl der rechts- / linksseitigen Räder.

Ich weiß jetzt nicht so recht, wie ich da nicht direkt damit befasste Interessierte daran teilhaben lassen könnte.
Da ist es schon einfacher auf konkrete Fragen zu antworten oder wenn jemand ein ähnliches Projekt vor sich liegen hat.
Grüße von Ottmar
P.S. Viel Erfolg bei Deinem Rolladenprojekt!

Hallo Ottmar!
Es tut mir in der µC-Seele weh, an deinem Projekt voraussichtlich nicht teilnehmen zu können. :( Zumindest "begleiten" - also dauernd verfolgen - würde ich es schon. Vielleicht kann ich in irgendeiner wenn auch eher geringen Weise was beitragen. Wie hälst du es z.B. mit dem Routen von Platinen? Selbst mache ich so was sehr gerne, evt. gibts da ja 'nen Ansatz.
Der zugrunde liegende "Karren" - pardon für die respektlose Bezeichung - zeichnet sich aus durch geringen Preis und Vierrad-Antrieb. Letzteres spräche für extreme Geländegängigkeit. Leider wird das aber durch das Fehlen einer echten Lenkung im wahrsten Sinne des Wortes ausgebremst. Stelle ich mir auch schwierig vor, das Lenken in so indirekter Weise umzusetzen. Das liefe dann so ähnlich wie bei Panzern: die kurven-innere Kette wird gebremst, rsp. nicht angetrieben, die kurven-äußere bekommt zusätzliche Energie. Das wird 'ne Herausforderung für den Programmierer.

Das MPLAB: da würde ich dir dringend - sehr dringend - zu der "mittleren" Version raten, also der mit einem nachfolgenden "X" bis max. v5.35. Die Syntax der Befehle ist bis auf ganz wenig Ausnahmen identisch, aber... aber es fällt die Notwendigkeit der dauernden Bank-Umschaltung weg und vor allem ist man damit näher an aktuellen Prozessoren. Das merke ich gerade bei meinem Rollladenprojekt. Der stonealte PIC16F84 - befüllt mit Progs aus dem alten Nicht-"X"-MPLAB - ist entweder auf dem Markt nicht mehr zu bekommen oder kostet über 8 €. Der von mir bislang bevorzugte "Nachfolger" PIC18F14K22 ist noch zu aktzeptablen Preisen erhältlich, aber von Microchip auch schon fast abgekündigt. Ein pin-kompatibler, aktueller Nachfolger des Nachfolgers ist mit erweiterten Funktionen auch für weniger als 2 € erhältlich und findet die volle Unterstützung mit Progs, Entwicklungsboards, Sonderaktionen, etc., etc.
Wenn ich heutzutage irgendwas bearbeite, dann versuche ich schon, die Oldies auszumustern, weil Aktuelles besser erhältlich, sehr viel preiswerter und vor allem auch voll unterstützt wird.
Grüße, picass

Hallo picass!
Es ist nett von Dir und wirklich freundlich, mir mit dem Erstellen einer Platine aushelfen zu wollen. Allerdings wird die Platine, sobald ich den Breadboardaufbau nicht mehr brauche, etwa so wie eine Arduino-Uno Platine aussehen. Hab mal einen Rohentwurf als Bild angehängt.

Mein Ziel ist nun wirklich nicht, daß ich mit dem RoboCar durch das Gelände preschen möchte. Vielmehr soll es so gut es eben mal geht lenkbar sein ,um letztlich Hindernissen selbstständig  auf dem Zimmerboden ausweichen zu können. Ob mir das gelingt wird sich zeigen.
Natürlich habe ich schon MPLABX angeschaut und auch ein wenig herumprobiert. Aber derzeit möchte ich  nicht umsatteln. Das Banking ist natürlich nicht gerade geschickt, hält sich aber nach der Initilisierung der MCU-Module/Register iim eigentliche Code-Ablauf in durchaus erträglichen Grenzen.

Mit der Zeit haben sich bei mir eine ganze Anzahl von unterschiedlichen Pic's angesammelt, das  reicht  meinem ersten 16F84 weiter über 16F6... 16F1..  midrange bis zu den 18F... 18F24.... Da ich ja von Deinem bevorzgten Pic18F14K22 gelesen habe, konnte ich es mir nachtürlich inzwischen auch nicht verkneifen mich mit dessen Innenleben zu beschäftigen...

Ich ziehe auch fast nie ein Projekt bis zum fertigen Gerät durch. Mir geht es hauptsächlich um das Verständnis und den Gebrauch der Module sei es Timer, ADC, Comparatoren PWM, Touch. SR-Latch und und und...
Wenn der Testaufbau  meine  Erwartungen erfüllt hat, wird dieser meist auch aufgelöst. Nur wenige Projekt fanden bisher in einem Gehäuse ihren Platz. Das sind z.B.  meine DCF77-Uhr mit dem 16F628, ein Kondensator Kapazitätsmessgert, die Messung des Innenwiderstandes von von  Enzelzellen (Batterien-/Akku). Ein LIPo-Lader ist vor Kurzem fertig geworden, aber ein Gerät lohnt sich für Einzelzellen nicht, da  gibt  es zum Spottpreis break-out Platinchen mit USB-Buchse und speziellem Ladechip.

Heute versuche ich mal einen groben Einblick in die erste Phase der Antriebssteuerung zu geben (vgl. angehängte Pdf-Datei). Anmerkung dazu: Den ASM-Code pflege ich stets  ausführlich zu dokumentieren, teils mit Übernahme des Textes aus dem Datenblatt.
mit Grüßen Ottmar

MPLAB: Ich hatte es kurz angesprochen, möchte nur noch mal darauf hinweisen, dass MPLAB X keineswegs gleich MPLAP X ist. Da hat es ab Version 5.40 nicht nur einen Paradigmen-Wechsel gegeben, da ist quasi eine ganz neue Sprache entstanden. Und die ist aus meiner Sicht verdammich schwer zu erlernen. Den irren Aufwand für solchen Umstieg werde ich mir auf keinen Fall antun. Bis v.5.35 alles paletti, danach Tabula Rasa.

Zitat von: Ottmar in 12.06.2023, 13:38:21 CESTIch ziehe auch fast nie ein Projekt bis zum fertigen Gerät durch.

>:D  >:D

Wenn du in meine Regale mit gesammelter Elektronik aus etlichen Jahrzehnten schauen könntest, würdest du eine Unmenge an Schaltungen finden, aber so gut wie keine mit Gehäuse. Lange Zeit war mein meist gebrauchtes Netzteil in einem Karton untergebracht. Seit einiger Zeit und natürlich für wichtige Anwendungen wie dem Rollladenprojekt finde ich mich aber auch zum Gehäuse-Verbau bereit. In deinen Maintext schaue ich gleich mal rein.
Grüße, picass

Zitat von: picass in 12.06.2023, 19:00:46 CESTDa hat es ab Version 5.40 nicht nur einen Paradigmen-Wechsel gegeben, da ist quasi eine ganz neue Sprache entstanden.

Na ja, die eigentliche Sprache ist noch absolut die gleiche,
da die Befehle im PIC hardwaremäßig drin sind.
Da kann man durch einen neuen Assembler wenig ändern.

Drumherum, mit Anlegen von Variablen, Interruptvektoren, usw. dann schon.
Nervig, kann man sich aber mit etwas Willen schnell aneignen ;-)

Am meisten hat mich gestört, dass es die Templates nicht mehr/noch_nicht gibt.
Dann wäre der Umstieg ein Klacks...

Zitat von: Ottmar in 10.06.2023, 11:06:29 CESTHallo zusammen!
Hat jemand Lust mit mir die programmiertechnische Problemstellung eines RobotCars per MPLAB-Assembler anzugehen?
Vielleicht ist jemand auch damit beschäftigt oder interessiert, wobei nur der letzte Anstoß zur Verwirklichung fehlt?

Hier eine knappe Übersicht

Artikel-Nr.: ROBOT CAR KIT 01 (z.B. Reichelt)
...

Interessant, wenn ich gerade etwas mehr Zeit hätte,
könnte ich mir das auch vorstellen.

Wir benutzen solche Bausätze auch für erste Studierendenprojekte und
hier liegen einige davon rum ;-)

Kaufen tue ich die normalerweise hier:
https://www.roboter-bausatz.de/p/bausatz-4wd-smart-car-chassis-fuer-roboter

Meist allerdings diese (bekommt man gelegentlich für unter 6€)
https://www.roboter-bausatz.de/p/yourdroid-2wd-smart-car-chassis-fuer-diy-roboter

Nur mal in den Raum geworfen:
Solltest du Teile brauchen, ich kann mein 3D Drucker als Arbeitstier anbieten. Aber bitte nicht erwarten das ich 20 mal Drucke bis es Top aussieht, bin mehr der "es muss Funktionieren" Mensch. Wenn ein Zahnrad alle Zähne hat reicht mir das meist erstmal :P

Wenn ich die Zeit hätte würde ich vermutlich den Robi komplett selbst Drucken, die Platine Fräsen (ich habe immernoch
keine gefräst seit dem Umbau) und natürlich das Programm schreiben.
Aber wie das so ist kommt die Arbeit, Kinder,Haus,Garten usw. und dann siehts im Moment schlecht aus mit der freien Zeit.

Gruß

Cobraschock

Sehe ich das richtig, dass die Steuerung des Cars über Fernsteuerung erfolgen soll und das vom PC aus? Oder gibt es da 'ne App fürs Smartphone?

Jetzt kommt das, was ich selbst bei einigen meiner früheren Projekte, für die ich irgendeine Detailfrage hatte, bisweilen wenig schätzte: Keine Antwort auf meine Frage, stattdessen eine Replik wie solche: "Warum machst du es nicht (ganz) anders?"
Aus meiner Sicht erscheint mir die Beherrschung von gleich vier Motoren und das via Assembler als sehr aufwendig, zumal jeder Mot gleich zwei Funktionen ausführen muss: Antrieb und "Mithilfe" bei der Steuerung. Ein Motor an der Hinterachse und ein Servo vorne für die Steuerung wäre für mich leichter überschaubar.
Grüße, picass

Hallo zusammen,
freut mich daß einige aus dem Forum Interesse an meinem Projekt RoboCar zeigen. Nun Ja, den Bausatz habe ich nunmal schon erworben und es wird wohl auch kein Nachfolgermodell geben. Ich bleibe auch wenigstens für dieses Mal noch bei MPLAB 8.92.

@Cobraschock
Danke für das Angebot, aber alle benötigen Teile habe ich schon beisammen.

@picass
Gesteuert wird per Bluetooth und mit dem Smartphone. Bis jetzt bin ich bei der App "Arduino bluetooth" gelandet, welche aber nicht  unbedingt das Gelbe vom Ei ist. Es ist auch nicht beabsichtigt, alle 4 Motoren einzeln anzusteuern. Wie schon mal gesagt, die Motoren der Linken Seite haben gemeinsam ihre eigene PWL4 und die Motoren der rechten Seite ihre eigene PWL5.

Zitat von: picass in 14.06.2023, 09:58:39 CESTJetzt kommt das, was ich selbst bei einigen meiner früheren Projekte, für die ich irgendeine Detailfrage hatte, bisweilen wenig schätzte: Keine Antwort auf meine Frage, stattdessen eine Replik wie solche: "Warum machst du es nicht (ganz) anders?"

Welche Frage an mich war das?

Derzeitiger Stand: Die erste Erprobung der Motorsteuerung war ein Erfolg, also vor und zurück, ebenso die Einstellung des Duty Cycle, um die Motoren mal langsam, mal schneller laufen zu lassen.

Derzeit tüftele ich an der Steuerlogik.
Meine App gibt bei jedem Tastendruck nur einen Steuerbefehl in Form eines einzelnen ASCII-Zeichen aus, leider nicht als stream.
F = Vorrwärts, B = Rückwärts , L =Links, R=Rechts, S=STOP, + = schneller, - = langsamer

Die Logik muss etwa so aussehen, wobei stets das aktuelle Zeichen mit dem vorhergehenden kombiniert
wird.
Also 
F F  Vorwärts (2x Taste vorwärts)
F+L  Vorwärts Linkskurve (+ Taste L)
F+R  Vorwärts Rechtskurve(+ Taste R)
B    STOP (vom Programm) kein schlagartiges Umschalten Vor-Rück
B+B  Rückwärts
B+L  Vorwärts Linkskurve
B+R  Vorwärts Rechtskurve
F    STOP kein schlagartiges Umschalten Vor-Rück
Das Alles und und... soll auf einem HD44780-LCD Monitor dargestellt werden.

Bis dahin also voraussichtlich ein ziemlich ruckhaftes Fahrverhalten beim Richtungswechsel. Wenn es mir zu dumm wird komme ich wohl um eine 2-Knüppel-Fernsteuerung nicht herum (Gehäuse mit Bluethoothmodul und MCU). Der Knüppelweg läßt sich ja relativ einfach per ADC auslesen, braucht halt für simultanes Steuern 3 ADC-channels und mehr Rechenarbeit für die MCU (fosc=16MHz).

Zur Zeit kommt mir das schöne Wetter voll in die Quere 8) ... aber es regnet auch bestimmt mal wieder.

Mit Grüßen Ottmar

Hallo, ich kann Dir hier nur bei der "Feinarbeit" helfen.

ZitatB+L  Vorwärts Linkskurve
B+R  Vorwärts Rechtskurve

ist dir da ein Fehler unterlaufen, müßte es nicht rückwärts Rechts- bzw. Linkskurve heissen?

Zitatdieses Mal noch bei MPLAB 8.92

Man kann auch bei MPLAB-X den alten Compiler installieren. Das mache ich, da ich tausende Seiten Text nicht überarbeiten möchte.

Viele Grüße
pic18 aus St. Peter-Ording

Zitat von: Ottmar in 14.06.2023, 23:59:39 CESTWelche Frage an mich war das?

Eher keine Frage, sondern der Hinweis, dass aus meiner Sicht die Steuerung eines Fahrzeugs mit "echter" Lenkung wesentlich einfacher handzuhaben wäre. Man sieht es ja auch an dem von dir genannten ruckhaften Verhalten: so steuern Panzer. Das mag heutzutage - z.B. bei den "Leo's" - mithilfe von Elektronik auch feinfühlig ablaufen, aber ohne die würde nur "geruckt". Aber du hast dich ja für die eine Version entschieden, und es ist mitnichten meine Absicht, dich von deinem Weg abbringen zu wollen.
Guter Erfolg bei deinen weiteren Arbeiten! :)
Grüße, picass

RoboCar Info 02 Erste Ergebnisse

Hallo,
heute mal ein kleine Info wie es bei mir dem dem RobCar inzwischen weitergegangen ist.

Zur Steuerung ist die App "Bluetooth CAR Controller" (Andi)die bis jetzt am besten geeignete App, welche mir in die Hände gefallen ist. Zur App gibt es ein Video auf Youtube, das Vieles, was beim ersten Blick nicht ganz einsichtig ist erklärt.Fahrtrichtung Kurven drehen aufder Stelle läßt sich alles machen. Leider ist die Geschwindigkeit nur mit einem etwas ungeschickt winzigen Touch-Schieberegler einzustellen.

MCU ist jetzt PIC16F1936
Von den 4 PWM-Modulen verwende ich PWM4 und PWM5 die Initialisierung von PWM ist im Datenblatt  gut erklärt. Leider beginnen die Motoren (die Räder) erst ab Duty Cycle (DC) ca 50% (f=7,8kHz) zu drehen.

Bluetooth Modul HC-05
Ein recht einfache zu handhabendes Teil, mit dem ich schon auf dem Arduno etwas rumgespielt habe. Sehr einfach anzuschließen. Allerdings verwende ich derzeit mur den Tx-Pin, da ich (noch) nicht weiß wie ich von dem Modul Daten auf mein Smartphone bekommen soll.

EUSART
Das schrecklich kompliziert Wort, welches hinter der Abkürzung steht, spare ich mir. Der Empfang von Kommandos aus der App  mit 9600 Baud ist nach Datenblatt rasch eingerichtet, wenn man weiß, dass auf jeden Befehl für eine Fahrrichtung, z.B. "F" (vorwärts) beim Loslassen sofort ein "S" (Stop) gesendet wird.

Kommando-Auswertung
Dies geschicht recht einfach, z.B. "B"(rückwärts) wobei das "B" als Ascii-Wert aus dem Register "RCREG" z.B. in "tmpRCREG" gelesen werden kann (prinzipielless Vorgehen):

movlw "B" ;Kommando für Rückwärts
xorwf tmpRCREG,w
btfss STATUS,Z
GOTO cmd_L      ;Auswertung ob "L" (LEFT) auszufürhen ist
BANKSEL PWM_LAT
bcf  PWM_LAT,EN1 ;schaltet linke Moorgruppe auf vorwärts
bsf  PWM_LAT,EN2
bcf PWM_LAT,EN3 ;schaltet  rechte Motorgruppe vorwärts
bsf PWM,LAT,EN4
BANKSEL 0

cmd_L:
 movlw "B" .......


Hinderniserkennung
Seitlich werden IR-Module verwendet, deren Ausgang ab einer mittels Poti einstellbaren Entfernung zum seitlichen Hindernis auf LOW geht
Das Modul HC-SR05 ist einfach zu handhaben. Neben der Versorgungsspannung ist noch der Anschluss TRIGGER und ECHO vorhanden. TRIG wird für  mindesstens 11 us auf HIGH gelegt

Danach sendet das Modul einen US-Burst. Der ECHO-Pin geht dabei gleichzeitig auf HIGh. Sogleich wird dann z.B. der 16Bit-TMR1 gestartet und sobald ECHO=LOW ist, angehalten.

Angenommen fosc der MCU sei 8MHz dann ist der TMR1-Takt fosc/4 = 2MHz, Periodendauer = 0,5us. TMR1 = 2500
Die Entfernung zum Hindernis errechnet sich dann einfach:
Entfernung = 343m/s * 2500 * 5^-7s / 2 = 0,21m

Auf einem LCD 4x20 werden dann alle interessanten Daten ausgegeben:
Empfanges Kommando,
Duty Cycle Antrieb rechts, links
Entfernung zum voraus befindlichen Hindernis,
Info zu Hindernissen rechts/links
Spannung der Antriebsbatterie.

Soweit der derzeitige Stand.

mit Grüßen Ottmar

Es sieht so aus, als ob du sehr fleißig gewesen bist!

Zitat von: Ottmar in 29.06.2023, 23:28:46 CESTRoboCar Info 02 Erste Ergebnisse
.Fahrtrichtung Kurven drehen aufder Stelle läßt sich alles machen. Leider ist die Geschwindigkeit nur mit einem etwas ungeschickt winzigen Touch-Schieberegler einzustellen.

Drehen auf der Stelle....., sag ich doch: der Antrieb wie ein Panzer. Aber.... .... mit Verlaub:
wenn der auf der Stelle dreht, was passiert mit den furchtbar vielen Käbelchen, welche in das Steckbrett führen? An dem hängt ja auch noch Diverses! Und Stichwort "Geschwindigkeitsregelung": was passiert, wenn der dann auch noch Fahrt aufnimmt?
Grüße, picass

Hi Picass
???... ??? das Steckbrett mit seinen Verbindungen zum Car ist doch nur, um noch Änderungen vornehmen zu können. Natürlich bekommt die Schaltung auch eine Platine und ihr zuhause auf dem Chassis des Cars. Hi, :) hi,hi - kleiner Schelm :-\ ? wolltest mich wohl ein wenig auf den Arm nehmen?
Zum Trost: bin auch kurz davor die Platine (ohne rumhängende Leitungen) anzufertigen.

Auf der Stelle drehen, ja, sieht eben robotermäßig aus. Die App erlaubt auch die Funktion Fahrt + links-/rechts abbiegen. Leider nicht analog. Behelfslösung funkioniert an der aufgebockten Chassis: Fahrt voraus, zum Abbiegen nach links/rechts am innenliegenden Antrieb PWM ums z.B. 50% verringern, PWM am außenliegenden Antrieb beibehalten -> kurven

Cmd_Evaluate:
; Switches the motors for the selected direction/cornering
...
cmd_eval_G:                ;KURVE vorw. LINKS Drive 5 halbe Geschwindigkeit    
   movlw    "G"            ;FORW+LEFT
   xorwf    tmpRCREG,w
   btfss    STATUS,Z
   GOTO     cmd_eval_I     ;Rechtskurve
   ;
   movf     DC5,w          ;eingestellte Fahrgeschwindigkeit
   rrf      tmpDC5,f       ;temporär PWM5 auf 50% von PWM4
   movf     tmpDC5,w       ;ins WREG
   BANKSEL  CCPR5L        
   movwf    CCPR5L         ;an ANTRIEB zuweisen
   BANKSEL  0
   ;
   movlw    b'00000101'    ;b7:4=0000  b3:0 = EN3:0 = 0101
   GOTO     cmd_drive_Y    ;Motoren vorwärts Antr.re 50%
   ;
...
   RETURN

Aber ein von mir mit Bluetoooth zu versehener Nintendo-nunchuck (Einhand-Joystick) +HC-05+MCU müßte es möglich machen, beide Antriebsseiten unabhängig voneinander mit unterschiedlichem PWM analog zur X-Y-Potistellung anzusteuern. Habe das schon mit 'nem Mini-Joystick (kabelverbunden) erfolgreich experimentiert... aber eines nach dem anderen...

Grüße Ottmar

Zitat von: Ottmar in 30.06.2023, 22:42:04 CEST.......Behelfslösung funkioniert an der aufgebockten Chassis....

Nix! Weder Kleiner noch Großer! Du hattest vergessen, das Aufbocken zu erwähnen. Und genau darauf wollte ich raus und gehe nach wie vor davon aus, dass dieses Car mit den vielen abreiss-gefährdeten Kabelverbindungen eben noch keinen realen, sondern nur einen virtuellen Return ausgeführt hat. Was in der Theorie funktioniert, kann in der Praxis unangenehme Überraschungen bereit halten. Da wären - nur als Beispiel - die Fragen, was der Untergrund zu den Drehmanövern sagt und ob der Anpressdruck und die Auflagefläche der Räder auch gleich ist.
Grüße, picass

RoboCar Info 03 - RoboCar fährt!

Hallo,
Nachdem alle Tests erfolgreich waren, wäre es mir selbst eine Zumutung gewesen, länger auf die erste Probefahrt zu warten. Die Herstellung einer Platine wird einfach aufgeschoben. Daher wurde die Schaltung auf einem kleinen Breadboard nochmals aufgebaut. Ein Platz für das weitere, bereits in Software und Technik getestete Zubehör, wie Ultraschall- und IR-Hinderniserkennung, muss noch gefunden werden.

Es braucht nicht viele Worte, das Video zeigt die ersten kleinen Fahrmanöver. Leider ist die Qualität schlecht damit die Beschänkung von Uploads auf 1024kB eingehalen werden konnte.

Ein Nintendo-Nunchuck (mit Joystick )ist bestellt. Damit werden rundere Kurven möglich sein, denn dieser wird als Bluetooth-Handsender umgebaut. Da kann ich gleich noch ein paar kleine Erfahrungen in der Datenübertragung per USART sammeln.

Die Bilder zeigen noch keinen entgültigen Aufbau.Bei dem PIC1936 sind noch viele I/O's frei, da kann man seiner fantasie noch etwas freien Lauf lassen. ;)

Bis ein ander Mal - Ottmar

Sieht doch super aus, der Karren ist sehr beweglich und jetzt schon gut zu steuern! Kompliment für die bislang geleistete Arbeit! Dass es dir gelungen ist, den Drahtverhau auf ein anderes, kleineres Brettboard zu verlegen, verdient auch Anerkennung.
Grüße, picass

Ja danke picass! :)
Was ich nicht zeigen konnte (hätte für 2 Handys dann drei Hände gerbaucht): Das Auto fährt auch so "la la" runde Kurven, wenn zu Vor- oder Rückwärts noch Seite gegeben wird. Das Tastverhältnis der PWM an der Kurveninnenseite wird dann um 50% reduziert.

mfG Ottmar

Du leistest da schon enorme Entwicklungsarbeit! :)  Anerkennung!
Grüße, picass

RoboCar Info 04

Hallo,

RoboCar ist immer noch in Arbeit, ist allerdings ein wenig weiter fortgeschritten. Inzwschen wurden einige Sonderfunktionen wie Scheinwerfer, Rücklichter und Fahrtrichtungsanzeiger verwirklicht. Die große Aufgabe steht jedoch noch bevor:

Berechnung von Ausweichmövern bei Hindernissen.
Es gilt als dem RoboCar ein wenig "Intelligienz" einzupflanzen.

Die Hinderniserkennung mit Infrarot zu den Seiten hin funktioniert und auch die Entfernungsmessung per Ultraschall arbeitet perfekt. Ich frage mich derzeit, ob es vorteilhaft sein könnte, den Ultraschallseensor auf ein Servo zu setzen und zu schwenken. Einen Timer für die PWM hätte ich dafür noch übrig.

Nun soll aus den Informationen der Abstandssensoren ein Ausweichmanöver errechnet werden. Bis dahin, für den Fall daß es jemanden interessiert, anbei der bisherige Programmablaufplan.

Bild 1: Die Eingangsschleife zur Hinderniserkennung und zum Empfang des Bluetooth-Signals
Bild 2: Die Antriebssteuerung, Fahrtrichtung und Geschwindigkeit.

mfG Ottmar

RoboCar Info 05

Hallo,

Wieder mal ein kleiner Zwischenstand zu meinem RoboCar-Projekt. Das Fahrzeug hat inzwischen seine Sensoren anmontiert bekommen und damit es sich im Dunkeln nicht verirren wird, auch eine Beleuchtung erhalten - Scheinwerfer nach vorne und Rücklichter.

Dazu ein visueller Eindruck.

Vielleicht ist es interessant zu wissen wie ich das Programm gestaltet habe um dem RoboCar "Leben" einzuhauchen. Dazu füge ich ein Listing mit einer schematischen Übersicht bei.

Solch ein Programm spalte ich gerne in mehrere INCLUDE-Files auf, in denen alle spezifischen Funktionen für den Programmabschnitt enthalten sind.

16F1936_RoboCar2023.ASM
; Projekt:  Control of RobotCar via Bluetooth
; MCU:      PIC1F1936 (28Pin)
; Info:    Program Memory Words Used:  1294
;          Average duration of a program cycle
;          with LCD ca. 38ms (for program development)
;          without LCD (final) around ca. 2.7-4ms
;          fosc=8MHz
02_HEADER_RoboCar2023.INC -Definitionen, Labels
03_INIT_Robo2023.INC  -Ports, Module, Funktionen
04_DRIVE_Robo2023.INC  -Auswertung Rx-Kommandos,
                        und Antriebssteuerung
05_US_Robo2023.INC    -Ulatraschallmessung
06_ADC_Robo2023.INC    -noch nicht im Programm integriert
07_LCD_Robo2023.INC    -LCD-Ausgaben nur zur Ewicklung#
HD44780_2Wire.INC      -LCD-Initialisierung

Leider überschreiten die weiteren Einzelheite das Zeichenlimit von 5000 für diesen Beitrag (siehe folgenden Beitrag)
Für anderweitige Ideen/Vorgehensweisen habe ich gerne ein offenes Ohr.

mfG Ottmar

RoboCar Info 5-1

Leider sind mit dem vrgesehene Text im Codefenster erneut die 500 Zeichen überschreitten, also teile ich das nochmals auf und schreibe noch einen Folgebeitrag

mfG Ottmar


16F1936_RoboCar2023.ASM
=======================
; Projekt:  Control of RobotCar via Bluetooth
; MCU:      PIC1F1936 (28Pin)
; Info:     Program Memory Words Used:  1294
;           Average duration of a program cycle
;           with LCD ca. 38ms (for program development)
;           without LCD (final) around ca. 2.7-4ms
;           fosc=8MHz
   #INCLUDE <02_HEADER_RoboCar2023.INC>   ;Labels, definitions, constants, etc
   #INCLUDE <03_INIT_Robo2023.INC>        Initialization of all required
                                          ;registers, ports, PWM, EUSART, LCD, etc
   main;
      CALL     Debug_Menue    ;Creates the LCd menu for function
                              ;testing and troubleshooting
   main_loop:
      CALL     US_Measure     ;Send/receive US-Burst/Echo
      CALL     US_Distance    ;Calculates the distance from US-runtime
      CALL     Obstacle_Dodge ;Calculates required avoidance of obstacles 
      btfsc    Flags,EXTRA    ;=1 execute functions when waiting for rx cmd
      CALL     Cmd_Extra      ;Switching of special functions light, horn
         ;
   main_rx_loop:              ;waiting for bluetooth command    
      btfss    PIR1,RCIF      ;=1? New data received with USART?
      GOTO     main_rx_loop   ;no, try it again
      ;CALL  Rx_Error         ;Error checking RCSTA,FERR:OERR (disabled)
      BANKSEL  RCREG          ;bank3
      movf     RCREG,w        ;copy received command
      BANKSEL  0
      movwf    tmpRCREG       ;contains received Ascii code
      ;
      CALL     Out_RX         ;display received Bluetooth-command (cmd)
      CALL     Eval_Cmd       ;evaluate/execute command ->04_DRIVE_Robo
   GOTO  main_loop
;----------------------------------------
      #INCLUDE <04_DRIVE_Robo2023.INC> ;Drive control subprograms
      #INCLUDE <05_US_Robo2023.INC>    ;ultrasonic distance measurement
      #INCLUDE <07_LCD_Robo2023.INC>   ;LCD output, binary BCD conversion, etc
      #INCLUDE <HD44780_2WIRE.INC>     ;initialization, DDRAM, DATA
   END
;-----------------------------------------
SECTIONS IN FILE 02_HEADER_ROBOCAR2023.INC
;  --SUPPRESSED WARNINGS
;  --MCUDEFINITION / CONFIGURATION
;  --VARIABLES DEFINITIONS
;    LABELS & CONSTANTS
;  --L298_PORT (PORTA)
;  --LCD_PORT (PORTB)
;  --AD_PORT  (PORTB)
;  --SCI_PORT EUSART (PORTC)
;  --US_PORT (PORTC)
;  --PWM_PORT (PORTC)
;  --DDRAM ADDRESSES for output in debug menu
;    LCD-PROPERTIES
;    RESET VECTOR
;    INTERRUPT VEKTOR
         ISR
            isr_tmr6
;----------------------------------------  

RoboCar Info 5-2

Hier also der letzte Teil zur Programmübersicht von RoboCar223

mfG Ottmar

MODULES IN INIT PROJECT    ROBOCAR2023
03_INIT_Robo2023.INC
   OSCCON
   PORTA    L298_PORT
   PORTB    LCD_PORT
            AD_PORT
   PORTC    SCI_PORT
            US_PORT
            PWM_PORT
   T2CON
   CCPR1L
   CCPR2L
   CCP1CON
   PSTR1CON
   PR2
   PR4
   CCPTMRS0
   PIR1,TMR2IF
   PIR3,TMR4IF
   RCSTA
   BAUDCON
   SPBRGH
   SPBRGL
   ADCON0
   ADCON1
   FVRCON
   CALL  Lcd_Init
   CALL  Lcd_Ready
   PRESET VARIABLES
   T6CON
   TMR6
   INTCON  
;----------------------------------------  
SUBROUTINES IN PROJECT    RoboCar2023
   04_DRIVE_Robo2023.INC
      Eval_Cmd             ;Calling up the subprograms for evaluating
                           ; the possible Rx commands
      Cmd_Lights          
         cmd_eval_front    ;frontlights on
         cmd_eval_front0   :frontlights off
         cmd_eval_back
         cmd_eval_back0
         cmd_eval_park
         cmd_eval_park0
         cmd_eval_horn
         cmd_eval_horn0
         cmd_eval_extra
         cmd_eval_extra0
      Cmd_Extra            ;switches headlights and taillights to flashing
         cmd_extra_on
         cmd_extra_high
         cmd_extra_low
      Cmd_Extra_OFF
      Cmd_Drive
         cmd_drive_F....
      Cmd_Speed
         cmd_speed_0...10
;----------------------------------------  
   05_US_Robo2023.INC
      US_Measure        ;US-Burst, TMR1,runtime measurement
      US_Distance       ;convert TMR1 to BCD4:0
      Obstacle_Left     ;Obstacle closer than 15cm on the left?
      Obstacle_Right    ;Obstacle closer than 15cm on the right?
      Bin32_Dez
      ;MULT16x16        ;unused
      ;
   07_LCD_Robo2023.INC
   table_debug          ;eg. dt LINE1+.0,"Rx:. Vdd ..,..V", 80h
   LcdOut_Table         ;Read table, display Mask in LCD
   Out_Menue_Control    ;Output of the parameters in the LCD
         out_vdd
         out_info1_info2
   Out_Vdd_MCU
   Out_Vdd_Drive
   Out_DC1_DC2
   Out_Rx               ;control actual bluetooth command
   Out_US_Distance
   Out_Obstacle_Left    ;Set a flag if there is an obstacle
   Out_Obstacle_Right
   ;
   LeadZero_Lcd         removes leading zeros  004,72 -> 4,72
   BCD_2Bit_Mult10
   Bin16_Dez
   Bin8_Dez_1
   OutBinReg            ;Debugging
   Mult10_8Bit
   ;----------------------------------------


MCU:      PIC1F1936 (28Pin) sollte 16F1936 heißen
liebe Grüße
pic18

Hallo Admin,
war wohl auch ein wenig ungeschickt von mir das so im Codefenster zu verteilen. Hätte ich doch anstatt dessen, alles in einem Rutsch als Textdatei hochladen können  :-[ . Nun ja, man lernt eben nie aus!

DanKe und Grüße 
Ottmar

@pic18 
Danke für die Klarstellung meines Tippfehlers! daumen_hoch

RoboCar Info 06

Hallo,

Hmm.. anscheinend befinde ich mich auf dem besten Weg ein dauerhaftes Selbstgespräch zu führen...

Heute mal etwas zur Belegung der Pins des PIC16F1936 im Programmcode "RoboCar" (siehe angehängte Datei "Pinbelegung" und einige Gedanken zum Empfang des Bluetooth-Kommandos und zur Berechnung des Abstandes zum Hindernis aus der Laufzeitmessung des Ultraschallechos zur Hinderniserkennung.

Mit der Verwendung des PIC16F1936 bekommt man insgesamt 24 Pins,welche mehrfach mit Funktionen belegt sind. Eeinige Funktionen können mittels des Registers "APFCON: ALTERNATE PIN FUNCTION CONTROL" auf einen anderen Pin gelegt werden.

Die Mehrfachbenennung von Ports entspricht der unterschiedichen Verwendung der Portbits. Dies habe ich praktisch empfunden und verbessert m.E. die Lesbarkeit des Codes. Gleiches gilt auch für die Festlegung von Konstanten. Im Code sollten möglichst viele Zahlenwerte durch aussagekräftige Label ersetzt sein. So liest sich zu. "LED_AUS" leichter als dem entsprechend "bcf LED_PORT,RA3"

Auswertung des Bluetooth-Kommandos
----------------------------------
Manchen wir es vielleicht noch interessieren wie die per Bluetooth übermittelten Befehle ausgewertet werden. Dazu muß das Modul EUSART/SCI initiiert sein (vgl. EUSART.TXT).

Anmerkung:
Zahlen S... oder DS beziehen sich auf die Seite im Datenblatt
zum PIC16F1936
;---------------------------------------------------------------------
;--EUSART Asynchronous Mode                                    ;S.291
;---------------------------------------------------------------------
   ;25.1.1.1 Enabling the Transmitter
   ;The EUSART transmitter is enabled for asynchronous operations
   ;by configuring the following three control bits:
   ;• TXEN = 1    • SYNC = 0  • SPEN = 1
   ;All other EUSART control bits are assumed to be in default state.
   ;Setting the TXEN bit of the TXSTA register enables the transmitter
   ;circuitry of the EUSART. Clearing the SYNC bit of the TXSTA register
   ;configures the EUSART for asynchronous operation.   
   ;
;   BANKSEL  TXSTA       ;TRANSMIT STATUS AND CONTROL REGISTER  S.298
;   clrf     TXSTA
;   bsf      TXSTA,TXEN  ;b5 Transmit enabled
;   bcf      TXSTA,SYNC  ;b4 Asynchronous mode
;   bsf      TXSTA,BRGH  ;b2 "                in low speed
   ;
   ;25.1.2.1 Enabling the Receiver                             S.295
   ;The EUSART receiver is enabled for asynchronous operation by
   ;configuring the following three control bits:
   ;• CREN = 1 • SYNC = 0  • SPEN = 1
   ;All other EUSART control bits are assumed to be in default state.
   ;
   BANKSEL  RCSTA       ;RECEIVE STATUS bank3                  S.299
;  b7=1  SPEN  Serial port enabled RX/DT autom set as PORT pins
;  b6=0  RX    Selects 8-bit reception
;  b5=0  SREN  asyncmode don't care  
;  b4=1  CREN  enble async eceiver
;  b3=0  ADDEN don't care in 8bit async mode
;  b2=0  FERR  Flag framing error
;  b1=0  OERR  Flag overrun error
;  b0=0  RX9D don't care in 8 bit mode
   movlw    b'10010000'
   movwf    RCSTA
   ;  
   ;Setting the SPEN bit of the RCSTA register enables the EUSART and
   ;automatically configures the TX/CK I/O pin as an output. If the
   ;TX/CK pin is shared with an analog peripheral, the analog I/O
   ;function must be disabled by clearing the corresponding ANSEL bit.
   ;
   ;25.1.2.8 Asynchronous Reception Set-up:
   ;1.Initialize the SPBRGH, SPBRGL register pair and the BRGH and


Nun genügen die folgenden Zeilen um das Bluetooth-Kommando in die Arbeitsvariable zu kopieren:

btfss    PIR1,RCIF      ;=1? New Bluetooth command received?
GOTO     main_rx_loop   ;no, try it again
;               
BANKSEL  RCREG          ;bank3
movf     RCREG,w        ;copy received command
BANKSEL  0
movwf    tmpRCREG       ;containss now received Ascii code
Die weitere Auswertung gestaltet sich recht einfach durch Aufruf einer entsprechenden Subroutine (vgl. "Evaluate_Command.txt"

Berechnung der Distanz zu einem Hindernis
--------------------------------------------
Zum guten Schluss noch die Überlegungen zum Berechnen der Entferung zwischen US-Modul und Hindernis (Beispiel: gesamter Laufweg des Schalls = 2m).

fosc/4  = 2.000.000Hz, wc (working cycle = fov_schall = 343,29m/s s_schall = 2x1m, Zeitmessung mit 16bittigem TIMER1

t_echo 2m     = 2m/343,29m/s    = 5,8260^(-3)s
TMER1H:L      = 5,8260-3s * 2   = 11652
s_echa/us     = 343,29m/s /10^5 = 3,4329^(-4)m = 0,34329mm
s_echo/wc     = 0,34329mm/2     = 0,17164mm
distance (mm) = TMR1H:L * (0,17164mm/2)
distance (mm) = TMR1H:L * 0,08582

Mit Integer ist es einfacher zu rechnen. Daher wir als Multiplikator kein Bruch sondern die Ganzzahl = 8582 vewendet und im Ergbnis das Komma an die richtige Stelle gesetzt, bzw. die letzten 5 Stellen einfach nicht ausgegeben -> Ergebnis in mm.
        TMR1H:L * 8582 -> 11652 * 8582 = 0099997464
                                        = 0,99997464m
        BCD9:0 0099997464 ->          = 999,97464mmm

Hier noch die Adressen für die entsprechenden Subroutinen zu
16x16Bit-Multiplikation und zur Binär-BCD-Konvertierung:

http://www.piclist.com/techref/microchip/math/mul/index.htm (http://www.piclist.com/techref/microchip/math/mul/index.htm)
http://www.piclist.com/techref/microchip/math/radix/index.htm (http://www.piclist.com/techref/microchip/math/radix/index.htm)

mfG Ottmar

Schönes Projekt.
Nur programmieren nicht mehr so viele in Assembler. Aber das sollte keinem von seinem Hobby 
abhalten. Nur weiter so.
 

Zitat von: Ottmar in 15.08.2023, 20:10:16 CESTRoboCar Info 06
Hmm.. anscheinend befinde ich mich auf dem besten Weg ein dauerhaftes Selbstgespräch zu führen...
mfG Ottmar

Hallo Ottmar! Diese deine Einschätzung geht nicht wirklich fehl! Leider!
Zu meinem "Anteil" daran sei gesagt: Zum einen war ich länger in Urlaub und zum anderen die schlichte Wahrheit: bei vielen (Teil-)Aspekten deiner Arbeiten zu diesem Projekt kann ich nicht mithalten. Es gibt da einfach Techniken, die ich selbst noch nicht oder nur in Ansätzen ausgeführt hatte. Schwitz.... Das bedeutet jedoch nicht, dass ich an deinen Berichten nicht teilhabe, nur eben leider als Beobachter und meist stiller Mitleser.

Mein erster Blick nach dem Urlaub auf die neu eingestellten Fotos erweckte bei mir allerdings Bewunderung. Und auch Freude darüber, dass du mit deinem Projekt so gut voran kommst. Der Robbi sieht inzwischen sehr eindrucksvoll aus. Kompliment für deine geleisteten Arbeiten, also mindestens eines! Würde mich sehr freuen, wenn du deine weiteren Arbeiten hier vorstellst und beschreibst.

An dem oben eingestellten Ausschnitt des Progs hinsichtlich der Mathe-Routinen bin ich sehr interessiert, wenn sie denn tatsächlich in Assembler stattfinden sollten. Wäre das so, könntest du vielleicht just diesen Teil deines Progs, in welchem die obigen Rechenmanöver ausgeführt sind, zur Begutachtung hier einstellen. Da würde ich gerne schauen, wie du die Mathe-Operationen ausgeführt hast.
Grüße, picass

RoboCar Info 07

Hallo picass,
Danke für Deine tröstenden Worte... :-[ :)

Hallo Peter,
Danke für den Google-Tip daumen_hoch

Zitat von picass
...die schlichte Wahrheit: bei vielen (Teil-)Aspekten deiner Arbeiten zu diesem Projekt kann ich nicht mithalten. Es gibt da einfach Techniken, die ich selbst noch nicht oder nur in Ansätzen ausgeführt hatte. Schwitz....
Zitat Ende
(welche Techniken???)

Zu viel der Ehre picass! So ausgefeilt ist der RoboCar-Code bestimmt nicht. Zumindest die Mathe-Routinen habe ich von fremden Seiten abgeschaut (vgl. Hinweis in den entsprechenden Routinen).

Es gibt bestimmt noch elegantere Routinen, heute bin ich wieder auf eine weitere 16Bx16Bit Multiplikation gestossen, die  weniger als die Hälfte Code enthält, als die von mir derzeit benutzte Routine. Zur Zeit mache ich mir Gedanken über einen selbstbalancierenden Robot (mit PIC und Assembler), das wird aber wohl erst nächstes Jahr was werden...

Anbei die von Dir angesprochenen Programmteile, eingepackt in ein ASM-File (Copy- und Paste aus dem Original RoboCar.ASM), war also nicht sonderlich aufwendig dies zusammenzustellen. Das ASM-File ist mit den erforderlichen Einstellungen in der IDE für PIC16F1936 im Codefenster ohne weiteres Zutun lauffähig, in MPLAB 8.92 und wohl auch in MPLAB-X.
Mit dem Watch-Fenster und step by step, kannst Du Dir die Funktion von A-Z zu Gemüte führen (oder wer auch immer sonst noch das tun will).

Viel Spass

mfG Ottmar

P.S. ...ein bisschen mehr traffic könne dieses Forum schon gebrauchen... Diskussionen/Gedankenaustausch zum Programmieren mit PIC's würde mir echt Spass machen...

Hallo Ottmar!
Danke für das Zur-Verfügung-Stellen von Matheroutinen. Hab' sie gerade runter geladen und werde in den nächsten Tagen da rein schauen.
Es gibt Gründe, warum ich Interesse an den von dir verwendeten Routinen habe und das waren eigene Probleme im Umgang mit den Matheroutinen in Assembler, welche ich aus diversen Seiten im Inet eingesammelt hatte. Angefangen hatte mein Sammeln mit dem Blättern in einem Sachbuch aus dem Markt&Technik-Verlag mit dem Titel "Mit dem PIC-Controller erfolgreich arbeiten" von den Autoren Dr.A.König und M.König, erschienen 1996 für satte 90 DM. Nix Euro, DM !

Mithilfe der dort abgedruckten Matheroutinen wollte ich mich in Mathe mit dem PIC einarbeiten. Und brach mir die Finger ab, weil das einfach nicht klappen wollte. Wieder und wieder kontrollierte ich, ob ich beim Abtippen einen Fehler begangen haben könnte. War aber nicht. Nur die Rechenroutinen - "einfache" Subtraktionen - lieferten "unerwartete" Ergebnisse. Is klar, dann andere Routinen aus dem Inet gesucht, z.B. bei Sprut und sonstwo und auch da gab es haufenweise Überraschungen.

Bei den vielen Versuchen wuchs allerdings mein Verständnis für den Progablauf und irgendwann wurde mir klar, dass die tollen Vorlagen echte Rechenfehler produzierten!
Voll der Hammer! Einige Routinen lieferten in 50% aller möglichen Zahleneingaben ein falsches Ergebnis! Das hat mich vom Hocker gehauen, auch die "Doktoren" König hatten da fehlerhafte Programme in ihrem Buch.
Wenn du neugierig geworden sein solltest, dann schau mal in meinen Fred darüber rein:
https://www.pic-microcontroller.de/compiler-software/mplab-x-ide-fehler-bei-subtraktion-falsches-flag-gesetzt/
Diese Angelegenheit dieser fehlerhaften Routinen in Vorlagen ist für mich noch nicht erledigt. Zwar habe ich anschließend Wege gefunden, wie solche Fehler zu vermeiden sind, aber zufrieden bin ich noch nicht. Es ist möglich, dass in dem einen oder anderen vor allem älteren Programm von mir noch solche "Königs"-Fallen existieren. Seitdem bin ich hoch misstrauisch, was Assembler-Rechenroutinen angelangt, in welchen Subtraktion benutzt wird.
Grüße, picass

Hallo picass

Den von Dir angeführten Thread habe ich mal so überlesen Das war ja eine recht ausufernde Diskussion hinsichtlich der Subtraktion  mit negativem Ergebnis.

Mit Mathematik-Routinen habe ich mich bisher nicht tiefgründig beschäftigt.  Insbsonders ist mir das Gebiet vorzeichenbehafteter Integer- oder gar das von Gleitkommezahlen zu fremd, bzw. zu kompliziert.

Bisher habe ich mich damit begnügt den Zahlenbereich, z.B. Multiplikation, Division ganzzahlig zu berechnen. Mußte das Ergebnis dann doch ein Dezimalbruch sein, so habe ich an den Multiplikanten oder den Dividenden die erforderliche Anzahl Nullen angehängt um im Integerbereich zu bleiben. Danach wurden - je nach Erfordernis - dann niederwertige Stellen weggelassen oder  die Kommastellen in der Anzeige, einfach dorthin  "gemogelt", wo dieses bei einem Ergebnis als Fließkommazahl hätte stehen müssen. Ich weiß, das ist nicht sonderlich kreativ.

Zum von Dir geschilderte Problem des Rechenfehlers bei der Subtraktion mit negativer Dfferenz, kann ich nichts sagen. Bei den bisher  notwendigen Subtraktionen, bin ich immer im positiven Bereich geblieben (wirklich negativ wurde es für mich nur wenns ums Geld gin, Schulden und so... :)) ).
Im Codefenster die von mir am häufigsten verwendete Subtraktion16Bit

mfG bis zum nächsten Mal
Ottmar

Sub_16
; Ist STATUS,C nach der Subtraktion=0
; ist das Ergebnis negativ
; Ist das Ergebnis im Low-Byte negativ muss
; das H-Byte um 1 vermindert werden

;Subtrahend enthält nach der Subtraktion die Diffferenz
   movlw    0xFF    ;255      0xFF01 = d'65281'    ACb1:0
   movwf    ACb1        ;      -0xEF96 = d'61334'    BCb1:0
   movlw    0x01    ;  1    -----------------
   movwf    ACb0    ;       0x0F6B =  d'3947     ACb1:0
   ;
;Minuend:  
   movlw    0xEF  ;239
   movwf    BCb1 
   movlw    0x96  ;150
   movwf    BCb0
   ;
;Subtraktion
   bcf      Flags,NEG   ;Negativflag löschen
   movf     BCb0,w      ;ACb0 = ACb0-BCb0
   SUBWF    ACb0, f
   btfsc    STATUS,C
   GOTO     Sub16a
   movlw    0x01        ;BORGEN VON ACb1!!!!!!!
   SUBWF    ACb1,f
   btfss    STATUS,C    ;C=0? Ergebnis negativ?
   bsf      Flags,NEG   ;Ja. Negativflag =1 setzen
Sub16a:
   movf     BCb1,w       ;ACb1:=ACb1-BCb1
   SUBWF    ACb1,f
   btfss    STATUS,C
   bsf      Flags,NEG   ;Flags,7=1 Unterlauf
   bcf      STATUS,C    ;C=0 Ergebnins negativ?
   btfsc    Flags,NEG   ;Ja, Flags,NEG=1? Fehler aufgetreten?
   bsf      STATUS,C    ;JA
   RETURN

Hallo Ottmar!

Danke auch dir für das eingestellte Beispiel einer Subtraktion. Das werde ich mir ausführlich zur Gemüte führen. Allerdings noch nicht jetzt, bin gerade nach dem Urlaub noch mit zu vielen nach zu holenden Angelegenheiten beschäftigt. Aber versprochen, weil mich das wirklich sehr interessiert.

Für mein Langzeitprojekt "Entlüftung eines feuchten Kellers", wo es um das Verarbeiten der Daten von je 2 Temp- und vor allem Hygrometer-Fühlern geht, war ich bislang der Ansicht, dass dies doch nicht mit Assembler zu schaffen ist, sondern ein Ausweichen auf so'n neumodisches Zeug wie einen 32-Bitter unter Basic unausweichlich ist. Dort wäre Rechnen ein Klacks. Mal sehen, was wird, an solchen Rechenübungen habe ich einfach Spass..... es braucht nur Zeit und Ruhe.
Grüße, picass

Hallo picass,

es eilt ja nichts! Ich weiß ja nicht wieviele Sensoren Du für Dein Kellerprojekt verbauen möchtest. Zu 100% bin ich mir sicher, daß diese Aufgabe selbst von einem einfachen Midrange-PIC erledigt werden kann.  Da müssen eben nur die Kommunikationsmöglichkeiten zu den Sensoren/Pheripheriegeräten und damit die erforderliche Pinzahl passen.

Gute Zeit! - Ottmar

Hallo Ottmar !
Es wäre fein, du würdest hier mal wieder rein schauen, denn ich plane gerade den Bau eines Robot-Cars. In dem Fall ein Kettenfahrzeug im Prinzip ähnlich dem eines Panzers, wobei mir aber nur das Chassis, der Antrieb und die Steuerung wichtig sind - auf den kriegerischen Effekt kann ich bestens verzichten. Melde dich mal wieder.
Grüße, picass

Hallo picass,
ich geniesse gerade den Sommer im tiefsten Süden. Wenn Du Fragen hast, helfe ich Dir dennoch gerne weiter.

Grüße Ottmar

Ui..., das ging ja schnell mit einer Antwort. War bis vor einer Woche selbst im Süden, einer von Vielen seit Jahrzehnten geschätzten Insel, deren Namen mit "T" beginnt. Dort im geheizten Pool - 28 Grados und täglich die Beine riskieren beim Kraxeln auf Lavagestein und danach einen Moijito verköstigen....
Zur Arbeit: Habe nach meiner vorigen Nachricht zugeschlagen und ein solches Panzerfahr-Chassis bestellt: https://funduinoshop.com/diy-werkstatt/bausaetze/chassis/stabiles-tank-chassis/kettenfahrzeug-tp101/roboter-kit-mit-12v-motoren-fuer-arduino-geeignet
Dazu noch zwei verschiedene Steuerungen mit L298. Die Funduino-Leute waren irre schnell: eine Stunde nach Bestellung war das Paket fertig gepackt und der DHL gemeldet.

Das wird mein Einstieg in solche Art der Bastelei. Die Verknüpfung der Steuerung mit einem µC steht dabei weit hinten an, ggf. läuft das auch ohne. Was mir vorschwebt ist ein sehr geländegängiges, langsames Fahrzeug. Das soll - Tusch - in dem Dachstuhl eines Schrägdaches rum krabbeln und möglichst Bilder von der Situation in engen Schächten/Schrägen liefern. Es geht quasi nur erst mal um das Ausschnüffeln der Verhältinisse. Dazu wird natürlich auch eine Cam benötigt. Einen Anlauf für das Suchen solchen Equippments ist in einem anderen Fred hier dokumentiert. Die erste Cam, solch übliche, kleine Überwachungs-Cam via Funk ins Netzwerk ist ja schon da, wird aber als Fehlversuch gewertet, weil die nur dann Bilder liefert, wenn eine Verbindung zum Server des chinesischen Herstellers besteht. Der nächste Versuch wird nun eine USB-Cam mit hoffentlich brauchbarer 10-m-USB-Kabel-Verlängerung.
Für direkte Fragen ist es wohl noch zu früh, muss erst mal die Einstiegshürden überwinden. Der nächste interessante Punkt wird die Steuerung des Raupenfahrzeugs mit seinen beiden Motoren.
Grüße, Bernd

Die L298-Module sind ja für die unabhängige Ansteuerung von 2 Antrieben vorgesehen. Zu deren Ansteuerung muss der verwendete Pic wenigstens über 2 PWM-Module verfügen.
Welch Art von Fernsteuerung zum Fahzeug hast Du im Visier?
Na ja, warten wir mal ab wie es konkret werden soll.
P.S. ca. SBR 34°21
Gruß Ottmar

Ottmar, du wirst dich eventuell gewundert haben, warum sich bei meinem Roboterprojekt nichts bewegt. Das liegt daran, dass sich dieser R nicht bewegt. Der Bausatz war als Weihnachtsgeschenk deklariert und entsprechend ausgepackt worden. Alleine..... die Lieferung war unvollständig. In dem Tütchen mit dem Befestigungs-/Montagematerial waren viel zu viele kleine Schräubchen drin, dafür fehlten zwei Hülsen, welche zur Montage der beiden Laufräder (2 Laufräder plus zwei Antriebsräder) nötig waren. Die schlackern nun lose umeinander. Der Mangel ist reklamiert, aber ob und wann sich da was bewegt.....?! Als Nicht-Mechaniker ist mir da auch noch kein rascher Ersatz etwa aus dem Baumarkt eingefallen. Gebraucht würde eine Hülse, die sich mittels Madenschraube in einer Position fixieren lässt. Im zweiten Bild sind rechts oben die Hulsen für die Achse der Antriebsräder zu sehen.
Grüße, picass

Hi picass
Leider fällt mir nur dazu ein:
Wenn die Buchse (Radlager) zu geringen Durchmesser hat, hilft  - in Grenzen! aufdicken mit Alufolie und Epoxy-2Komp.Kleber, bis satte Passung erreicht ist.
Vielleicht hat ein Modellbaugeschäft passende Madenschrauben oder Hülsen. Wird ja auch für RC-Modelle als Ersatz gebraucht.
MfG Ottmar

Habe evtl. eine Übergangslösung: beim Grabbeln in meinen Vorratsregalen fiel mir per Zufall ein kleines Tütchen in die Hände, welche niedliche Stellringe enthielt. Und da dämmerte mir was. Also ab in den Baumarkt und dort gab es solche mit 8mm Durchmesser, welche - bis jetzt - recht gut zu passen scheinen. Die sind schon montiert, im Moment quäle ich mich mit der Einstellung der um einige Glieder verkürzten Ketten ab...., das ist 'ne rechte Fummelei. Du siehst, die Mechanik ist nicht mein Freund, schon gar nicht ein alter. Aber im Laufe des Tages wird es werden....
Eines hatte ich schon rausgefunden: die Motoren-Steuerung wird aufwendig werden. Die beiden Motoren samt montiertem Getriebe sind nominell für 12 Volt angegeben. Freundlicherweise beginnen die aber schon bei gut 2 Volt zu laufen. Aber die üblichen Nutzer solcher Karren haben anscheinend ihren Spass daran, diese mit full speed durch den Garten zu jagen und möglichst Weitsprünge über Rampen auszuführen. Will sagen: das ist alles viel zu schnell für meine geplanten Einsätze, bei denen sich so'n Karren im Schleichmodus wenige Zentimeter vor bewegt und gleich wieder verharrt.
Hoffe, dass ich den LM298 mit Gleichspannungsimpulsen ansteuern kann, um die Geschwindigkeit reduzieren zu können.

Im Moment kämpfe ich aber noch an der Wasserfront - anderer Fred hier - . Das funktioniert zwar schon - der Keller scheint gesichert - , aber es braucht noch einiger Nachkorrekturen.
Grüße, picass

Hi picas
prima wen Du das mechanische Problem lösen konntest!
Die Drehzahl der Motoren wird per Pulsweitenmodulation (PWM) eingestellt. Du kannst da schon an die Nennspannung der Motoren herangehen, musst ja nicht voll durchschalten. Merke: Die Motorinduktivität integriert PWM zu einer niedrigeren Spannung.
Der L298 wird direkt vom PWM-Modul des PIC angesteuert. Dazu kommt noch die Umpolung des Motors an den entsprechenden L298-Eingängen.

Du wirst Dich von Deinem bevorzugten 31kHz  Arbeitstakt trennen und sehr viel höher gehen müssen.
Dazu gibt es die Erläuterungen im Datenblatt (DS) Deines PIC
mfG Ottmar

Der Kampf an der Wasserfront lässt mir weder Zeit noch Ruhe, aber einen kleinen Schritt hatte ich in Sachen Robotcar doch unternommen. Einer der beiden Motoren ist via L298 unter Strom gesetzt. Dafür hatte ich einen Fertigbaustein benutzt, den man gegen wenig Geld im Inet kaufen kann. Es gelang auch bereits, den Motor mittels PWM zur nur hälftigen Geschwindig-keit zu überreden. Da wurde einfach ein Funktionsgenerator an einen der beiden Eingänge geschaltet. Die Frequenz des FG scheint fast egal zu sein, nur unterhalb 30 Hz gibts Ungutes. Der FG erzeugt aber einen perfekten 1:1-Rechteckmodus, Verschiebungen sind da nicht vorgesehen.

Das wäre nun das Nächste auf der Liste. Einen Anlauf dafür gab es auch, aber der gelang zu kurz. Schlicht gedacht: bevor ich tagelang mich auf neue Programmiertechniken beim PIC einlasse, wird mal kurz ein LM556 genommen. Der erste 555-er läuft als astabiler MV, triggert den Zweiten, der als monostabiler MV läuft, und dessen An-u.Aus-Zeit  wird über ein schlichtes Poti (Trimmer) verschoben. Ach......, grau ist die Theorie. Was ich da als Poti oder auch zeitbestimmenden C einsetze, der Zweite macht am Ausgang das Gegenteil des Ersten, ist also total synchronisiert. Da glaubt man, solche  alte Elektronik wäre was Einfaches und schon hat man das Problem der Realität eines Glaubens. >:(

Also erst mal nix mit variabler PWM. Mist flixter, dann muss ich mich wohl wieder der Wasserfront zuwenden, da klappts wenigstens.
Bei die Gelegenheit: muss man eigentlich dieses Rad der Motorensteuerung von Robot-Cars unbedingt immer wieder komplett von vorne erfinden oder gibts da bekannte Muster oder Vorlagen?
Grüße, picass

Hallo Picass,

also die Loesung mit 2x NE555 ist wohl nicht das Gelbe vom Ei, wenn man die Wahl fuer einen entsprechenden PIC hat, in welchem bereits die beiden erforderlichen PWM-Module zur direkten Ansteuerung eines 2xL298-Modules eingebaut sind. Dazu noch mit max.10bit-Aufloesung. Dies erfordert nur wenige Programmzeilen! Also spare Dir die Loeterei mit NE556 o.ae.

Es genuegen 2 separate PWM-Module (CCPx). Voll- und Halbbruecke (ECCPx) wird nicht gebraucht, da dies vom L298 uebernommen wird. Genuegend Pins (28) waeren dazu auch nicht schlecht.

Im beiligenden ZIP-File habe ich mal die grundlegenden Einstellungen dargestellt, welche Du leicht auf Deinen gewaehlten PIC-Typ uebertragen kannst.

----------------

Ich habe mir mal das Datenblatt des PIC18F14K22 (Dein bevorzugter Typ) angeschaut. Hat leider nur 1 PWM-Modul (CCP1). Du solltest aber wenn das RoboCar genuegend wendig sein soll, beide Motoren getrennt ansteuern koennen. Wenn Du bei 18F.. bleiben willst, waere der 28pinner PIC18(L)F2X/4XK22 eine Moeglichkeit. Wenn Du einen PIC16F1936 verwendest, kann ich Dir direkt mit Programmabschnitten helfen.

Bist Du inzwischen schluessig, welche Art von Fernsteuerung Du verwenden willst? Ich wuerde mir evtl. fuer Deinen Zweck ein preiswerte gebrauchte RC-Fernsteuerung, inclusive Empfaenger besorgen. Alle erforderlichen Signale fuer den PIC kannst Du dann am Empfaenger abzapfen.
Kanal 1) Geschwindigkeit Vor - Stop -Rueck
      2) Richtung Links - Neutral - Rechts
      3+x Funktionskanaele
Die nicht mehr gebraeuchlichen 36MHz-Anlagen für Flugmodelle (ebay) haben 2 Steuerknueppel, dazu oft noch einen Proportionalkanal und mehrere Schaltkanaele. Zur Abfrage brauchst Du natuerlich entsprechende Eingangspins oder Du fraegst die Kanaele ueber ein entsprechendes IC, per Mulitplexing mit einem einzelnen Pin am PIC ab. Abfragezeit 2ms/Kanal (Zeitbedarf/Programmieraufwand!).

mfG Ottmar

Zitat von: Ottmar in 10.01.2024, 18:18:54 CETRC-Fernsteuerung, inclusive Empfaenger

wäre zu überlegen, ob man dies mit einem ESP32 realisiert, entweder über Bluetooth oder Wlan.

..meinte Picass will mit dem car auf dem Dach Erkundungen durchführen - Reichweite?
ESP32 ist für mich Neuland.

Zitat von: Ottmar in 10.01.2024, 18:18:54 CET......also die Loesung mit 2x NE555 ist wohl nicht das Gelbe vom Ei, wenn man die Wahl fuer einen entsprechenden PIC hat, in welchem bereits die beiden erforderlichen PWM-Module zur direkten Ansteuerung eines 2xL298-Modules eingebaut sind.

Der Kampf gegen den vermeintlich so bekannten LM555 ging auch weiter.
Nein, nach einem Blick in das Datenblatt des PIC18F14K22 und dort in die Abteilung ,,MMV" motivierte mich nicht, die Arbeit der Motorenansteuerung über den PIC zu versuchen. In Basic wird das gänzlich anders sein, aber in Assembler...., dazu fehlt mir im Moment der Ehrgeiz, der Antrieb und irgendwie auch die Zeit.
Also wieder den besagten ,,guten, alten Bekannten" aus den hinteren Ecken der Vorratskisten raus gekramt. Und dann kam es wider Erwarten dicke. Erst schaffte ich wohl gleich zwei Cmos-Versionen des 556-er, warum auch immer. Dann noch 'ne Stufe zurück auf die schlichten TTLs. Dann der Kampf mit der Erlangung passender Frequenzen, dann wollte der Zweite sich nur in strengster Parallelität mit dem Ersten zur Arbeit überreden lassen.
Der Erste ist ein astabiler Multivibrator, der sollte die Frequenz vorgeben, angepeilt war irgendwas zwischen 100 und 500 Herz. Dieser aMV sollte den Zweiten triggern, der als monostabiler MV lief. Das klappte leider zu gut, egal, welchen Kondensator ich als zeitbestimmenden für den mMV einsetzte, er hatte das gleiche Ausgangssignal wie der Erste. Für zusätzliche Verwirrung sorgte noch die Erkenntnis, dass bei gleichen Bauteilen für die Zeit-Achse ein aMV extrem andere Frequenzen einnimmt als ein mMV.

Glaubt man nicht, wenn man die als äußerst sparsam anzusehende Bestückung der beiden 555-er anschaut, aber das war ein rechter Kampf, bis es endlich passte. Aber nu' passt es und die Kopplung mit dem LM298 brachte dann den gewünschten Erfolg: der Motor lässt sich quasi vom Stillstand kontinuierlich bis ca. 75 Prozent der Volllast durch regeln. Auf dem Bild sieht man das vordere Kettenglied mit Bewegungs-Unschärfe, das löppt also nun.
Demnächst gehts weiter, aber nun ist wieder erst die Wasserfront dran.
Grüße, picass
MMV 1.jpgMMV 2.jpgMMV 3.jpgMMV 4.jpg

Hi picass,

Deine Freiheit die Antriebssteuerung mit 2xNE555 durchzufuehren, sei Dir unbenommen. Nur befreit Dich die Software eines PIC von zusaetzlichen Bauteilen, Verbindunngen und Komplikationen. Einstellungen lassen sich unkombliziert vornehmen.
Info: Ich bin nahe der 80 und habe das auch hinbekommen!

Beiliegend eine Uebersicht, wie einfach sich das Alles per Software locker erledigen laesst. Ich habe das mal so zusammengestellt und hoffe nichts Wesentliches dabei uebersehen zu haben.

Ja, zugegeben ich musste mich auch kraeftig durchbeissen, bis ich es geschluckt habe! Man kann ja probieren, studieren und macht dabei (hoffentlich) kaum was kaputt, ausser der aufgewendeten Zeit.

Wichtig ist nur, dass Du die Initialisierung hinbekommst. Mit einem Oszi ist es dann leicht die Auswirkungen bei Aenderung der PWM-bestimmenden Parameter zu verfolgen.

Ansonsten: Viel Erfolg bei der Vollendung Deines Hochwasser-Problems im Keller!

mfG Ottmar

gute Arbeit, welche Bluethooth APP benutzt Du?

Hi pic18,
Hatte ich in google Play fuer Android unter "Bluetooth RC Controller" (Andi) runtergeladen, kann diese dort aktuell aber nicht finden. Aber dies ist die Homepage.
APK free download (https://bluetooth-rc-car.en.softonic.com/android)
mfG Ottmar

danke, wenn die Reichweite reicht, dann hätte man hier eine schöne Fernbedienung. Man kann das ganze mit dem ESP32 aufbauen.

Ich denke bluetooth reicht so um 6-8 Meter weit.

Es RAUPT !

Also das Raupenfahrzeug!
Nach der Erstellung eines zweiten Motor-Steuer-Zweiges, ebenfalls aus je einem astab. und monostb. Multivibrator – wieder mit zwei 555-zigern – können nun beide Motoren in Betrieb genommen und unabhängig voneinander geregelt werden.

Ja, nein – is klar: noch ist die Kiste aufgebockt auf zwei Rollen Lötzinn, aber lass' ma, die Freude über diesen ,,ersten, eigenen Lauf-Schritt" ist dennoch vorhanden. O:-)

Nun gibts erst wieder 'ne Pause zwecks Anstehens eines Kurzurlaubs tieeeeef im Norden, im Westen von Ostfriesland zum Zwecke des Durch-Kühlens. Wenn ich zurück und wieder aufgetaut bin, geht es in kleinen Schritten weiter: für die Steuerung werden zwei Schieberegler angeschafft, die nebeneinander montiert werden und dann folgen die ersten Fahrversuche, noch an einem langen Steuerkabel. Danach dann mit Gemach ein Akkupack und zwischendurch mache ich mir Gedanken über eine eventuelle Fernsteuerung.

A pro po, da frage ich mich doch dieses:
Habe drei Drohnen. Die sind alle drei nicht wirklich mehr in Betrieb, eine ist mehr was für innen, eine bekommt kein GPS-Signal mehr und ist daher schwer auf der Stelle zu halten. Da könnte man doch..... eventuell eine solche Fernsteuerung zweckentfremden. Das ist aber noch weitestgehend ein Buch mit drei Siegeln. Aber vielleicht geht da was.....? !
Grüße, picass
Raupen.jpg

Heute hat er seinen ersten Ausflug unternommen und das auf seinen eigenen zwei Beinen! :)
Das löppt weit besser als erwartet. Selbst mit diesem rudimentären Provisorium von "Steuerpult" - siehe Bild im Beitrag oben drüber - ist das Raupenfahrzeug gut zu steuern: sauber geradeaus, links-rechts, Drehung auf der Stelle. Rückwärts kann er noch nicht, da warte ich noch die Ankunft der bestellten Schiebepotis ab. Nach dem Kurzurlaub....und nur dann, wenn das Auftauen nach der Kälteorgie draußen gelungen sein sollte.
Grüße, picass
Raupen2.jpgRaupen3.jpg

Sieht gut aus

Nicht schlecht! Da sieht man was mit minimalistischer Elektronik machbar ist  daumen_hoch daumen_hoch !
100 Punkte für Dich!

Danke für die Blümchen! Es ist ja nur - und da ist eine Verdopplung angebracht - ein erster Anfang. Inzwischen denke ich an Anderes. Dieses Raupenfahrzeug soll quasi als Spähfahrzeug in unwegsame bis nicht zugängliche Bereiche des Dachbodens gefahren werden. Grund: Hornissen !
Die waren vor zwei Jahren zahlreich dort vertreten und hatten hübsche Nester gebaut. Hauptgrund ist mein Bemühen, einen Teil des Daches von innen nachträglich irgendwie zu dämmen. Lange hatte ich mich überhaupt nicht in diese engen Bereiche rein getraut, diese Biester sind mir nicht geheuer und dicht an ein "belebtes" Nest möchte ich nicht ran kommen. Deswegen das Spähfahrzeug.

Nach dem Spähen kommen die Überlegungen, wie man in enge Spalte Isoliermaterial rein schieben oder transportieren könnte. Wahrscheinlich habe ich da rosige Vorstellungen, die genau genommen nur Hoffnungen darstellen. Aber zumindest versuchen möchte ich es. Nun gälte es, sich in die Bereiche der Mechanik einzuarbeiten, in denen Motoren gesteuert werden - evtl. Steppermotoren - , die aber dennoch bemerkenswerte Power haben sollten, immer nur langsame bis sehr langsame Bewegungen. Am Wichtigsten: ich brauche Mechaniken, welche drehen und schieben können.

Gerade, wenn es um Drehen und Schieben geht, wo bitte könnte ich für Anregungen oder konkrete Materialen schauen? Ein erster rascher Blick im Inet mit dem Stichwort "Modellbau" führte in der Regel nur zu Automodellen für mehrere Hundert Euro. Ein geeigneter Shop für Modellbau-Teile wäre ein Anfang.
Grüße, picass

Nachtrag, @Ottmar : ich habe hier in deinen Fred rein geschrieben. Es ist aber beileibe nicht meine Absicht, deinen Fred umzufunktionieren. Bitte sage, wenn dich das stören sollte, schließlich wäre ein neuer Fred ja nun wirklich kein Prob.

Also ich würde mir die Teile drucken :D

also im Ernst wenn es spizeller wird weil baubedningt nicht anders geht wird es wohl ein Eigenbau. In der heutigen Zeit oder der 3d Druck durch aus tauglich und mit teuren material auch beachtlich stabil.
Kann dir gerne auch was konstruieren wenn du mir eine Skizze machst und es mal ausdrucken. Allerdings mache ich nur pla und petg derzeit. Kommt halt drauf an welche Form usw.
Habe mir vor kurzen paar Zahnräder gedruckt und diese zu ein getriebe zusammen gesetzt. War echt erstaunt wie viel die schon aushalten.
Klar 24/7 356 werden die nicht halten aber für selbst gemacht... Anderes Beispiel: ein gedruckert nylon Zahnrad war bis zum Schluss (meine Dame hat es entsorgt) in ein Brot Schneider verbaut...
Ansonsten auch wenn es vielleicht doof klingen mag: pappmaschee
Damit kann man recht stabile aber leichte Gerüste aufbauen.

Hallo picass,

Zahnräder, Normteile u.a. findest Du z.B. hier:
https://ghw-modellbau.de/

und Lager gibt's hier:
https://www.kugellager-express.de/

Habe bei beiden schon bestellt und war zufrieden.

Nachtrag: Bei https://www.maedler.de kann man zu den Zahnrädern (Polyacetal, POM, Ms, St) die zulässigen Drehmomente nachschauen.
(Kaufen kann man da auch, aber unterhalb 50EUR Mindestbestellwert gibt es einen Bearbeitungszuschlag.)

danke für den Tipp PICkel. Wenn ich mal wieder was brauche werde ich sie auf jedenfall mal ausprobieren.

Zitat von: picass in 17.01.2024, 17:13:57 CET@Ottmar : ich habe hier in deinen Fred rein geschrieben. Es ist aber beileibe nicht meine Absicht, deinen Fred umzufunktionieren. Bitte sage, wenn dich das stören sollte.

Stört mich nicht passt ja doch ins Thema. Zudem dauert meine Sendepause hinsichtlich meines RoboCar noch bis Mai.

@Ottmar
Bin beim Stöbern im Inet auf die fernöstliche "AliExpress"-Seite gestossen und habe dort von manchen Anbietern fast gleiche Raupenfahrzeuge entdeckt wie das von mir Verwendete. Zumindest das Chassis mit Motor, Rädern, Kette ist exakt gleich. Beim hiesigen Lieferanten "Funduino" ist der Typ mittlerweise ausverkauft, deshalb hatte ich mich gefreut, dort Ähnliches zu entdecken. Habe mir auch gleich Reserveketten bestellt für evtl. Vergrößerung des Chassis, jetzt fehlen noch weitere Räder.

Entdeckt hatte ich auch einen Bausatz für einen solchen Karren, der zudem einen bedienbaren Greifer, US-Abstandswarner, LEDs für das Nachsteuern auf solche bekannten Linien auf dem Boden und sogar eine Kamera enthält. Dazu gibts die komplette benötigte Software in Phyton. Alles zusammen soll 50 € kosten.
An das Phyton traue ich mich nicht ran, aber die haben in ihrem angebotenen Softwaredownload u.a. eine Bedienungsanleitung für die Inbetriebnahme des Kits und der Software mitgeliefert. Die ist - finde ich - durchaus lesenswert, deshalb habe ich das PDF-File mal unten angehängt. Vielleicht schaust du mal rein.
Grüße, picass

Nachtrag 1: Mist, das PDF-File ist viel zu gross, selbst nach dem Pack-Versuch. Hm....

Zweiter Nachtrag: auf der Homepage des Anbieters gibt es diesen Link, durch den man die komplette Software mit Anleitung etc. laden kann:
http://freenove.com/fnk0077
Diesen Link hatte ich selbst benutzt und der scheint auch virenfrei zu sein. ;) 
Der Link auf die Seite mit dem gesamten Angebot und den Bildern und Beschreibungen ist mehrere Zeilen lang. Weiß nicht, ob ich den so einstellen sollte.

Hi picass,
alle Achtung vor dem was Du Dir vorgenommen, bzw an Möglichkeiten geschaffen hast! Wenn man bedenkt, welche Vielfalt an zusätzlichen Funktionen Deine "Raupe" haben kann, wird Dir das auch eine Menge neuer Kenntnisse vermitteln.

Den Inhalt des Links (PDF) habe ich mal überflogen. Die zusätzliche Mechanik Greifer) anzusteuern erscheint mir als interessant. Falls Du aber bei der Steuerung aller Funktionen weiter ein Kabel verwenden möchtest, wird dieses einige Adern haben müssen und der zugehötige Kontrollpult ist eine Aufgabe für sich (ich werde dabei den Gedanken an eine RC-Fernsteurung nicht los).

Auch erscheint es mir aus dieser Sicht als sinnvoll "einfache" Abläufe einer MCU zu überlassen.

Bei der Funktionsviefalt verstehe ich, dass in dem PDF mit Raspberry (Kamera) gearbeitet wird. Hinsichtlich einer evtl. Kamera kann ich aber nichts sagen, dazu weiss ich hierüber zu wenig. Vmtl. würde ich da eine Komplettlösung Kamera - WiFi - Monitor anstreben.

Vermutlich war dies alles wenig hilfreich für Dich. Auf jeden Fall drücke ich Dir die Daumen, dass alles, so wie Du es Dir vorstellst, auch gelingen möge!
MfG Ottmar

Zitat von: Ottmar in 27.01.2024, 08:57:59 CET..... was Du Dir vorgenommen, bzw an Möglichkeiten geschaffen hast!

Ähm....räusper......, der Schuster picass bleibt nicht nur erst mal bei seinen Leisten - sprich: bei dem jetzt vorhandenen einfachen Raupen-Chassis gänzlich ohne Funktionsanbauten - , sondern versucht sich weiter in Basic's, zu deutsch: den Niederungen der Grundlagen.

Der Blick auf dieses Fernost-Modell mit Greifer, der rote Bälle aus seiner Bahn weg befördern kann, ist selbstredend verlockend. Das vor allem deswegen, weil in der Bewerbung des Artikels gesagt wird, das Modell würde mit kompletter, fertiger Software für die Steuerung geliefert. Und die über 100 Seiten lange Anleitung verstehe ich so, dass man sowohl für Smartphone oder alternativ PC (Windows/Apfel) Steuerungssoftware mit geliefert bekommt, um darüber das Modell in Betrieb nehmen zu können.
Drastisch runter gebrochen: wenn es gelingen sollte, all die notwendigen einzelnen Software-Teile down zu laden, zu installieren und in Betrieb zu nehmen wie in der Anleitung beschrieben, muss man nicht selbst irgendwas programmieren: Software-Teile in Betrieb nehmen und schon geht die Nutzung des Modells los.

Da stellen sich zwei Frage: sollte man das wirklich so einfach erreichen können, was genau hätte man dann davon? Sich als glohrreichen Programmierer feiern lassen....., eher nicht.
Frage 2: will man auch nur eine kleine Änderung im Prog für die Steuerung ausführen, muss Phyton ran. Ein Einstieg auf diesem Wege...?
Vorerst bleibe ich bei meinen Leisten und mühe mich in winzigen Schritten vorwärts. Wobei auch das nicht stimmt, denn genau genommen steht heute die Übung an: rückwärts fahren.
>:D
Grüße, picass

Auf'm Gymmi in der Obersekunda – wer noch weiß, was das war – hatten wir einen Klassenkameraden, welcher für Robustheit, Beliebtheit und das Raushauen trockener Sprüche stand – wenn er auch nicht mehr lange stand, nach diesem Schuljahr musste er ab. :'(  Einer seiner Sprüche ging so, zunächst die Präliminarien: es sollte um eine Situation deutscher Soldaten nach einiger Zeit in Stalingrad gehen. Also der Spruch:" Vorwärts Kameraden, wir müssen zurück!" Zitatende

Zurück steht ja auf meinem Pflichtenheft, was das Raupenfahrzeug (RF) anbelangt. Da bislang alles ohne PIC lief, dann also auch dieses Umswitschen von vorwärts auf rückwärts ohne komfortable Software-Unterstützung, sondern Abtauchen in die ganz niedrigen Tiefen der analogen Elektronik und hin zu Drahtverhauen auf Brettboard und mit so was Modernem wie Kleinsignaltransistoren (KSTr).

Sowohl dunnemals als auch jetzt für mich konterkariert/e der o.g. Spruch die raue Realität. Für ,,Vorwärts" gibt es bislang eine 3-Draht-Leitung vom ,,Steuerpult" zum RF. Auf dem sitzt ja ein LM298, der für die beiden Motoren sich als zuständig erklärt hat. Für ,,Rückwärts" will er aber jeden einzelnen der 4 zuständigen Anschlüsse auf seiner Platine gänzlich anders angesteuert haben. Wo vorher Takt war, muss nun ein Low-Signal hin. Und umgekehrt. Und das an allen 4 Anschlüssen. Fein wäre da ein 4-fach-Umschalter, aber so'n Relais ist wieder riesig, frisst Strom, etc.. Eine Handklaviatur aus Dip-Schaltern auf der Steuerplatine ginge auch, ist aber fehlerhaft und umständlich bedienbar, eine Ansammlung von Riesen-Knüppeln will man da auch nicht haben und zudem müsste dann ein dickeres 5-pol-Kabel zum RF gezogen werden.

Also knobeln und mit KSTr's – jeder Zweite negiert das, was sein Nachbar tut – den Draht verhauen. Bis zu zwei von den vier Kanälen habe ich mich vor gemüht. Mein Ehrgeiz, das Alles möglichst klein zu halten, hat zu einer Anzahl von Unübersicht-lichkeiten geführt und mit dem Sehen habe ich im Moment eh' ein Problem, ein Auge will nicht so recht und der teilweise Verlust räumlichen Sehens beim Löten und Draht-Verhauen ist auch nicht so der Bringer.

Das Ziel wird schon noch erreicht werden und es kann so auch bei der bisherigen 3-Draht-Verbindung bleiben, aber: schwitz...., die Rückkehr wird zum Horror.
Grüße, picass
rückwärts.jpg

Zitat:
Das Ziel wird schon noch erreicht werden und es kann so auch bei der bisherigen 3-Draht-Verbindung bleiben, aber: schwitz...., die Rückkehr wird zum Horror.
---------
Hallo picass,  
was hältst Du davon die Ansteuerung Deiner Raupe Schritt für Schritt auf Microcontroller umzurüsten? 
Das hat den Vorteil daß 
a) der "Drahtverhau" deutlich kleiner wird  
b) Änderungen per Software, ohne Löten erfolgen können 
c) Du Deine Programmierkünste erweiterst,  
d) und die in PICs vorhandenen Module kennenlernst.  

Nimm nur mal Fahrgeschwindigkeit  / Kurve/Vor/Zurück: dann reichen 4 direkte Verbindungen (Drähte) zum L298. Befehl hierzu geht Kabellos per Bluetooth (z.B.HC-05)/FM-HF, raus an Deine MCU.  

Du kannst das doch!  

Die Schaltung von "Robocar" habe ich damals vollständig auf einem Steckbrett aufgebaut. Habe erstmal ein altes Handy und einen HC-05+ PIC mit 40 Pins verwendet, bis ich einen Überblick zu den erforderlichen Pins hatte (war ja auch Neuland für mich) und dann auf den 16F1936 mit 28 Pins reduziert.  

Spätestens dann, wenn Du irgendwelche Sensoren verwenden möchtest, wird der Aufwand mit dem bisherigen diskreten Lösungsweg sehr erheblich werden.  

mfG Ottmar

Endlich..... :-[  ist es so weit: das Tank-Chassis fährt auch rückwärts und bei der Gelegenheit wurden auch die beiden Schieberegler (SR) anstelle von Potis in Betrieb genommen. Gerade die SRs gestalten die Geschwindigkeits- und vor allem Kurvensteuerung recht komfortabel. Die endlose Frickelei beim Erstellen der Schaltung auf dem Lochrasterboard hat irre viel Zeit und Nerven gekostet und bei der Inbetriebnahme für Entsetzen gesorgt: nur eine Kette wollte raupen. Freundlicherweise war nur ein dünnes Käbelchen abgerissen.

Insgesamt lässt sich das Raupenfahrzeug nun erbaulich steuern. Die "Steuerplatine" ist in diesem Zustand natürlich auch nur eine Übergangslösung, ein Einstieg halt. Aber lass' ma, ab nun darf man auch ein klein wenig Spass am Fahrbetrieb haben, was der vorher hoch-gefährdeten Motivation wieder in den Sattel helfen sollte.
Inzwischen habe ich einen der Fernost-Anbieter angefragt, ob er die Räder und Ketten auch einzeln verkaufen kann und will. Falls da was möglich sein sollte, könnte das Fahrzeug auch vergrößert werden, etwa, um mehr ,,Aufbauten" aufnehmen zu können.

@Ottmar :
Von solcher Umrüstung auf die Steuerung mit einem PIC träume ich natürlich. Werde gleich mal beginnen, mir über eine Umsetzung erste Gedanke zu machen. Hilfreich könnten da fertige Vorlagen sein, auch wenn sie nicht "genau" passen sollten. Allerdings gehe ich davon aus, dass diese Vorlagen so ziemlich alle in "C", Basic oder Phyton ausgeführt sein werden, sodass dann weniger die Robotertechnik als vielmehr eine neue Programmiersprache zu lernen anstünde. Mhm....., die Meinungsbildung ist noch in Arbeit.... >:D
Grüße, picass
Raupen4.jpg

Die Steuerplatine sieht wirklich gut aus, wohl noch ein wenig unhandlich :), aber wohl durchaus zweckdienlich und weiter ausbaufähig daumen_hoch
Ich bin mir sicher, dass Du keine neue Sprache lernen musst, um die Steuerung zu programmieren. Mit Assembler kannst Du das locker hinbekommen. Nur Mut!

Zitat von: Ottmar in 31.01.2024, 19:00:53 CETDie Steuerplatine sieht wirklich gut aus......

Gut so! Hau den Spott nur raus.....!
Aber danke für dein Mut-Machen, bin selbst gespannt, ob und wie es weitergeht.
Heute morgen gabs 'ne Überraschung per Mail. Die gestern Abend angeschriebene Firma in Fernost, welche diesen oben genannten Roboter-Bausatz - der mit Greifer, Fernsteruerung, etc. - mit gleichem Raupen-Fahrgestell anbietet, hat auf meine Anfrage nach Ersatzteilen wie die 4 Räder und 2 Ketten über Nacht geantwortet und gleich eine Rechnung für eine mögliche Bestellung mitgesandt - die Rechnung wie üblich via Paypal. Bin das Wagnis mal eingegangen und nun gespannt, was denn dann tatsächlich wann kommen wird. Aber fix waren die schon. Diese Firma hat sich übrigens auf solche Lehrbausätze konzentriert, da gibts Einiges zu entdecken.
Grüße, picass

Sorry picass, 
das war keine Ironie, kein Spott!
Wenn Du das so machst, warum nicht?
Also: weiterhin viel Spaß am Hobby!
LTspice: Nur Schaltungssimulation möglich, kein Erstellen von Layouts.
Grüße Ottmar

Eine Portion gesunden Spottes - insbesondere, wenn er angebracht ist - darf durchaus sein. Macht dann ja beiden Seiten Spass. >:D
Das Prog LTspice kenne ich und habe es auch auf einer HD "montiert", bin nur über ersten Versuch nicht raus gekommen. Für Layouts kommt eh' nur Eagle für mich auf den Tisch und das ist einer nicht-neuen Version, irgendwas um die 6.2 rum. Man ist Gewohnheitsmensch, mit allen Vor-u. Nachteilen. :-[
Grüße, picass

Habe ich grade in den Tiefen einer Kiste gefunden:

ein ca 17 Jahre alter Test Aufbau bestehend aus einem Schrittmotor, einen Modellbau Servo, ein PIC628A (fehlt) war mal drin und
4 Transistoren mit Kühlkörper (2 Fehlen) als Treiber Stufe für den Schrittmotor (unipolarer). Ein Reifen Fehlt auch, weiß nicht wo das abgeblieben ist :D
Man konnte mit den "Pfeil" Tasten dann Kabel gebunden Vorwärs,Rückwärts Links und Rechts (+-90°, Zwischenstellenungen gabs nicht).
Wo ich das aufgebaut und Programmiert (Assembler) habe war ich ca 15 Jahre alt... (was man nicht alles aufhebt...) War Stolz wie Wolle wo das Teil in mein Zimmer rum fuhr.
Ich erinnere mich das ich zuerst kleine Transotoren ohne Kühlkörper hatte die dann weg brannten... Daraufhin hatte ich das größte genommen was ich zu der Zeit rumliegen hatte...

Kuck an...., der Cobra ist "circa 32 Jahre" alt. Na dann.... ;D
Aber die im Jugenalter gebastelte Karre finde ich klasse: Antrieb über Schrittschaltmotor, Lenken per Servo und dann noch PIC-Assembler...! Kompliment im späten Nachhinein. Den Status habe ich ja heute noch nicht und begnüge mich mit analogem Motor und altbewährten ICs, also ohne PIC. Wenn du das alte Programm auch noch auftreibst, und das entsprechende 17 Jahre alte Medium noch in Betrieb zu nehmen ist, dann mache es mal rüber. Also das Prog! >:D
Grüße, picass

Kann ich gerne mal nach schauen. 
Wird aber im einfachen Editor geschrieben worden sein und somit null bis garnicht in mplab funktionieren. 

Und ja bin 32  :)) und vermutlich einer der jüngsten hier 😂

Da ich selbst nun neugierung wurde habe ich bei mir mal rum geschnüffelt.
Leider gab es kein Ordner oder Datei die "Auto" o.ö. hieß.
Habe nur die gefunden.Schrittmotor_Servo.txt

Ob dies aber die richtige ist und auch mal lauffähig war kann ich leider nicht mehr beurteilen.

Immer wieder interessant so alten kram sich an zu schauen.

Das scheint das Richtige zu sein. Im Prog werden sowohl ein Servo zum Lenken als auch ein Schrittmotor betrieben. Werde das in den nächsten Tagen mal versuchen, in meine MPLAB-Version rein zu schieben. Klar kann man das Textfile gebrauchen, die von MPLAB erzeugten Programmdateien enden zwar auf ".asm", aber das sind auch nur Textdateien. Was der Debugger dazu sagt, sehen wird dann.
Danke für deine Bemühung des Nachbuddelns. Das Prog kann ich nicht direkt benutzen, weil auf meinem Raupenfahrzeug zwei analoge Motoren sitzen...., aber Schrittmotoren habe ich auch in einer Kiste liegen. Mal sehen, ob die sich zum Bewegen bewegen lassen.
Für dein jugendliches Alter dunnemals warst du so assembler-mäßig echt gut drauf! :) Da wollen wir mal hoffen, dass du mittlerweile was dazu gelernt hast! >:(
 ;)   
Grüße, picass

Ich fürchte das es ehr umgekehrt ist. Da ich inzwischen seit Jahren sps programmiere beruflich und somit eine andere Sprache bzw. Dialekt gewohnt bin ist es alles sehr umständlich für mich. 
Z. B. Die sps verwaltet alles in ob, FC, fb, DB und da bin ich eine gewisse Struktur gewohnt. Nun habe ich versucht dieses nach zu empfinden. Aber komme immer wieder an Stellen wo es nicht ganz passt.
Gestern habe ich mein Programm getestet wo ich 10 servos ansteuern wollte. Leider funktioniert es nicht und finde derzeit auch die ursache nicht. Das Signal ist ca faktor 10 zu langsam. Aber da werde ich eventuell noch ein thread aufmachen 

Mache! Es ist heute foren-prominente Unterstützung eingetroffen.  8)
Womit ich nicht mich meine! >:D
Grüße, picass

@Ottmar
Was macht eigentlich dein Roboter?
Grüße, picass

Hi picass,
Das Video vom 7.7.2023 zeigt den momentanen Endstand, voll betriebsbereit und steuerbar mit Handy-App.
In Arbeit: Hinderniserkennung und selbstständiges Entscheiden/Ausweichen vor Hindernissen.
Bin aber noch bis Apr. 2024 im meinem Sommerdomizil (32°C) fern meiner Bastellkammer.
Danach geht's ran an einen 2räderigen selbst balancierenden robby.
MfG Ottmar

Das hört sich mal interessant an! Bin schon gespannt.