Turboloch ! N1S verschluckt sich beim Beschleunigen !

[MEroller]

rollerus, es tut mir leid, aber ich arbeite nicht für Bosch noch habe ich einen Bosch controller (nur Kellys, Lingbo/Goldenmotors und MQCON/Sabvoton), so dass ich nicht exakt technisch begründen kann, was bei der Applikation im Falle der 2018er Niu N1 schief gelaufen ist.

Ich weiß, nur, dass diese Fehlfunktion nicht zwingend ist, denn weder die 2017er Nius noch die neuen Unus - alle mit Bosch Controller - hatten bzw. haben sie. D.h. Begründungen, dass die vielen Gedenksekunden der Vektorsteuerung oder gar einem Feature zuzuschreiben sind sind weder glaubwürdig noch wahrscheinlich.

Wenn Du mir noch kurz den entscheidenden Hinweis auf den von mir verwendeten totschlag-Fachbegriff geben könntest ist es mir vielleicht möglich, diesen näher zu erläutern

[chrispiac]

Bei meinem 2017er NIU trat es vor dem Akkuwechsel (und den wahrscheinlich damit verbundenen Firmwareupdate) deutlicher hervor. Ich empfinde es auch nicht als „Turboloch“ sondern als angepasstes Fahrverhalten. Bei einem Verbrenner nehme ich in vergleichbarer Lage ja auch nicht das Gas ganz weg, wenn ich absehbar wieder beschleunigen möchte, weil ich zum Beschleunigen erst wieder auf eine höhere Motordrehzahl kommen muß und dazu ist dieses Verhalten eigentlich Simultan. Es weicht eher von einem Verhalten ab, das man sich am Elektroroller angewöhnt hat, gerade als Kleinkraftrad, wo es ja fast nur 3 Zustände zu geben scheint: „Vollgas“, Rollen lassen - also ohne Gas und Bremsen. Da ist etwas weniger Gas geben (statt ohne Gas einach rollen lassen) um schneller wieder zu beschleunigen eher ungewohnt. Dieses Verhalten könnte beim 2018er NIU stärker ausgeprägt sein, ich konnte mich bei meinem 2017er daran gewöhnen/darauf einstellen und es tritt wirklich nur über 35 km/h auf, da wirken viele der vorgebrachten Situationen, wo dieses Verhalten schädlich sein könnte, eher konstruiert. Schließlich ist da nicht mehr viel Geschwindigkeitszuwachs „drin“ wenn spätestens bei 47 bis 50 km/h auf dem Tacho abgeregelt wird.

[Eule]

Chris, wenn es den berühmten Spruch "It´s not a bug, it´s a feature" nicht schon gäbe, er könnte von dir stammen, gell?

Aber mal im Ernst, ich würde mich auch ärgern über dieses "feature", z.B. beim Heranrollen auf eine stehende oder gerade anfahrende Kolonne. Man dreht den Stromhahn zu, der Vordermann beschleunigt zügiger als erwartet, du gibst wieder Strom um dran zu bleiben und es passiert....nichts.

Sicher, da kann man mit leben, aber es ist halt auch Kacke

[sunnyville]

Vielleicht gibt es irgendwann ein Firmware Update dazu? Müsste sich doch leicht beheben lassen.

[Hrodgar]

Warum macht man solch eine "Verzögerungsautomatik"?

Aus meiner Sicht ein Versuch einer Erklärung:

Ich habe einen Motor, einen Akku und eine Endstufe mit ihren Schalttransistoren. All das hat jeweils einen Innenwiderstand. Beim Akku der "Ri", beim Motor der Wicklungswiderstand und beim Transistor der "Rds_on".
Wenn ich die Stellung des Gasgriffs jetzt direkt in eine neue Drehzahlanforderung umsetze, dann wird jeder kleinste Zuck (Beispielsweie durch Fahrbahnunebenheiten, deren Rucken irgendwann am Arm und dann an der Gashand ankommen) sofort in andere Drehzahlanforderungen umgesetzt und soit in starke Stromschwankungen. Letztere allerdings ohne großen Effekt. Nachdem aber die Verlusstleistung quadratisch zum Strom verläuft, das Beschleunigungsmoment aber nur Linear, wird durch dieses Ruckeln Energie verschwendet, also Reichweite geopfert.
Es gilt: P=I²xR, also Verlusstleistung = Strom² x Widerstand; Widerstand = Innenwiderstand vom Akku + Rds_on + Wicklungswiderstand;

Das ähnliche gilt übrigens für Verbrenner und den Spritverbrauch, weswegen das "elektronische Gaspedal" heute im Auto normal ist.

So, wie gehe ich jetzt damit um?
Das beste ist, zu wissen, was der Fahrer will. Klar. Aber ich habe nur die Daten vom Gasdrehgriff. Also analysiere ich die. Dafür kann ich verschiedene Algorithmen nutzen, die unterschiedlich Rechenleistung brauchen. Der einfachste ist, ich glätte über der Zeit. Das ist sehr einfach, sparsam, schnell zu machen, geringer Aufwand beim Verifizieren. Aber eben mit "Turboloch".

Will ich das nicht haben und auch keine anderen Algorithmen programmieren (z.B. weil mein Prozessor es nicht leisten kann oder ich als Jungingenieur in einem Startup es nicht besser weiß.), dann nehme ich das raus und - schwupps - kann meine Reichweitenzusagen nicht halten.

Dieses seltsame Verhalten war mir übrigens bei meiner Probefahrt mit dem Niu aufgefallen und auch als sehr gefährlich vorgekommen. Ich hatte das Gefühl, mich nicht auf das Gerät verlassen zu können. Und das ist in Frankfurt im Innenstadtverkehr ein seeeeehr blödes Gefühl.

Wie gesagt: Ein Versuch einer Erklärung. Etwas spekulativ, aber ich möchte nur aufzeigen, daß es durchaus schlüssige Gedanken gibt, die zu diesem Verhalten führen.

[chrispiac]

Chris, wenn es den berühmten Spruch "It´s not a bug, it´s a feature" nicht schon gäbe, er könnte von dir stammen, gell?

Bin halt mit Apple Rechnern aufgewachsen - soweit ich weiß, kommt da dieser Spruch her.

Aber mal im Ernst, ich würde mich auch ärgern über dieses "feature", z.B. beim Heranrollen auf eine stehende oder gerade anfahrende Kolonne. Man dreht den Stromhahn zu, der Vordermann beschleunigt zügiger als erwartet, du gibst wieder Strom um dran zu bleiben und es passiert....nichts.

Sicher, da kann man mit leben, aber es ist halt auch Kacke

Ich vermute halt, das dieses Verhalten eine „Anbiederung“ an Umsteiger von Verbrennern sein könnte. Da ich halt lernfähig bin, weiß ich halt, das ich in so einer Situation halt nicht den Beschleunigungsgriff einfach loslassen darf, sondern ihn nur etwas zurücknehmen sollte. Schön ist natürlich anders, da ich es mir auch gerne einfach mache. Solange aber NIU nicht unterschiedliche Programmierungen für unterschiedliche Kundenwünsche anbietet, kann man entweder lernen damit umzugehen oder sich bei NIU und Händlern darüber beschweren, mit der Hoffnung, das sie die Programmierung anpassen. Sollte es beim 2018er NIU tatsächlich noch längere Reaktionszeiten geben, würde ich mich wahrscheinlich auch beschweren. Mit um/max. 1 Sekunde bei meinem 2017er Modell ist es halt spürbar aber nicht weit überhalb der üblichen Reaktionszeit.

Wie gesagt: Ein Versuch einer Erklärung. Etwas spekulativ, aber ich möchte nur aufzeigen, daß es durchaus schlüssige Gedanken gibt, die zu diesem Verhalten führen.

Das ist ja das Merkmal der Feldorientierten Steuerung (FOC) gegenüber herkömmlicher Sinuscontroller. Der Sinuscortroller ist im Verhalten direkter. Die FOC versucht mehr, das Verhalten des Fahrers vorherzusehen. Wenn man die Beschleunigung komplett wegnimmt, geht er halt eher von einem folgenden Bremsvorgang aus, als von einer erneuten Beschleunigung von der vorhandenen Geschwindigkeit aus. Wenn die Erfahrung von NIU lautet, das bei so einer Vorgabe eher gebremst wird, als beschleunigt, werden sie die Firmware entsprechend ausgelegt haben. Daher hilft, den Beschleunigungsgriff nicht ganz loszulassen, um so der FOC klarzumachen, das eine erneute Beschleunigung folgen könnte. Sollte aber wirklich wie Threadstarter rollerus schreibt, beim 2018er NIU 4 bis 5 Sekunden vergehen, ist das deutlich zu viel. Schon bei der Häfte dieser Reaktionszeit, würde ich auch dagegen protestieren.

[Patrick]

mal ne genellere Frage, hat das jeder Niu oder nur der N1S? bei anderen Rollern die ich schon fahren konnte ist mir das nicht aufgefallen.

[chrispiac]

Es scheint im Wesentlichen das 2018er Modell vom NIU N1S betroffen zu sein. Es scheint auch von der jeweiligen Firmware Version abzuhängen.

[Hrodgar]

Das ist ja das Merkmal der Feldorientierten Steuerung (FOC) gegenüber herkömmlicher Sinuscontroller. Der Sinuscortroller ist im Verhalten direkter. Die FOC versucht mehr, das Verhalten des Fahrers vorherzusehen. Wenn man die Beschleunigung komplett wegnimmt, geht er halt eher von einem folgenden Bremsvorgang aus, als von einer erneuten Beschleunigung von der vorhandenen Geschwindigkeit aus.

Es würde ausreichen, die erste Ableitung der Drehgriffstellung nach der Zeit im Datensatz mitzuführen und mit einem Grenzwert auszustatten, der mit einem Grenzwert der Amplitude der Bewegung kombiniert wird.
Ein Bremscontroller im Auto erkennt ja auch eine Notbremsung, wenn unmittelbar zuvor voll auf das Gas getreten oder die Bremse ruckartig gelöst wurde.

Man muß das nur wollen und etwas Rechenkraft bereithalten. Solche Regelungen habe ich schon in den Neunzigern auf nem 8-Bit-Controller geschrieben. Aber die mussten auch nicht ständig meine Standortdaten nach China funken.

[kabee]

Ich bin mir nicht sicher ob es für die Umsetzung deiner Lösung erforderlich ist, dass ein Beschleunigungssensor verbaut ist. Diesen hat der NIU nicht und ich bin mir auch nicht sicher, ob die verbaute ECU ein solches Signal überhaupt verarbeiten und an den FOC weiterleiten könnte.

Aber immerhin kann er mit der neuen Software jetzt noch zuverlässiger und in kürzeren Intervallen seinen Standort nach China senden. Sieht man schön in der App, die Kurven der aufgezeichneten Wegstrecken sind wesentlich runder.