Menü
Aktuelles
Von:
Filter

Sunray modding Spielwiese

Wie es aussieht kann es aber auch ein Laufzeitproblem sein. Wenn der pathfinder arbeitet steht der roboter ja, eigentlich sollten die bools dann resetten, es sei denn sie lesen alte werte aus motor.cpp aus, die noch garnicht nach dem pathfinder durchgelaufen ist.
 
Mr. Tree schrieb:
Wie es aussieht kann es aber auch ein Laufzeitproblem sein. Wenn der pathfinder arbeitet steht der roboter ja, eigentlich sollten die bools dann resetten, es sei denn sie lesen alte werte aus motor.cpp aus, die noch garnicht nach dem pathfinder durchgelaufen ist.
Zum Vergrößern anklicken....
Muss ein Laufzeitproblem sein, bei einfachen Pfaden klappt es auch, sobald der Pathfinder nachdenken muss, geht es bei mir in die Hose
 
Ich habs jetzt mal mit diesen Änderungen versucht, noch nicht getestet:

Code: 
// should robot rotate?
bool robotShouldRotate(){
  if ((fabs(motor.linearSpeedSet) < MOTOR_MIN_SPEED/2) &&  (((fabs(motor.angularSpeedSet))/PI*180.0) > 2.5)) return (true);//MrTree changed to deg/s (returned true before if angularspeedset > 0.57deg/s), reduced linearSpeedSet condition
  else {
    stateDeltaSpeedLP = 0;      //MrTree reset measurement
    diffIMUWheelYawSpeed = 0;   //MrTree reset measurement
    diffIMUWheelYawSpeedLP = 0; //MrTree reset measurement
    return (false);
  }
}

Der true trigger war vorher auch sehr niedrig bei 0,5deg/s... also kaum sichtbare Rotation, auf dem Rasen eher unrealistisch.
 
Zuletzt bearbeitet:
WhatATest schrieb:
Does that mean the robot is turning while computing the path finding?


Timesteps size is hardcoded in StateEstimator, here for example:
github.com

Sunray/sunray/StateEstimator.cpp at 160d39b22c33cca61071d4e5fd7b87a48251bfdb · Ardumower/Sunray

Ardumower Sunray. Contribute to Ardumower/Sunray development by creating an account on GitHub.
github.com github.com

Changing that 0.02 for the actual time delta might fix it.
Zum Vergrößern anklicken....
That is indeed an issue, beside it´s not turning in the process.
 
Ich hab etwas auf Github hochgeladen das bisher anscheinend den obstaclerotation bug eindämmt aber die funktionaliät des triggers noch gewährleistet. Brute force allerdings an mehreren stellen, sauber ist das nicht... aber es scheint zu funktionieren, mit resetAngularMotion(); bisher läuft der mower seit ein paar stunden durch mit einer absichtlichen niedrigen triggerzeit von #define ROTATION_TIME = 1000 ms .. also 1 sek, ich mache noch ein Update nachdem er durch unterspannung zum dock will ohne eingreifen.. So wie er sonst nach dem dock befehl und daraufhin mit dem pathplanner sporadisch mit error stehen geblieben ist.


2024-06-13_000306.jpg
 
Zuletzt bearbeitet:
Ich habe einen Alfred und habe den letztens auf einen Raspberry Pi 4 umgerüstet. Dort habe ich die normale Sunray Version genutzt. Diese läuft jedoch nicht so rund wie man das erhofft. Diese Version hier soll wesentlich besser funktionieren. Da ich mich mit Linux nicht ganz so gut auskenne wollte ich mal Fragen ob mir jemand ein fertiges iso bereitstellen könnte das ich mit einer separaten SD-Karte mal austesten könnte?
 
Ich glaube so einfach ist das leider nicht... Aber vllt schon, ich weiß es nicht. Habe noch nie in die Alfred config.h und die ganzen Dateien reingeschaut ...
Da müsste sich mal jemand kompetentes zu äussern.

Ich warne auch davor dass einfach so auszuprobieren! Wer weiß ob die ganzen Hardware Pins etc gleich belegt sind, ein Hardwaredefekt ohne gewisse Überprüfungen kann nicht ausgeschlossen werden.
 
Mr. Tree schrieb:
Aber vllt schon, ich weiß es nicht. Habe noch nie in die Alfred config.h und die ganzen Dateien reingeschaut ...
Zum Vergrößern anklicken....
Eigentlich ist es easy, aber der Teufel Steckt wie immer im Detail

Grob:
1. Dein repository auf den Pi clonen
2. Die config.h im Alfred Ordner mit deiner config.h aus dem Sunray Ordner vergleichen und neue Sachen ergänzen
3. Aktuellen Sunray Dienst stoppen mit sudo systemctl stop sunray
4. In den alfred/build Ordner wechseln
5. rm -Rf *
6 cmake..
7 make
8 sudo ./sunray
9. Wenn alles so läuft wie man sich vorstellt, dann den Sunray Dienst auf den neuen Sunray Ordner ummünzen
 
Zuletzt bearbeitet:
Hab mal die original config´s mit dem diffchecker angesehen, änderungen sind minimal und betreffen nur komponenten wie treiber und wheel size etc.., sollte also wirklich kein problem sein. Allerdings sind, obwohl alles einstellbar ist, sämtliche mod funktionen auf die ardumower hardware abgestimmt. Hier muss man sicherlich einige male was ändern und neu kompilieren, sodass es auf dem alfred rund läuft. Diese Arbeit werde ich nicht leisten können. @Novus, ich schlage also vor das du dich befähigst. Scheint wirklich machbar, irgendwann ist immer das erste mal.
 
Zuletzt bearbeitet:
@Mr. Tree, auch wenn du hier evtl nicht helfen kannst, sondern das schon in der Original-FW so eingebaut wurde.

Ich habe mal eine Frage zum Dockingpfad und Mähstart:
Warum startet der Mähmotor nachdem die Map hochgeladen wurde, um dann die Docking-Station zu verlassen und dann auf dem Dockingpfad zum ersten Mähpunkt zu fahren? Könnte der Mähmotor nicht erst dann starten, wenn er im Mähgebiet angekommen ist?
Denn wenn der Mower fertig ist und zur Dockingstation zurückkehrt, ist der Mähmotor ja auch aus.

Mir fiel das gestern besonders auf, da der Dockingpfad zur vorderen Mähfläche durch eine andere Mähfläche führt und dort jetzt eine gemähte Spur sichtbar ist.
 
Hab's gerade kurz getestet, scheint zu funktionieren. Ich stell es nachher in den master, kannst du dann in der config.h aktivieren. Könnte sein das es zu Problemen kommt nach obstacle falls er dann im waymode wayfree ist. Dann bleibt das mähwerk aus.
 
MOW_ONLY_WAYMOW

Allerdings funktioniert es nicht gut. Schau dir die Beschreibung an. Die infrastruktur gibt da leider nix schnelles her, weil WAY_FREE für den pathplanner und die obstacles genutzt wird... ob er den pfad zum mähpunkt sucht nach obstacle oder dock, wird nicht unterschieden.
 
Hab's umbenannt und einen workaround für das problem gefunden, da diese Option doch ganz nützlich ist. Ist jetzt ein onetimetrigger, der nur nach dem undock einmal triggert, wenn er den ersten waystate= waymow status hat.
 
Zuletzt bearbeitet:
code hat nicht funktioniert, hatte ein undock fehler... und der eigentliche fix hat nicht funktioniert. hab es jetzt aber doch hinbekommen, ist auch getestet...... @_@
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben