Open Source Firmware für Lishui Controller

Diskutiere Open Source Firmware für Lishui Controller im Controller/Regler, Fahrerinformation, Elektronik Forum im Bereich Diskussionen; Ich habe die beiden Profile verglichen : GCC Assembler => Debugging : Debug level = none GCC Compiler => Debugging : Debug level = none =>...

skwad

Dabei seit
23.10.2019
Beiträge
37
Jetzt komme ich grad wieder an meine Grenzen, was den Compiler angeht. Wenn ich als Release compilieren will, um keine platzraubenden Debug-Informationen mitzuschleppen, gibt es nur Fehlermeldungen :rolleyes:. Er scheint da irgendwelche includes nicht mitzunehmen...
Ich habe die beiden Profile verglichen :
GCC Assembler
=> Debugging : Debug level = none

GCC Compiler
=> Debugging : Debug level = none
=> Preprocessor : ARM_MATH_CM3 hinzufügen, wie bei Debug
=> Include paths : "${CMSIS_LOC}/Include" hinzufügen, wie bei Debug
=> Optimization : Optimize for size (-Os)

GCC Linker
=> Libraries
=> Libraries : arm_cortexM3l_math hinzufügen, wie bei Debug
=> Library search path : "${workspace_loc:/${ProjName}/Drivers/CMSIS}" und "C:\CMSIS_5-develop\CMSIS_5-develop\CMSIS\Lib\GCC", auch wie bei Debug

Dann kriegst du die Fehler nicht mehr.

edit: habe gerade volatile auf ui8_adc_regular_flag gesetzt und es scheint schön zu laufen (mit debug display), auf einen bischen älteren master commit (ca9d47cc7d7c0c02b265d1afc5c80bcb065a7705)
 
Zuletzt bearbeitet:

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Dann kriegst du die Fehler nicht mehr
Danke! Leider verändert sich die Größe nicht, egal ob man mit debug oder mit release-Einstellung compiliert :-(

Ich habe jetzt alle floats rausgeschmissen und durch Ganzzahlen und Shifts ersetzt. Die Faktoren für den Regler müssen jetzt natürlich viel größer sein, da ich in der Regelschleife jetzt mit einem rightshift 10 arbeite, um die Zahlen in einen sinnvollen Wertebereich zu bekommen. Im Plot sehe ich auch, daß der P-Faktor viel zu klein ist, er hat fast keine Wirkung. Weiterhin sieht man, daß die Regler-Parameter nicht gut für die Batteriestromregelung passen, des System schwingt. Da muß ich die Batteriestrom-Werte noch besser in den Zahlenbereich der ADC-Werte der Phasenstromregelung skalieren.
Der Plot zeigt einen Versuch auf dem Rollentrainer mit 10 Ampere Batteriestrombegrenzung und mäßiger Last. Man sieht, das die BEMF mit der Geschwindigkeit so hoch wird, daß die Spannung nicht mehr reicht, um den gewünschten Strom in den Motor zu bekommen...

Gruß
hochsitzcola

1610559758671.png
 
Zuletzt bearbeitet:

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Steuerst du die Spannung nicht vor?
Nein, ich lass das einfach vom I-Anteil ausregeln, sprunghafte Änderungen haben wir ja bei einem Pedelec nicht, da reicht die Geschwindigkeit der Regelung so locker...

ich hab die Regler-Parameter und die Skalierung vom Batteriestrom noch mal angepasst, jetzt sieht es schon besser aus. Allerdings zappelt jetzt der P-Anteil beim "Austrudeln" ziemlich rum, optimal ist das noch nicht :oops:

Gruß
hochsitzcola

1610564582199.png

1610564618838.png
 
Zuletzt bearbeitet:

reinosmart

Dabei seit
29.04.2017
Beiträge
499
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
Habe gerade den ersten schmutzigen Aufbau zusammengesteckt. Leider war das Anfahrmoment genauso bescheiden wie beim BMT, da ist beim Kunteng deutlich mehr los 🥴 .
Musste leider auf 3 Lipos aus dem Modellflieger zurückgreifen, da meine anderen Akkus fest verbaut sind. Das reicht auch für ein paar km, nur Reku sollte man sich da eher verkneifen.
 

Anhänge

  • Aufbau 140121.jpg
    Aufbau 140121.jpg
    126,2 KB · Aufrufe: 8

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
da ist beim Kunteng deutlich mehr los
Bitte Äpfel mit Äpfeln vergleichen. Was hast du denn beim Kunteng für Motor- und Batteriestrom-Limits eingestellt? Wenn du die beim Lishui genauso einstellst, kommt auch das Gleiche, dem Motor ist doch egal, wer den Strom anschubst ;-) Beim BMT haben wir ja keinen Einfluß, wie der Controller den Strom hochrampt, hier schon!

Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
499
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
Hab jetzt mal den max. Motorstrom von 300 auf 500 erhöht. Während vorher der max. Batteriestrom bei blockiertem Rad nur ca. 1.5 A betrug, steigt er jetzt auf ca. 6 A an. Von Proportionalität keine Spur. Wenn ich jetzt neben dem Rad stehe und den Lenker festhalte, geht die Kiste vorne hoch, so kenne ich das.
Allerdings bricht bei gebremsten Rad das Moment etwa im Sekundenrhythmus zusammen und steigt dann wieder an??
Beim Kunteng habe ich immer Batteriestrom 10A, Phasentrom 15A.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Allerdings bricht bei gebremsten Rad das Moment etwa im Sekundenrhythmus zusammen und steigt dann wieder an??
Wenn das Rad blockiert ist, schaltet die PWM nach einer Sekunde ab. Das ist ja das Feature, da ich eingebaut habe, um das Zappeln im Stand zu vermeiden.

Von Proportionalität keine Spur.
Das muß ja auch nicht proportional sein. Das ist ja eine Verschaltung von Induktivitäten und Kapazitäten angeregt von einer Rechteckspannung :eek: Jemand mit Ahnung von der Materie könnte das bestimmt berechnen :unsure: Oder eine LT-Spice-Simulation davon machen :). Mein Halbwissen reicht da auf jeden Fall nicht aus...

Gruß
hochsitzcola
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Ich überlege gerade für den Torquesensormodus ein Unterstützungsprofil einzubauen, wie man es vom Bosch Nyon kennt. Also kein fester Wert für TS coefficient, sondern ein Profil, abhängig von der Geschwindigkeit. Vom Code her sollte das überschaubar sein.



Dieses Beispielprofil sollte doch für ein S-Pedelec geeignet sein. Bei niedriger Geschwindigkeit wenig "Verstärkung", damit man noch feinfühlig mit den Beinen "Gas geben" kann, im hohen Geschwindigkeitsbereich mehr Verstärkung, damit man genug Leistung vom Motor bekommt, ohne selber ständig 250W treten zu müssen...

Hat jemand Erfahrung mit solchen Setups?

Gruß
hochsitzcola
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
das hieße auch am Berg wenig Unterstützung?
das ist ja grad die Idee dieser individuellen Fahrmodi, daß man je nach Streckenprofil unterschiedliche Kennlinien einstellen kann. Zum Mountainbiken wird ja dieses Profil vorgeschlagen:



Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
499
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
Ich kann mir nicht helfen, aber die Fahrgeschwindigkeit als Parameter für den Unterstützungsgrad halte ich für untauglich. Warum willst du den Ansatz p-motor=k * p-mensch verlassen. Das ist doch das Maß aller Dinge. Evtl. könnte man hier den linearen Ansatz etwas verlassen und den individuell gestalten, ich persönlich würde mir hier eine leichte Progression wünschen.
daß man je nach Streckenprofil unterschiedliche Kennlinien einstellen kann
das wäre mir einfach zu viel Gefummel.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Ich überlege gerade für den Torquesensormodus ein Unterstützungsprofil einzubauen
Einen ersten Entwurf habe ich jetzt gemacht, das Profil ist allerdings erst mal noch hardgecodet.

Code:
const uint8_t assist_profile[2][6]= {    {0,10,20,30,45,48},
                                        {64,64,128,200,255,0}};

daraus wird mit der Map-Funktion der geschwindigkeitsabhänigige Speedfaktor berechnet.

Code:
ui8_speedfactor = map(uint32_tics_filtered>>3,speed_to_tics(assist_profile[0][ui8_speedcase+1]),speed_to_tics(assist_profile[0][ui8_speedcase]),assist_profile[1][ui8_speedcase+1],assist_profile[1][ui8_speedcase]);

Das aus der Eigenleistung berechente current_target wird dann mit dem Speedfaktor skaliert.

Code:
int32_current_target = (int32_current_target * ui8_speedfactor)>>8;

Zu beachten ist, daß, wie bei den Stufen vom Display, immer nur reduziert werden kann, die Grundverstärkung wird über TS coefficient eingestellt und über den Speedfaktor und die Stufe vom Display wird runterskaliert.

Die geloggten Werte zum Speedfaktor sehen jetzt so aus:

1610718397495.png


Die Nichtlinearität kommt aus der integerbasierten Map-Funktion, ich denke aber, das wird beim Fahren nicht auffallen.

Warum willst du den Ansatz p-motor=k * p-mensch verlassen
Wie oben schon geschrieben. Für ein S-Pedelec ist dieser direkte Zusammenhang nicht tauglich, da du bei langsamer Geschwindigkeit immer gleich viel zu viel Gas geben würdest und so die Geschwindigkeit zum Beispiel beim Fahren in einer Gruppe mit Pedelecs oder Biobikern nicht fein genug nur mit den Beinen steuern könntest. Zumindest, wenn du die Grundverstärkung so hoch drehst, daß du die 45 km/h noch mit bequemen 100W Eigenleistung erreichen kannst.

Es zwingt dich ja keiner, ein Profil zu nutzen, du kannst ja alle Faktoren auf den gleichen Wert setzen.
Durch die Vermeidung von floats ist jetzt auf jeden Fall noch genug Speicher da, um verschiedene Profile zu hinterlegen und auch noch die Batteriestrombegrenzung bei Reku einzubauen :)

1610719044291.png


Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
499
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
ich hätte nochmal eine Frage zur Mittelwertbildung des torque Signales. Es kann im Konfigurator ja nicht die Anzahl der PAS Impulse angegeben werden. Ist ja auch nicht nötig, da du ja nicht wirklich über eine Kurbelumdrehung mittels, sondern nur ein gleitendes Mittel bildest. Über 32 Werte, obwohl der T9/13 36 Pulse erzeugt. Beim Kunteng Projekt wurde ja richtig über eine Umdrehung gemittelt

Code:
ui16_sum_torque = 0;
        for (ui8_temp = 0; ui8_temp < NUMBER_OF_PAS_MAGS; ui8_temp++) { // sum up array content
            ui16_sum_torque += ui16_torque[ui8_temp];
        }
        ui16_sum_torque /= NUMBER_OF_PAS_MAGS

das ist natürlich viel besser, da keine Restwelligkeit mehr übrig bleibt. Ich denke, da sollte man nochmal nachjustieren.
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
67
Mein neuer ST-Link ist endlich angekommen 🥳
Ich hab grade den aktuellen Master Branch runtergeladen und mal mit meinen bisherigen Einstellungen getestet. jetzt funktioniert quasi garnichts mehr. Bisher hab ich nur kurz getestet was mit der Schiebeunterstützung passiert. DIe spricht wesentlich langsamer an als bisher, der Motor ist lauter als vorher (immerhin ist der Ton angenehmer da tiefer), das Rad dreht sich geschätzt mit Schrittgeschwindigkeit während das Display 50km/h zeigt und es hört auch erst wieder auf wenn man das Display abschaltet.
Da habe ich nur noch die Idee, daß die Hallsignale bei dir nicht sauber alle 60° kommen, die Hallsensoren im Motor also ungenau eingeklebt sind.
Ich habe mal beim Autodetect den Winkel zu den Hallstates mit ausgeben lassen. Bei meinem IGH3 streut das um maximal 3°, kannst du das bei dir mal prüfen?
Immerhin konnte ich deinen Vorschlag mal prüfen. Dabei kam folgendes raus:
Code:
[22:17:22:079] phase current offsets:  2002, 1990, 1997
[22:17:22:086]  angle: -180, hallstate:  4, hallcase 4
[22:17:22:308] angle: -146, hallstate:  5, hallcase 45
[22:17:22:680] angle: -85, hallstate:  1, hallcase 51
[22:17:23:046] angle: -25, hallstate:  3, hallcase 13
[22:17:23:400] angle: 33, hallstate:  2, hallcase 32
[22:17:23:766] angle: 93, hallstate:  6, hallcase 26
[22:17:24:137] angle: 154, hallstate:  4, hallcase 64
[22:17:24:503] angle: -146, hallstate:  5, hallcase 45
[22:17:24:875] angle: -85, hallstate:  1, hallcase 51
[22:17:25:229] angle: -27, hallstate:  3, hallcase 13
[22:17:25:601] angle: 34, hallstate:  2, hallcase 32
[22:17:25:966] angle: 94, hallstate:  6, hallcase 26
[22:17:26:338] angle: 155, hallstate:  4, hallcase 64
[22:17:26:697] angle: -146, hallstate:  5, hallcase 45
[22:17:27:064] angle: -86, hallstate:  1, hallcase 51
[22:17:27:424] angle: -27, hallstate:  3, hallcase 13
[22:17:27:790] angle: 33, hallstate:  2, hallcase 32
[22:17:28:167] angle: 95, hallstate:  6, hallcase 26
[22:17:28:527] angle: 154, hallstate:  4, hallcase 64
[22:17:28:683] Motor specific angle:  -1741847578, direction 1
[22:17:28:692]  Lishui FOC v0.9
[22:17:28:702]  Motor specific angle:  -1741847578, direction 1
[22:17:28:711]  1668, 0, 0, 2064, 7, -6516, -261
[22:17:28:871] 1668, 0, 0, 2060, 7, -6516, -261
Der spec_angle hat sich scheinbar auch geändert. Kann es sein dass sich was an den Werten in der config.h geändert hat wegen der Umstellung auf Ganzzahlenberechnung?
 
Zuletzt bearbeitet:

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Kann es sein dass sich was an den Werten in der config.h geändert hat wegen der Umstellung auf Ganzzahlenberechnung?
Die Faktoren für den Regler müssen jetzt natürlich viel größer sein,
Poste bitte mal den Inhalt deiner config.h!

das ist natürlich viel besser, da keine Restwelligkeit mehr übrig bleibt. Ich denke, da sollte man nochmal nachjustieren.
Implementiere und teste das doch bitte, wenn es deutlich besser funktioniert, als die bisherige Lösung stelle einen Pull Request!

Gruß
hochsitzcola
 

Millimeter94

Dabei seit
13.07.2020
Beiträge
67
Das hier ist die Version von gestern abend
 

Anhänge

  • config.txt
    1,9 KB · Aufrufe: 5

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
Das hier ist die Version von gestern abend
Du hast den Torquesensor aktiv, ist das Absicht?

Ich habe den aktuellen Stand heute mal auf der Straße probiert, du hast recht, der Motor läuft rauh, da muß ich noch mal dran. Das kann man auf dem Rollentrainer nicht wirklich gut beurteilen.
Der Winkel ist jetzt leicht anders, da ich den Strom Ud bei der Autodetectroutine erhöht habe. Mal schauen, vielleicht hat das schon so großen Einfluß. Mit dem kleineren Strom hat mir der Wert vom motorspezifischen Winkel beim eingespeichten Rad aber zu sehr gestreut, bei 10 mal einschalten sind fast 20° Streuung drin gewesen, wenn ich mich recht erinnere. Vielleicht macht es Sinn, auf den Wert vom höheren Strom einfach einen Offset draufzurechnen.


könnte man denn nicht die Open Source Firmware vom Lishui auf den Controller vom Segway Ninebot G30 porten?
Es ist jetzt tatsächlich jemand auf diesen Zug aufgesprungen und hat einen Port der EBiCS Firmware für den Xiaomi M365 Roller gebaut. Erste Probefahrt war erfolgreich. Die Controller kriegt man für 30€ an jeder Straßenecke und sie lassen sich wohl auf 72V/100A pimpen. Manko ist, daß man ihn eigentlich nur über UART steuern kann, da keine Prozessorpins für irgendwelche Sensoren auf leicht zugängliche Steckkontakte gelegt sind. Da braucht man auf jeden Fall einen "Precontroller". Mich wundert, daß sich in der Rollerszene so viele Hacker tummeln, da gibt es zig Projekte. Zum Beispiel ein Parallelprojekt auf Basis der STM MotorController Workbench, der erzeugte Code ist nur viel zu groß für die 32kB, die wir beim Lishui haben....
Hier in der Pedelec-Szene ist die Anzahl der Interessierten doch eher gering.:unsure:


Gruß
hochsitzcola
 
Thema:

Open Source Firmware für Lishui Controller

Open Source Firmware für Lishui Controller - Ähnliche Themen

Offene Firmware für viele "Discounter-Räder" (Fischer, Prophete, NCM, ....) mit Lishui FOC Controller: Die Firmware hatte ich schon in verschiedenen Threads angesprochen. Ich habe ihr jetzt noch eine nutzerfreundliche grafische Benutzeroberfläche...
Oben