[News] EDuWaFa - Energie Durch WAsserFAll (high pressure)

OSEG Projekte Projektinkubator ("PROTO")
1

– Wiki –

Repository


Alles unterhalb kann Diskussion oder veraltete Information sein.



Energiegewinnung Wasser - Übersicht:

Energie durch Wasserbewegung oder korrekter durch Impuls (=momentum in English) (EDUWASI)

  1. vertikal:
  • EDuWaFa (WAterFAll - Wasserkraftwerk mit hoher Fallhöhe/Druck, geringem Volumen, hoher Geschwindigkeit)
  • EDuWaMa (WAterMAsses - Wasserkraftwerk mit hohem Volumen, geringer Fallhöhe, niedriger Geschwindigkeit)
  1. horizontal (keine direkte Gravitationskomponente, indirekt schon, da die Schwerkraft einen Strom abwärts treibt und Gezeiten antreibt):
  • EDuWaFl (WAterFLow - Wasserrad z.B. HydroCat, wenn dann schon mobil)
  • EDuWaTi (WAterTIdes - Gezeitenkraftwerk)
  1. kreisförmig:
  • EDuWaTu (-"- WAterTUrbulencies / Wasserturbulenzen)
  • EDuWaRo (-"- WAterROtation / Wasserrotation)

Gibt es neben horizontal planar, vertical planar und circular (Vortex, Wirbel) weitere Typen?


Leitspruch:
Entwicklungsentscheidungen lassen oft bitteren Streit in Open-Source-Projekten entflammen (siehe z.B. KiCAD), deshalb schon hier ein Leitspruch, nach dem sich alle Entscheidungen richten:
For the goals we bake, the best and simplest solutions we take.
Hinweis: Da Einfachheit in den meisten Fällen niedrige Kosten impliziert, wird dies nicht explizit erwähnt. Durch die Verwendung des Plurals wird zudem impliziert, dass wir nicht an einer einzigen Lösung festhalten und offen für mehrere Lösungen in verschiedenen Projektzweigen sind. Alles wird unter einem Versionsverwaltungssystem gehalten. Gemeinsame Dateien werden wünschenswerterweise in den Ordner der höchsten Ebene gelegt, der noch unter Versionsverwaltung steht. (Es gibt also keinen extra ‚common‘-Ordner - stattdessen ist die höchste Projektebene automatisch für alle Zweige gemeinsam, ohne sie irgendwo benennen zu müssen.)

Um der Gleichheit willen könnten wir sogar das Wort ‚branch‘ (Zweig) aufgeben und sogar auf ‚trunk‘ (Hauptstrang) verzichten und einfach Kategorienamen verwenden. z.B. unter Verwendung des Musters $PROJECT_DIRECTORY/<ordering_using_three_digits*_if_desired>--<how_it_s_done1>/<ordering_3digits*>--<how_it_s_done>/
*3 Ziffern, da es so jederzeit einfach ist, einen weiteren Eintrag/ein weiteres Modul zwischen zwei anderen Modulen einzufügen.
Es gibt zwei Möglichkeiten:

  1. Jeder Ordner auf der höchsten Ebene der Projektdateistruktur ist ein individueller ‚Branch‘ (daher ein Klon, Checkout des Trunks oder wie auch immer man es nennt). Der Trunk (Hauptversion) ist ebenfalls vorhanden, wird aber nicht Trunk genannt, um nicht den Eindruck zu erwecken, dass dort alles feststeht und die anderen Branches nicht.
    ODER
  2. Wir haben nur zwei Repositories:
  • final/trunk, wo es keinen -How:<how_it’s_done>/ Zusatz zu den Ordnernamen gibt.
  • branch, wo sich die gesamte Entwicklung befindet und jeder Ordner separat ausgecheckt und committet werden kann. Bei diesem Ansatz sind Checkout und Änderungen feingranularer, wodurch weniger Overhead entsteht. Ich denke, das ist es nicht wert.
    ODER
  1. Wir haben nur ein Repository und keine Branches. Dort haben wir eine Ordnerstruktur, bei der wir das ‚-How:<how_it’s_done>‘ weglassen, und dies ist die aktuelle Lösung aus der Praxis, die am vielversprechendsten ist. Sie kann als eine Sammlung der anderen Ordner/Ideen angesehen werden, die am einfachsten und dennoch am besten sind und somit unsere Anforderungen erfüllen. Die gewählten Entwicklungsordner werden mittels GNU/UNIX (Linux) symbolischen Links in diese Hauptordner verknüpft.

Der letzte Ansatz ist für mich der vielversprechendste, da die Anpassung einer neuen und einfacheren Lösung, die ein Entwickler gefunden hat, viel einfacher ist, da überhaupt kein Merge involviert ist. Die ausgereiftesten Submodule können einfach in einer wilden Mischung verknüpft werden, solange diese Sub/Module disjunkt sind, was meistens der Fall ist.
Auf diese Weise kann sogar das Review entfallen und jede neue Idee erhält einfach ihren eigenen Ordner, in dem wir notieren, was an dieser Lösung besonders ist (über das How:<how_it’s_done>/ im Ordnernamen).

Um keine riesigen Downloads zu haben, sobald das Repository gefüllt ist, könnten wir jede Art (die verschiedenen „How-it-s-done“) bereitstellen und dann nur lokal und einmal auf dem Server verlinken. Die „beste Lösung“ auf dem Server (die verknüpfte Ordner enthält) muss dennoch nicht verwendet werden, wenn man das nicht möchte. Man kann lokal immer anders verlinken.

Beispiel für Möglichkeit 3 (siehe Liste oben):

  • Energy_Hydro_EDUWAFA/
    / \
  • 010-Power-How:nuclear_and_fuel_cells/
    • 010-Nuclear-How:Cold_fusion/ …
    • 010-Nuclear-How:Hot_fusion/ …
    • 020-Fuel_cell-How:only_using_water_as_electrolyt/ …
    • 020-Fuel_cell-How:I’m_convinced_this_is_simpler/ …
    • 010-Power-How:fuel_cells_only/
      • 010-Fuel_cell-How:air_cathode_choke/ …
    • 015-Gravity_wheel-added_this_inbetween_Power_and_Hull/
      • - noch keine Unterverzeichnisse -
    • 020-Hull-How:I’m_convinced_this_interaction_of_electronics_and_mechanics_is_better/
      • 010-Mechanics-How:using_titanium_micro_meteor_shield/ …
    • 020-Hull-How:but_I’m_convinced_the_mechanics_don’t_need_to_have_those_electronics_hooks_if_we_glue_them_to_the_walls_instead/
      • 010-Mechanics-How:using_titanium_micro_meteor_shield/ …
      • 020-Electronics-How:never_using_bolts_instead_glue_all/ …
      • 020-Electronics-How:good_idea_but_no_I_prefer_keeping_thebolts_and_using_the_glue_additionally/ …

Entwicklungsentscheidungen - Beispiel:
Als Beispiel dafür, wie man zu einer Lösung kommt, für die Frage, ob wir einen Patch mergen oder nicht, betrachten wir, dass wir Folgendes erreichen wollen:
Unsere Batterien dürfen nicht kaputtgehen (z. B. Feuer fangen). Impliziert: Eine angemessen lange Lebensdauer haben.
Dieses Ziel wird im Folgenden austauschbar als Anforderung bezeichnet.

Wir haben uns also für langlebige Batterien entschieden (der aktuelle Stand der Technik ist LiFePO4, das intensiv getestet und vom Militär verwendet wird, und erst kürzlich wurde aufgrund von Airbus-Batterieproblemen ein schlechtes Licht auf die Batterien geworfen).
Wir benötigen Batterien, um die Spitzenenergie Nachfrage zu decken (z. B. Einschalten starker Elektromotoren, bei denen wir viel „unsichtbare“ Energie benötigen). Wenn wir sie weglassen würden, was möglich ist, müssten wir auf Netzstrom umschalten, wann immer ein hoher Energiebedarf erforderlich war. In Fällen, in denen ein Stromnetz verfügbar ist, ist dies eine Option.

Da diese hohen Energiebedarfsspitzen nicht allzu oft auftreten, reicht eine Batterie mit sehr geringer Kapazität aus - als Ausgangspunkt verwenden wir 10 Ah, um 10 A für eine Stunde oder 20 A für eine halbe Stunde (und so weiter) zu liefern. Da wir von Drehstrom sprechen, was normalerweise für Landwirte erforderlich ist (und Open Source Ecology muss Farmen bauen, um jede Art von Nahrung auf ökologische Weise zu beschaffen). Wir sprechen hier also von 700V DC Batterien. Das bedeutet, dass grob 20A * 410V = 8200 W Spitzenleistung für eine halbe Stunde geliefert werden können. Wenn dem Wasserwerk das Wasser ausgeht oder es aus einem anderen Grund ausfällt, reicht diese Zeit natürlich wahrscheinlich nicht aus, um das Wasserkraftwerk zu reparieren, aber der beste Weg, um zu erkennen, dass mit dem Werk etwas nicht stimmt, ist, dass ohnehin kein Strom mehr vorhanden ist (es sei denn, einige kritische Anwendungen laufen, daher geben die 30 Minuten genug Zeit, um entweder einen Notstromgenerator einzusetzen oder die Arbeit zu erledigen oder die kritische elektrische Maschine auf eine sanfte Weise zu beenden, anstatt den harten und plötzlichen Stopp der elektrischen Energieversorgung).

Wie?

  • Batterien dürfen nicht überladen werden.
  • Batterien dürfen nicht vollständig entladen werden.
  • Batterien dürfen nicht unsymmetrisch sein. (Speziell für Lithium-Batterien, andererseits leiden sie nicht unter dem Memory-Effekt wie Nickel-Batterien und haben eine viel längere mittlere Lebensdauer.)
    Um dies nun zu erfüllen, haben wir eine sehr seltsame und unkonventionelle Strategie eingesetzt, und ich weiß, dass sich die Leute darüber beschweren werden. Dennoch werde ich diesen Ansatz testen, weil es die einfachste und dennoch beste Lösung ist, da sie immer noch alle Anforderungen erfüllt, um die Batterien gesund zu halten.

Wenn nun natürlich ein anderer Entwickler einen anderen Vorschlag macht, führt dies sofort und automatisch zur Erstellung eines Branches für die Idee des Entwicklers. Es gibt keine Leute, die die Macht haben, diese Idee zu stoppen, wir haben keine Hierarchien (zumindest für Projekte, die unter meinem Kommando stehen .. ha, lustige Antithetik .. ich meinte diejenigen, an denen ich beteiligt bin).

Sobald die bisher einfachste Lösung fehlschlägt, können wir sofort den Trunk und den nächsten einfachen und vielversprechenden Branch austauschen. Auf diese Weise wird niemand wütend, weil ein Entwickler sich weigert, eine Merge-Erlaubnis im Patch-Merge-Review zu erteilen. Es gibt keine Patches, die das Prinzip ändern, wie Dinge getan werden, es sei denn, sie sind einfacher und erfüllen dennoch die Anforderungen. Dann kommt die aktuelle Lösung in einen neuen Branch und Entwickler, die diesen Ansatz für am vielversprechendsten halten, können ihre Bemühungen fortsetzen, bis sie schließlich durch Vereinfachung und/oder Durchbrüche, die alle anderen Entwickler überzeugen, den Weg zurück zum Trunk finden.Es ist auch gut, eine neue Lösung in einem Thread zu diskutieren, bevor man sie implementiert, da andere Entwickler Einblicke geben könnten, wie eine solche Lösung umgesetzt werden könnte (um dem anderen Entwickler Arbeit und Zeit zu ersparen).

EDUWAFA Ziel:

  • Elektrische Energieerzeugung: 2..20 kW (Mikrowasserkraft).
    Der Prototyp konkret:
  • Dual Output: 1x 2 kW bei Niedrigwasser (Sommer) + 1x 4 kW sonst.
    Entwicklung:
    • [strike]Versionierungssystem für den Webspace[/strike] (erledigt) (Server wäre viel einfacher, weil wir da ROOT, also Administrator, wären und damit alle benötigten Installationen leichter wären als Mercurial und Python und alle anderen benötigten Pakete ohne diese Rechte zu installieren.)
      Ziel dieses Unterfangens: Forenthema - Soll das Wiki Entwicklerseiten spiegeln?
    • BMS - BatterieManagementSystem (erledigt in Revision 1, Referenz wird hinzugefügt, aktuell gibt es für mich KiCAD-Probleme).
    • Rohrleitung, bis dato wurde vergeblich nach gebrauchten und günstigen 10cm-Durchmesserrohren gesucht. Aber egal ob man Weinbauer fragte oder das Internet durchsuchte, immer gab es Probleme. Die ostdeutschen Länder waren zu weit entfernt oder die gefundenen Rohre hatten Bewässerungslöcher. Nach langem Hin- und Her also folgender ‚Trick‘: Wir nehmen einfach mehrere 5cm-Durchmesserrohre an Stelle des einen 10cm-Rohres.