Posts by mberghoefer

    Das ist nicht ganz korrekt. Neue Funktionalität kann auch ohne App-Update ermöglicht werden.

    Alles, was die Firmware braucht, um die eigene Funktionalität zu ändern, ist die Fähigkeit, Module vom Server laden und diese dann einbinden zu können. Deshalb baut man sowas, also das Kommunikations- und Funktionalitätsgerüst (nicht aber die eigentlichen Detail-Funktionalitäten) eigentlich als allererstes in autonome System ein (und das wurde schon vor vierzig Jahren so gemacht, wenn die Infrastruktur das zuließ).


    On Ecovacs das so gemacht hat, weiss ich natürlich nicht.

    Aber ein App-Upgrade wird nie etwas am "Verhalten" des Roboters ändern. Dazu muss es ein Firmware-Upgrade auf dem Roboter geben.

    nicht notwendigerweise. Wenn die bestehende Firmware vernünftig programmiert ist, dann würde sie praktisch alle veränderlichen Parameter der Konfiguration des Roboters aus dem Server lesen, ganz egal ob eine App heute schon in der Lage ist, die zu ändern, oder erst morgen in der Lage dazu wäre. Dazu könnte sowas wie "Wasserdurchfluss" schon gehören.
    Dass Konfiguration nicht "hard-coded" in der Software selbst abgelegt werden sollten, das ist seit Jahrzehnten schon "normal" und wird eigentlich nur von Fricklern mißachtet.

    Und wenn die Firmware wirklich gut programmiert ist, dann wird sie nicht nur Parameter sondern sogar Algorithmen (also Funktionalitäten) vom Server laden können.

    Avaloss und andiber und MK34


    Ich lese heute bereits schon zum zweiten mal, dass der O950 virtuelle Grenzen missachtet. Könntet ihr mir das mal genauer schildern? Wie genau kommt es dazu - oder habt ihr ein Bild/Screenshot davon?


    Wenn ich "Beweismaterial" habe, kann ich sowas immer viel leichter an Ecovacs weitergeben.

    das Überfahren virtueller Grenzen passiert bei mir auch, allerdings sehr sehr selten, und immer nur dann, wenn er relativ kurz vorher an irgendeiner Stelle ein Problem hatte, das seine Positionsbestimmung beeinträchtigte, also zB Verrutschen beim Überfahren einer Teppichkante oder Türschwelle, Festfahren und etwas Rangieren an Teppickecken, Verschieben eines Teppiches während des Auffahrens, kurzes Hängenbleiben mit Versetzen am Hindernis (bei mir zB eine Pflanze, die dem Boden sehr nahe kommt und beim Anfahren ein paar Zentimeter nachgibt.).


    Solche Problemstellen sind in der Karte oft gut zu erkennen weil dort vergleichsweise "dickere" oder "erkennbar chaotischere" Fahrspuren eingezeichnet sind.


    Wie gesagt, passiert, aber wirklich selten (1 mal im Monat bei mir)

    hatte ich neulich auch zweimal, dass der Roboter auf Teppich plötzlich die Saugleistung nicht mehr erhöhte. Der Staubbehälter war selbst am Ende der Fahrt bei weitem nicht voll, daran kann's nicht liegen. Irgendetwas muss den Teppichsensor blockiert haben, hab ich angenommen. Der sah aber auch ganz ok aus.

    Was mich als einziges so richtig stört ist, dass wenn er direkt auf eine spitze Teppichkante auffährt, er in 95% der Fälle erstmal mit durchdrehenden Reifen dort hängen bleibt, dabei ist es nahezu egal, wie hoch die Kante ist.

    Irgendwann merkt er es dann und wenn man Glück hat, probiert er es etwas versetzt nochmal, sonst geht's halt von vorne los. :/

    genau für diese Situation hab ich im "Änderungs-Abstimmungs"-Thread einen Vorschlag gemacht, wie das per Software zu optimieren wäre.

    bei uns sind ab dem 18.12. überhaupt keine Reinigungsläufe mehr im Protokoll abgelegt, erst gestern (27.12.) mal wieder - allerdings nicht jeder Reinigungslauf.

    Für mich ist das auch ein ziemlich nebensächliches Problem. Würde ich unbeaufsichtigte Reinigungsläufe programmieren, wäre das was anderes.

    Da ich auch im Staubbehälter feuchtes Sammelgut hatte und immer wieder habe -- ist dies auch eine Sache für die Abstimmaktion. Ich wäre z.B. dafür, daß es eine NUR_Wischfunktion gäbe. Werde es mal drüben einfügen ;)

    Ja, das ist ein guter Vorschlag.

    Hab den Roboter jetzt seit 7 Wochen, in dieser Zeit vielleicht 10 mal wischen lassen. Heute hab ich ihn zum zweiten mal komplett sauber gemacht und dabei einiges an Schmutz unter der Bürste und innen an der Bürstenabdeckung gefunden, der wohl von feucht augesaugten Partikeln herrührt und sich schon derart ordentlich abgesetzt hatte, dass er mit Krafteinsatz herausgekratzt werden musste.

    Ich glaube auch, dass diese Ablagerungen zunehmend die Staubaufnahme beim Saugvorgang behindern, insbesondere den Transport zum Auffangbehälter. Nicht schön.

    Daher sauge ich erst mit dem 950 und dann kommt die Wischfunktion

    Der 950 saugt doch sowieso, wenn man die Wischfunktion nutzt. Wieso dann vorher schonmal saugen lassen und alle Flächen doppelt befahren (doppelt so viel Zeit, doppelt so viel Verschleiß an Bürsten usw)?

    richtig, und der Roboter hat eine Teppicherkennung, er erkennt also erstens wo der Teppich jetzt ist und damit zweitens, ob er sich bewegt hat. Natürlich würde er einen "neuen Teppich" erst bei der ersten Überfahrt erkennen und kartieren können, aber das ist ebenfalls kein Problem, denn entweder hat er ihn tatsächlich überfahren (und er ist nun sauber und muss gar nicht nochmal gereinigt werden) oder er hat ihn beim Wischen erkannt und ausgelassen (und ist damit eindeutig positionierbar).


    Wie gesagt, du unterschätzt m.E. was mit Software machbar ist und wie wenig komplex das ist bei zweidimensionalen Binärkarten wie den von Ecovacs genutzten.

    Und meinen Beobachtungen nach müsste auch an der Software etwas gemacht werden. Mal fährt er problemlos drüber, mal ist er recht langsam und hängt dann und rudert wild hin und her als ob es kein morgen gäbe. Da könnte die Software auch eine "Türschwelle" also Hinderniserkennung machen und dann darauf anders reagieren.

    hatte ich im "Vorschlag-Abstimmungs"-Thread vorgeschlagen, wurde aber nicht in die Liste aufgenommen. Warum, weiss ich nicht.

    Für mich wäre es ebenfalls die einfachste Optimierung, dem Roboter per Software beizubringen, dass er Teppiche und Schwellen nur so anfahren soll, dass beide Räder gleichzeitig die Kante berühren (also "frontal"), das ergibt die höchste Wahrscheinlichkeit, dass das Klettern funktioniert (und die geringste Wahrscheinlichkeit, in einer Teppichecke hängen zu bleiben)

    catraxx , in der aktuellen Liste sehe ich, dass du den Punkt "fahre zu Punkt X" aufgenommen hast, nicht aber "Reinigungsläufe als "nur Teppiche", "keine Teppiche", "auch Teppiche" (das ist aktuell die Norm) definieren können".

    Ich vermute das liegt daran, dass es bei dir keine Teppiche gibt und/oder du die Wischfunktion nicht nutzt?


    Der Sinn dieser Funktion liegt darin, dass jeder, der eine Wohnung mit Teppichen hat, für wischen+saugen der gesamten Wohnung die Teppiche getrennt saugen lassen muss (alles andere ist ja bereits während des Wischvorgangs gesaugt worden). Das bedeutet, dass man jeden Teppich einzeln benutzerdefiniert auswählen müsste und für jeden Teppich eine eigene Fahrt anstoßen muss. Das ist viel Aufwand, weshalb man wohl eher die Räume mit Teppichen nochmal komplett befahren lässt (dann wohl vor dem Wischen) - was aber eigentlich unnötig ist, doppelt soviel Zeit und doppelt so viel Materialverschleiß bedeutet.

    Deshalb der Vorschlag, einen Reinigungslauf als "nur Teppiche" definieren zu können. Dann würde man erst alles wischen, dann alle Teppiche auf einen Schlag saugen lassen können (oder umgekehrt) und hätte nichts doppelt befahren müssen.


    Vielleicht gibt's aber natürlich auch einen anderen Grund, weshalb das in der Liste fehlt...

    Eine Absaugstation ist auch tatsächlich etwas, was ein Großteil der O950-Besitzer gerne hätte (aber auch diese wäre in der jetzigen Abstimmung fehl am Platz).

    Im Gegensatz zu einer Funktion, welche die Datenbasis analysiert, um Stuhlbeine zu erkennen....

    Von dem programmiertechnischen Aufwand mal ganz abgesehen.


    Ich glaube, du verstehst was ich meine, oder?

    Der programmiertechnische Aufwand, zusammenhängende Objekte zu erkennen, ist jedenfalls geringer als der, den du betreibst, um den Abstimmungsthread zu lesen. Sowas ist extrem simpel zu programmieren, und genau genommen braucht mans nicht mal zu programmieren, denn für Mustererkennung gibt's fertige Software.

    Das ist eben wieder ein Punkt, wo deine Entscheidung einzig auf deinem persönlichen Kenntnisstand zu Software und zu möglichen Implementierungs-Ansätzen basiert. Produkte die begeistern oder die einen wirklichen Fortschritt darstellen, entstehen auf diesem Weg nicht, die entstehen, wenn man eine fortschrittliche Funktionalität definiert und deren Umsetzung dann von Experten diskutieren lässt.


    Aber ich verstehe natürlich, was du meinst. Und selbstverständlich ist es richtig, dass es für die meisten Nutzer sicher interessanteres gibt als "automatisches Erkennen von Stühlen, Schwingstühle/sesseln", selbst wenn es sowas wie "den Bereichen Klarnamen geben" ist, was keinerlei Nutzen für die Kernfunktionalität eines solchen Roboters bedeutet.


    Werd ab und zu mal schauen, was aus der Liste so wird. Dass da "1000 Wünsche" zusammen kommen, ist ja eh nicht zu erwarten. Und wenn von der finalen Liste auch nur ein Punkt wirklich umgesetzt wird, weil dieses Forum das bei Ecovacs einkippte, dann wärs ja schon ein Erfolg.

    Wenn du sehen möchtest, was ausgewählt wurde, dann schau im Eingangsposting ganz unten (unter angenommene Vorschläge)

    hab ich grad' mal wieder gemacht.

    Du hast Punkt 12 falsch übernommen (von "diagonal" war keine Rede), und Punkt 1 ist eine Untermenge von Punkt 12, sprich: die beiden sollten m.E. zusammengefasst werden, denn es geht in beiden darum, wie der Roboter seine Bahnen anlegen soll (horizontal, vertikal, "an der Wand ausgerichtet" (meint wohl die erste Randfahrt?) oder per zufall). Falls du "Diagonal" wirklich für sinnvoll hältst, wieso nicht, wäre dann eine fünfte Option.

    Wenn du sehen möchtest, was ausgewählt wurde, dann schau im Eingangsposting ganz unten (unter angenommene Vorschläge)

    wie gesagt, da sehe ich die, die du zu einem bestimmten Zeitpunkt ausgewählt hast. Weder weiss ich so welche du noch überhaupt nicht betrachtet hast, noch welche du herausgefiltert hast.

    Dass man bzgl Umsetzbarkeit/Sinnhaftigkeit von Vorschlägen deutlich unterschiedlicher Ansicht sein kann, das siehst du ja allein schon an den zwei Punktien, die wir hier grad kurz angesehen haben. Und wg Machbarkeit ("zu teuer"): Das sollte natürlich eine Entscheidung von Ecovacs sein, nicht von dir, finde ich. Erstens wissen wir nicht, wie teuer irgendetwas Ecovacs käme und zweitens wissen wir nicht, welchen Benefit sich Ecovacs von Funktionalität x versprechen wird. Denn darauf kommt es an, nicht ob's vielleicht teuer ist, sondern ob Ecovacs das Kosten/Nutzen-Verhältnis für akzeptabel hält.

    zB eine Absaugstation zu bauen ist sicher teurer als das Bewegungsmuster zum Türöffnen zu implementieren, trotzdem gibt es Hersteller, die das teure tun und über das günstigere noch nachdenken.

    Als Beispiel hier: Türen erkennen um diese um X Grad zu öffnen => Würde eine Kamera voraussetzen, welche der O950 nicht besitzt.

    auch das ist nicht korrekt.

    Türen lassen sich rein aus den gesammelten Kartenbeständen heraus erkennen. Dazu braucht es keine Änderung am Roboter.

    Das kannst du ja auch ganz einfach testen, in dem du dir hier im Forum Karten anderer Nutzer anschaust - du als Mensch wirst selbst anhand einer einzigen Karte mit hoher Sicherheit sagen können, wo eine Tür ist und wo nicht, welche Drehrichtung sie hat usw. Und das kann die Software ebenso, sogar mit höherer Sicherheit, weil sie viel mehr Karten anschauen kann.

    Löschen heißt normalerweise nicht automatisch, dass es dauerhaft sein soll (Man könnte es sich ja auch nochmal anders überlegen...)

    Vorallem, was ist, wenn ich ausversehen etwas falsches lösche?

    Nach deiner Logik hab ich dann dort, wo eigentlich WZ ist, für immer und ewig ein riesengroßes Loch....

    auch das ist eine simple Softwarelogik. Wenn Bereiche (wie oben erwähnt) beispielsweise als "Maske" definiert sind, dann sind sie bekannt, könnten jederzeit aufgelistet und reaktiviert werden. Sprich:nichts wäre "für immer" und der Nutzer hätte die Kontrolle.


    Das sind aber Implementierungsdetails. Gesammelt werden sollten Funktionalitäten, oder?

    Man muss halt aufpassen, dass man Funktionalitäten nicht aussortiert, bloß weil man sich nicht vorstellen kann, wie sie (rein über Software) implementiert werden könnten. Darum kümmern sich ja nachher die Experten.

    Hier kommen wir aber eher in den Bereich des Kartenbackups bzw, des Ablehnens einer Kartenänderung.

    (Thema war "löschen", insbes. bzgl Phantombereichen)

    ich weiss nicht, inwiefern das etwas mit Kartenbackup oder Ablehnen einer Kartenänderung zu tun hat. Das sind andere Funktionen, die profitieren können davon, dass eine Karte vom Nutzer "sauber" gemacht wurde.

    Mal tief durchatmen!!! Eine Vorauswahl muss hier erfolgen und bisher finde ich die von Catraxx durchgeführte Vorauswahl sehr wohl für nachvollziehbar.

    Mir ist die Vorauswahl nicht bekannt, sie ändert sich ja auch über die Zeit. Mit "Durchatmen" (erst recht mit solchem mit drei Ausrufezeichen) hat das nichts zu tun. Es ist eine ganz einfache Frage und deren Beantwortung sorgt dafür, dass man nicht nur sieht, was ausgewählt wurde, sondern auch, was nicht (und weshalb nicht), und was bislang noch gar nicht betrachtet wurde.