Menü
Aktuelles
Von:
Filter

Sunray modding Spielwiese

Hmm, verstehe ich nicht. Auszug aus der ChargeOp.cpp:
Code: 
   if (MOVE_REGULARLY){
       ...

Der Code wird also nur ausgeführt, wenn MOVE_REGULARLY true ist. So, wie es sein soll.
 
jklotzek schrieb:
Import JSON map:
Data source management Anhang anzeigen 7394 -> Vector -> File->Vector datasets: YourGarden.json -> Add -> Add layer
Grid: Processing -> Toolbox (so that Processing tools are visible on the right) -> Vector generation -> Create grid (double click) -> Grid KBS: EPSG:5833 select from Compound -> Select grid size -> Select distances, e.g. 10 cm -> Overlay should remain 0 -> Start -> Close

Anhang anzeigen 7395


This is THE tool for map editing!!! Thank you for the find, Mr. Tree!
Zum Vergrößern anklicken....
@jklotzek how did you export the map and import back into sunray? I've been able to create the grid but not able to get the map back into Sunray. It seems like the GeoJson output from QGIS doesn't register in sunray. Any suggestion on how to resolve this?
 
After export the geojson out of QGIS you need to edit it:

Mr.Tree says:
- damit die exportierte map von QGIS mit cassandra geladen werden kann, muss einmal händisch die "crs" line ("crs": { "type": "name", "properties": { "name": "urn:eek:gc:def:crs:OGC:1.3:CRS84" } }, ) am Anfang aus der geojson zb. mit notepad oder programmersnotepad rausgelöscht werden
 
@Mr. Tree, ich habe heute zum 2. Mal mit deiner 319.6 gemäht und ich muss sagen, es ist ein Traum! Der Mower fährt so geschmeidig über den Rasen, wie ich es in den knapp zwei Jahren seit ich ihn habe, noch nicht erlebt habe. Kein Zucken und Zappeln und keine unnötigen Drehungen am Bahnende!
Ich hatte zuletzt mit der 322 gearbeitet, die lief zwar bei mir besser als die beiden vorherigen Versionen, aber immer noch nicht richtig sauber ohne 270°-Drehungen und ein ständiges Tänzeln an den Bahnenden.
In Verbindung mit CaSSAndRA von @EinEinfach ist das jetzt das, was ich von Ardumower erwartet habe.
Vielen Dank euch beiden für die hervorragende Arbeit!
 
Mr. Tree schrieb:
Diese Sache könnte man vllt fixen, indem man sagt... Immer wenn ein Fahrbefehl kommt in der comm.cpp, die OP in idle zu ändern. Das wäre vllt der Totschlag workaround. Das würde den Error OP dann einschließen. Also alle Operationen. Danach muss man halt wieder auf start drücken, sollte auch eigentlich so sein.
Zum Vergrößern anklicken....
sooo, das habe ich jetzt umgesetzt und ausprobiert. Läuft wunderbar.
Einfach in der comm.cpp hier folgendes einfügen
void cmdMotor(){
if (cmd.length()<6) return;
if(activeOp->name() != "Idle")activeOp->changeOp(idleOp);
...
Zum Vergrößern anklicken....
Damit kann man sich jederzeit aktiv einmischen. ;)
 
Mr. Tree schrieb:
Wenn jemand Änderungen oder Bugfixes hat, gerne im Github commiten.
Zum Vergrößern anklicken....
mir fällt mal pauschal die Implementierung der v3 Sparkfun Bibliothek ein, die läuft echt sauber.

Kein Reboot bei reboot GPS mehr- stabilerer FIX

Um den Ardumowerreset beim Reboot GPS auszuschalten habe ich auf die SparkFun_u-blox_GNSS_v3 migriert. Die alte Version ist von 2016 , die neue von 2022 mit vielen Verbesserungen. Getestet mit Sunary 1.0. 230 und 1.0. 298 Am einfachsten nehmt den Bibliotheksmanager und installiert...
forum.ardumower.de

Kein Reboot bei reboot GPS mehr- stabilerer FIX

Um den Ardumowerreset beim Reboot GPS auszuschalten habe ich auf die SparkFun_u-blox_GNSS_v3 migriert. Die alte Version ist von 2016 , die neue von 2022 mit vielen Verbesserungen. Getestet mit Sunary 1.0. 230 und 1.0. 298 Am einfachsten nehmt den Bibliotheksmanager und installiert...
forum.ardumower.de
 
Moin,

gibt es eine Übersicht was genau gegenüber der "original" Sunray Firmware alles geändert wurde?

Benutzt jemand Mr. Tree's gemoddete Sunray auf Alfred, und wie sind die Erfahrungen damit?

Beste Grüße,
Chris
 
Die Übersicht wäre das initiale überschreiben der .322 vom masterbranch mit der 319 von mir vor ein paar tagen, nicht optimal aber ...tja XD. Ist im Github. Um das im Alfred zu verwenden sind mindestens tests nötig, Ich habe keinen Alfred, deshalb wird da von meiner Seite nix passieren, wenn es aber wer übernimmt und es läuft dann zieh ich das natürlich mit rein.
 
Huge BUG?:
Code: 
Linetracker.cpp angular: 0.00
Linetracker.cpp linear: 0.00
clearObstacles
LineTracker.cpp targetPoint  x = -9.27 y = -15.68
Linetracker.cpp angular: -25.00
Linetracker.cpp linear: 0.25
Linetracker.cpp linear: 0.40
dumpState:  X=-6.31 Y=-43.45 delta=1.71 mapCRC=-2428891 mowPointsIdx=393 dockPointsIdx=1 freePointsIdx=1 wayMode=3 op=1 sensor=0 sonar.enabled=1 fixTimeout=120 absolutePosSource=0 lon=0.00 lat=0.00 mowPwm=250 finishAndRestart=0 motorMowForwardSet=1
save state... ok

TUNING_LOG (disable in config.h):
---------------------------------------------------->
motor.cpp: adaptive_speed() -- motorMowRpmSet: 3000.00 RPM, Batt: 25.40 V, mowMotorPower: 5.04 Watt
                               speedcurr: 0.40 m/s, Speedfactor: 1.00

motor.cpp: sense()          -- mowPowerAct: 5.04 Watt, motorMowSense: 0.20 A, motorMowSenseLP: 0.15 A
                               motorLeftSense: 0.17 A, motorLeftSenseLP: 0.23 A
                               motorRightSense: 0.25 A, motorRightSenseLP: 0.19 A

IMU                         -- diffIMUWheelYawSpeedLP = 1.41 deg/s, stateDeltaSpeedIMU = -10.30 deg/s, stateDeltaSpeedWheels = -11.34 deg/s, stateDeltaSpeedLP = 6.22 deg/s
<----------------------------------------------------

Linetracker.cpp angular: 0.00
Linetracker.cpp linear: 0.00
yaw difference between wheels and IMU for requested rotation => assuming obstacle
triggerObstacleRotation
==> changeOp:EscapeForward(initiatedByOperator 0)->Mow

driveForwardStopTime
==> changeOp:Mow(initiatedByOperator 1)
MowOp::begin
MowOp:: set linear = 0, angular = 0
battery.setIsDocked 0
Map::startMowing
findObstacleSafeMowPoint checking -9.27,-15.68
findPath (-6.51,-42.86) (-9.27,-15.68)
path finder is enabled (using FLOAT_CALC)
freem=197171  allocating nodes 384 (9216 bytes)
freem=197171
starting path-finder
.finish nodes=384 duration=80
node pt=-9.27,-15.68
node pt=-6.51,-42.86
MowOp::begin switch ON mowmotor --> startMowing
Motor::setMowState RPM - Motor already switched on!
LineTracker.cpp targetPoint  x = -6.51 y = -42.86
LineTracker.cpp targetPoint  x = -9.27 y = -15.68
dumpState:  X=-6.54 Y=-42.87 delta=-2.91 mapCRC=-2428891 mowPointsIdx=393 dockPointsIdx=1 freePointsIdx=1 wayMode=4 op=1 sensor=0 sonar.enabled=1 fixTimeout=120 absolutePosSource=0 lon=0.00 lat=0.00 mowPwm=250 finishAndRestart=0 motorMowForwardSet=1
save state... ok

TUNING_LOG (disable in config.h):
---------------------------------------------------->
motor.cpp: adaptive_speed() -- motorMowRpmSet: 3000.00 RPM, Batt: 25.42 V, mowMotorPower: 6.59 Watt
                               speedcurr: 0.35 m/s, Speedfactor: 1.00

motor.cpp: sense()          -- mowPowerAct: 6.59 Watt, motorMowSense: 0.26 A, motorMowSenseLP: 0.17 A
                               motorLeftSense: 0.48 A, motorLeftSenseLP: 0.34 A
                               motorRightSense: 0.16 A, motorRightSenseLP: 0.31 A

IMU                         -- diffIMUWheelYawSpeedLP = 35.57 deg/s, stateDeltaSpeedIMU = 23.17 deg/s, stateDeltaSpeedWheels = -17.22 deg/s, stateDeltaSpeedLP = 591.50 deg/s
<----------------------------------------------------

yaw difference between wheels and IMU for requested rotation => assuming obstacle
triggerObstacleRotation


Seems like the pathfinder algo is causing strange values for the imu algos even if the mower is not moving while pathfinder is active!

Take a look at this!
stateDeltaSpeedLP = 591.50 deg/s
diffIMUWheelYawSpeedLP = 35.57 deg/s
 
Ja, ist mir auch schon aufgefallen, passiert ganz oft nach dem der Mähvorgang beendet wird und der Pathfinder den Weg bis zur Dockingstation sucht, dann gibt es einen Obstacle error
 
Dieses Problem habe ich schon häufig beobachtet, aber auch mit allen sunray-Versionen, die ich vorher genutzt habe. Der Mower ist mit mähen fertig, CaSSAndRA zeigt 'finished, docking', dann kommt sofort 'ERROR Obstacle' und der Mäher bleibt am letzten Punkt stehen. Es kommt sogar recht selten vor, dass er tatsächlich zur Station fährt.
 
Das ist ja merkwürdig. Bei mir fährt er IMMER ins Dock (zwischendurch zum Nachladen und am Ende des Tasks. Die ersten beiden Saisons mit Sunray, diese Saison mit Cassandra) Ich habe noch nie erlebt, dass er es nicht ins Dock schafft. Ich bin in der 3. Saison dabei und habe immer upgedatet, also schon ein paar Versionen mit gemacht.
 
themanfrommoon schrieb:
Das ist ja merkwürdig. Bei mir fährt er IMMER ins Dock (zwischendurch zum Nachladen und am Ende des Tasks. Die ersten beiden Saisons mit Sunray, diese Saison mit Cassandra) Ich habe noch nie erlebt, dass er es nicht ins Dock schafft. Ich bin in der 3. Saison dabei und habe immer upgedatet, also schon ein paar Versionen mit gemacht.
Zum Vergrößern anklicken....
Kommt drauf an, wenn der Pathfinder nicht rechnen muss um ins Dock zu kommen, dann funktioniert, sobald der Pathfinder losläuft kommt es zum Obstacle
 
Das kommt darauf an, ob obstacle rotation aktiviert ist! Mir ist das jetzt aufgefallen, weil ich die trigger Zeit reduzieren will. Dann kommt das auch im Betrieb z.b nach einem obstacle oder wenn er einen anderen Bereich anfährt und er den pathfinder nutzen muss

Dort wird dann auch nicht resettet und der trigger scheint hintereinander hochzulaufen.

Es sind zwei bools für den reset vorgesehen, wobei diese funktionen dann aber nicht die messwerte selbst wieder nullen, sondern nur die startzeit/totzeit des triggers. Das sind shouldrotate und shouldmove oder so.. Das Problem sollte lösbar sein, entweder mit entsprechenden resets im linetracker oder direkt in motor.cpp weil dort die tatsächlichen fahrbefehle aller funktionen zusammenlaufen oder in den ops...
 
Zuletzt bearbeitet:
Mein Docking Pfad besteht ais zwei Punkten. Allerdings ist die Karte schon komplex, so dass zum erreichen sicherlich ungefähr 3-8 Ounkte errechnet werden müssen, je nach aktuellem Standort des Rovers
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben