Menü
Aktuelles
Von:
Filter

Alfred firmware - OpenOCP funktioniert nicht

KadaverJoe

KadaverJoe

Member
Hallo liebe community,
Ich versuche nun seit ein paar Tagen Sunray auf einem Raspberry Pi 4 mit Debian OS Lite 64 bit zum Laufen zu bekommen. Leider funktioniert es nicht so, wie auf github geschrieben. Ich habe nun die SD-Karte nochmal komplett neu gemacht und stoße wieder auf den gleichen Fehler:
Ich installiere über den Raspberry Pi imager das Raspberry Pi OS Lite 64 bit und installiere dann anschließend OpenOCD und alle zugehörigen libraries, wie auf github beschrieben. Danach habe ich den Sunray code für Alfred heruntergeladen und kompiliert.
Außerdem habe ich mir den "sunray_install" Ordner von meinem Banana Pi kopiert und ins home Verzeichnis des Pi kopiert. Wenn ich nun versuche, die firmware mit dem Befehl sudo ./flash.sh auf Alfred zu flaschen, bekam ich erst den Fehler, dass bei Arduino irgendetwas fehlt. So kam mir die Idee mal das flash.sh script anzuschauen. Läuft der Banana Pi auf 32 bit? Ich habe zumindest die Arduino version unter wget auf die 64 bit Version geändert. Danach war der Fehler weg. Allerdings habe ich jetzt immer noch folgenden Fehler, wenn ich sudo ./flash.sh ausführen will:
Error: STMicroelectronics: Unknown package
ERROR: no firmware binary was generated! Check above for errors!

Ich denke, das also an der Konfiguration irgendwas noch nicht stimmt. Kann mir jemand zufällig seinen sunray_install Ordner teilen? Ich könnte mir vorstellen, dass das den Fehler behebt.

Viele Grüße
Konrad
 
Nein, ich habe nur das, was ich mal von AlexanderG bekommen habe und das wird nichts anderes als die Version aus dem banana Pi sein.
 
Die Sunray-Firmware wird unter Linux nicht geflasht - nur bei Änderungen an der STM32-Alfred-Roboter-Firmware (alfred/firmware/rm18.ino) muss die Roboter-Firmware neu geflasht werden.

Zum Kompilieren der Roboter-Firmware (mit Arduino-Compiler) benötigt man entsprechende Arduino CPU-Library (STM32 von STMicroelectronics) - diese muss bei einem selbst erstellen Linux-Image noch installiert werden:
1. sicherstellen dass die Datei exisiert: /home/pi/ngp_rm18/config_files/arduino/package_stmicroelectronics_index.json (Datei ist jetzt auf Github: https://github.com/Ardumower/Sunray/tree/master/alfred/config_files)
2. ./flash.sh und dann auswählen "install_arduino_ide"
 
Zuletzt bearbeitet:
Hallo Alexander,
ich weiß nicht, ob ich zu doof bin, aber ich bekomme immer noch den selben Fehler. Ich habe mir ja den sunray_install Ordner vom Banana Pi von Alfred kopiert und auf meinen RPi 4 kopiert. Somit habe ich unter /home/pi/sunray_install/config_files/arduino/ schon die package_stmicroelectronics_index.json Datei.
In deiner flash.sh ist dort folgendes notiert (ich habe bei bei Arduino den Pfad auf die aarch64-Version geändert):

function install_arduino_ide {
if [ ! -d "/home/pi/arduino-1.8.19" ]; then
echo "installing Arduino IDE..."
cd /home/pi/
runuser -l pi -c 'wget https://downloads.arduino.cc/arduino-1.8.19-linuxaarch64.tar.xz'
runuser -l pi -c 'tar -xvf arduino-1.8.19-linuxaarch64.tar.xz'
cd arduino-1.8.19/
sudo rm /usr/local/bin/arduino
sudo ./install.sh
sudo usermod -a -G dialout $USER
fi
echo "installing STMicroelectronics boards..."
# https://github.com/arduino/Arduino/blob/master/build/shared/manpage.adoc
#runuser -l pi -c 'arduino --install-boards arduino:sam'
runuser -l pi -c 'arduino --save-prefs --pref "boardsmanager.additional.urls=file:///home/pi/sunray_install/config_files/arduino/package_stmicroelectronics_index.json"'
runuser -l pi -c 'arduino --install-boards STMicroelectronics:stm32'
}
Zum Vergrößern anklicken....
Das heißt, der Ordnerlink für die json Datei ist doch schon richtig hinterlegt oder? Selbst wenn ich die Datei, wie von dir beschrieben, unter /home/pi/ngp_rm18/config_files/arduino/package_stmicroelectronics_index.json ablege, bekomme ich jedes Mal wieder den "unknown package" Fehler.

Wenn ich sunray so installiere und keine Firmware flashe, regt sich bei Alfred garnichts. Auch werden keine Daten zur Batterie etc. übertragen. Daher dachte ich, dass ich die firmware erst flashen muss...außerdem wäre es schön, die Möglichkeit der Anpassung der Firmware nutzen zu können ;)
Was mache ich falsch?
 
Kann die Sunray-Firmware denn eine Kommunikation zur Alfred-Firmware aufbauen? Was zeigt das Console-Log (showlog.sh)...
 
Dann muss ich erstmal die Pi in Alfred bauen. Momentan habe ich erstmal wieder auf BPi umgebaut.

Ich habe noch ein Problem mit dem RTK: ich habe meine eigene Ardusimple F9P gebaut, die ich nutze. Die habe als base configuriert und sende die Korrekturen via UART2 zum Xbee.
Alfred empfängt diese auch wunderbar und hat einen stabilen fix. Bis nach ca. 6-7 Minuten die Korrekturen nicht mehr "ankommen", d.h. die Zeit der zuletzt empfangenen Daten steigt und steigt.
Ich habe die RTCM 1005 schon auf 10 gestellt und 1124 deaktiviert. Egal, was ich einstelle, nach 6-7 Minuten nimmt Alfred keine Daten mehr an.
Kann es an der Base liegen? Ich habe die aktuelle ublox firmware (132?) installiert. Hat jemand eine passende config für mich?

Das steht im Log, wenn das Korrektursignal nach 60 Sekunden weg ist.
IMG_7337.png

edit: auch hier nach sehr intensiven Versuchen und vielen, vielen Stunden Arbeit habe ich eine Lösung gefunden: ich habe die Baudrate beim Xbee 868 auf standardmäßiger rate von 115200 gelassen, sodass die Daten mit maximaler Geschwindigkeit gesendet werden. Allerdings muss die Bandwidth limitiert werden, da mein Xbee maximal 24 Kbps senden kann! Werden mehr Daten gesendet, so füllt sich der TX buffer, bis dieser voll ist. Dann stellt das (TX) Xbee seinen Dienst ein! Leider bekommt man das nur beim RX Xbee (im Rover) mit, da dort keine Daten mehr ankommen (also auch die XBEE > GPS LED aus bleibt), jedoch vom Ardusimple der Basisstation munter weiter Daten gesendet werden und daher die GPS > XBEE LED weiter blinkt.
Um die Datenrate zu limitieren, habe ich folgende Werte bei der Base eingestellt:
RTCM 1005: 10
RTCM 1074: 10
RTCM 1084: 10
RTCM 1094: 10
RTCM 1124: 0
RTCM 1230: 10

Mit diesen Raten scheint der buffer nicht überfüllt zu werden und Xbee verrichtet seinen Dienst! Ich hatte es vorher mit jeder sechsten Nachricht probiert, aber auch das führt nach ca. 50 Minuten zum buffer overflow...jede 10te geht auf jeden Fall zuverlässig und auch das RTK bleibt bei einer Genauigkeit von 2 cm.
 
Zuletzt bearbeitet:
AlexanderG schrieb:
Kann die Sunray-Firmware denn eine Kommunikation zur Alfred-Firmware aufbauen? Was zeigt das Console-Log (showlog.sh)...
Zum Vergrößern anklicken....
Apr 09 16:53:05 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=47/0 summaryFreq=2/0
Apr 09 16:53:06 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:06 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=47/0 summaryFreq=2/0
Apr 09 16:53:07 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:07 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=48/0 summaryFreq=2/0
Apr 09 16:53:08 raspberrypi start_sunray.sh[586]: Info - LoopTime: 3 - 0 - 0.44 - 22ms
Apr 09 16:53:08 raspberrypi start_sunray.sh[586]: 0:1:30 ctlDur=0.02 op=Idle(initiatedByOperator 0) mem=3692 bat=28.00,0.000(0.00) chg=0.00,0(0.00) diff=-28.000 tg=0.00,0.00 x=12.48 y=42949672.00 delta=0.97 tow=226406800 lon=12.XXXXXX lat=54.XXXXX h=54.8 n=0.00 e=0.00 d=0.00 sol=0 age=90.62
Apr 09 16:53:08 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:08 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=47/0 summaryFreq=2/0
Apr 09 16:53:09 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:09 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=47/0 summaryFreq=2/0
Apr 09 16:53:10 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:10 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=48/0 summaryFreq=2/0
Apr 09 16:53:11 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:11 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=48/0 summaryFreq=2/0
Apr 09 16:53:12 raspberrypi start_sunray.sh[586]: WARN: resetting motor ticks
Apr 09 16:53:12 raspberrypi start_sunray.sh[586]: WARN: SerialRobot unmet communication frequency: motorFreq=47/0 summaryFreq=2/0
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Nein, dein Raspberry PI kommuniziert nicht mit dem Alfred Motherboard. Ist die Serielle Schnittstelle im Raspberry Pi aktiv?
 
Ein paar Ideen:
1. Es könnte ein unterschiedliches Pinout zwischen BananaPI M4 (https://wiki.banana-pi.org/Banana_Pi_BPI-M4#GPIO_PIN_define) und Raspberry PI (https://pinout.xyz/) für den UART vorliegen (Hardware Pins 8 und 10), so dass das Alfred-DIY-PCB nicht passen würde - sieht für mich auf den ersten Blick aber nicht danach aus.
2. Der Raspberry UART-Geräte-Pfad könnte ein anderer sein als beim Banana-PI (config.h: #define SERIAL_ROBOT_PATH "/dev/ttyS1" ).
Den UART-Pfad z.B. herausfinden mit "dmesg | grep uart"
3. Die Baudrate zwischen Roboter-Firmware (rm18.ino:
#define CONSOLE_BAUDRATE 19200 ) und Sunray-Firmware könnte nicht zueinander passen (config.h: #define ROBOT_BAUDRATE 19200 )
4. Es könnte ein Geräte-Pfad Rechte-Problem vorliegen: läuft das Sunray-Binary als "Root-User" ("sudo ./sunray")? Falls nicht, darf der Benutzer auf den Gerätepfad zugreifen? (https://roboticsbackend.com/raspberry-pi-hardware-permissions/ )
5. Es könnte eine andere Linux-Anwendung den Gerätepfad belegt haben. Übliche "Verdächtige" sind z.B. "Modem Manager" (https://forums.raspberrypi.com/viewtopic.php?t=150611 )

Herausfinden, ob ein Linux-Prozess einen Gerätepfad geöffnet/belegt hat (Beispiel):
Gerätepfad belegen (Abbrechen mit CTRL+C):
alex@alexpc:~$ cat /dev/ttyS4

Prüfen ob und was den Gerätepad belegt (neues Terminal-Fenster):
alex@alexpc:~$ lsof /dev/ttyS4 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME cat 31581 alex 3r CHR 4,68 0t0 487 /dev/ttyS4
 
Zuletzt bearbeitet:
Danke @AlexanderG, das werde ich bei Gelegenheit mal testen. Erstmal bin ich damit leider noch nicht weiter gekommen.
2. UART ist anscheinend /dev/ttyS0, wie EinEinfach schon geschrieben hat..
3. die Baudrate ist bei mir auf 115200 eingestellt...das scheint zu passen...
4. ich habe die Ordner mal mit ls -la gelistet und sie gehören zum user pi und zur Gruppe pi. Schreib- und Leserechte sind bei allen Ordnern gleich.
5. ModemManager ist nicht installiert. Wenn ich cat /dev/ttyS0 eingebe, passiert nichts und es wird auch nichts gelistet.

Außerdem möchte ich mich bei dir mal bedanken! Die Sunray Software ist aus meiner Sicht schon mega gut gemacht und ich finde es einfach nur genial, was du dort alles eingebaut hast! Als ich heute dann auch noch in der config.h die Variablen gefunden habe, wann Alfred den Akku als leer und voll erkennt, habe ich mich bzw. dich echt gefeiert! Gerade für meinen großen 20 Ah Akku ist das aus meiner Sicht eine geniale Einstellmöglichkeit. So kann Alfred morgens mit einem vollen Akku starten und wenn er leer ist, so lange laden, bis z.B. die Zellen bei 3,9 V sind und dann nochmal ein paar Stunden mähen, bevor er dann (durch den genialen Zeitplan gesteuert) zum finalen Laden fährt und der Akku dann über Nacht vollständig laden kann!
Auch die Erkennung von Hindernissen und von Situationen, wo Alfred sich festfährt, funktionieren schon echt super!
Ich habe noch eine experimentelle Funktion der smooth curves gefunden. Kannst du diese empfehlen?

Vielen Dank für deinen Einsatz! Wenn ich mit meinen Möglichkeiten irgendwie helfen kann, gib mir gerne Bescheid!
 
Nachtrag: wie heute gemeinsam herausgefunden noch die Lösung für andere (Beschreibung wurde auch ins Github übernommen) - Die Ursache war ein anderer Linux-Prozess welcher (sporadisch) auf die UART-Schnittstelle zugegriffen und gestört hat:
# find out processes accessing the UART serial path: sudo lsof /dev/ttyS0 # list all running services: sudo systemctl list-units --type=service --state=running # stopping/disabling service sudo systemctl stop serial-getty@ttyS0.service sudo systemctl disable serial-getty@ttyS0.service
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben