Facial Recognition

It’s been a while since I wrote a post. Over the Christmas holidays I was able to invest a little more time in my hobby. The current goal is a security camera with the Raspberry Pi 4 running a offline face recognition.

To get a good overview of which facial recognition is suitable, I tried some on my Ubuntu system. Anyone who played with face recognition two years ago and was disappointed with the result should definitely test RetinaFace and ArcFace from http://insightface.ai/. The performance is really amazing and terrifying at the same time.

RetinaFace is a high performance face detector and outputs five facial landmarks (eyes, nose, 2xmouth). The points are used to align the faces uniformly so that the recognition stage (ArcFace) get evenly aligned faces.

I did some tests and also tested the lightweight models from ArcFace. However, the quality falls far too quickly and I stayed with the original network. The lightweight RetinaFace model is okay when small face are not that relevant.

My Raspberry camera is currently sending faces that are not in the face database to my smartphone via a Telegram Bot. This is currently working quite slowly. If you actively cool the Pi 4 (>= 4GB RAM, Ubuntu 64Bit), a camera image with a face is evaluated within 2 seconds. With passive cooling only the value drops to approx. 5 seconds.

You could see a early version with a working script on my github account:

https://github.com/Counterfeiter/SecurityCam

Please consider there is a long way to execute this script on the Pi:

• Install Ubuntu 64 Bit instead of Rasbian
• cross compile mxnet v1.6 python wheel from MXNet source (docker build)
• build opencv from source (takes a while)
• because of the armv8 (64 Bit arch) a lot of python packages will build from source (takes a while)
• calibrate your camera (especially fish eye cameras)

There is still much to be done to increase the speed to a manageable level. In the next few weeks I will compile MXNet again with NNPACK linking. Hopefully this should double the inference speed, especially on ARM architectures. Furthermore, if there is enough memory, a batch inference could increase the speed.

Furthermore, I found the resources about facial recognition on YouTube is rather poor. Somehow no video could really convey what this technology can already do. So I looked for a video with many faces and ran it through a Python script. The result is people with unique numbers above their heads. Since each video frame was processed individually, (almost) no filters were used, it is quite easy to see how simple it is to find people in YouTube videos.

There are still so many steps to take in order to get a good result on the Raspberry Pi, I hope I will find some time to report a little more in the next few weeks.

Celestron Teleskop SkyQ Link WI-FI hack

Ein guter Freund hat seit neustem ein Teleskop von Celestron und ich geh gern mit auf Nachthimmelschau. Leider bietet die zugehörige Tastenfernbedienung mit 7-Segmentdisplay nicht so viel Komfort wie die Handy-App (SkyPortal). Von Arbeitskollegen weiß ich zwar, dass die Profis mit diversen PC-Tools, also Laptops, ausgerüstet den Nachthimmel observieren, jedoch ist uns das für den Einstieg ein bisschen zuviel.

Die Lösung für die Handy-App wäre also dieses Zubehör:

Celestron WLAN-Modul SkyPortal Wi-Fi

Das Zubehör am AUX-Port hat einen stolzen Preis. Natürlich habe ich mich gefragt, welche Funktion es eigentlich erfüllt und ob es nicht schon einen Hack mit einem ESP8266 oder ESP32 gibt, um sich die Investition zu sparen, da das Hobby durch teure Optiken schon ausreichend ausufern kann.

Ich hatte zwar einige Forenbeiträge gefunden, die sich daran versucht haben, jedoch gescheitert sind. Auf der Celestron-Seite bekommt man schnell heraus:

Mit eigenem Access-Point hat das Teleskop die IP 1.2.3.4 auf TCP Port 2000. Da es an den AUX Port angesteckt wird, könnte es einfach nur eine UART per TCP Durchleitung sein?! Auf dieser Seite gibt es sehr gute Infos über das Protokoll und die nötige Hardware zum AUX-Port:

https://sites.google.com/site/wayneholder/nexstar-direct-telescope-mount-control

Auf einer anderen Seite hieß es, dass original Module verwendet ein RN171, welches ich schon gut kannte. Die Idee mit der UART-Durchleitung wurde immer wahrscheinlicher.

Mit einem ESP8266-12E Module für ca. 2 € und einer Adapterplatine (leider keine Quelle mehr) für 50 Cent hab ich mich an die Funktionalitäten herangetastet:

Ein github Repo für die Arduino-Firmware habe ich nicht erstellt, da es UART-WiFi Links wie Sand am Meer gibt. Ich habe folgenden Sketch für mich abgewandelt:

https://github.com/roboremo/ESP8266-WiFi-UART-Bridge/blob/master/v1.1/sketch_esp_WiFi_UART_Bridge.ino

Einfach auf 19200 Baud, TCP, AP einstellen und fertig… zumindest schon mal die Software, die Hardware hat mir einiges mehr an Nerven gekostet.

Um euch nicht mit den Details zu quälen, diese Schaltung funktioniert ganz wunderbar:

Celestron WiFi SkyPortal Hack

Die UART des ESP wird zu einer Art One-Wire-Bus zusammengeführt, da im Celestron zwei PIC Mikrocontroller auf diesem Bus hängen. Damit ließt das ESP auch seine gesendeten UART-Daten sofort zurück. Dies wird jedoch bereits in der Handy-App berücksichtigt und muss nicht herausgefiltert werden.

Merkwürdig war: wenn das ESP8266 ohne die NPN-Kollektorschaltung angeschlossen wurde, konnte der RX-Pin des ESP8266 nicht zu jeder Zeit auf GND getrieben werden, als wenn gelegentlich ein sehr starker (1k ?) Pull-up am RX-Pin des ESPs zugeschalten wurde. Daher bin ich mit dem recht starken Pull-Down von 150 Ohm erst zu guten Signalpegeln gekommen. Am NPN fällt ca. ein Volt ab, so das 1 Pegel nur mit 2,3 Volt am ESP anliegt, was jedoch für diese Bastelei ausreichend scheint. Der TX-Pin am ESP wird mit einer Schottky-Diode von einer PushPull-Konfiguration zu einem OpenDrain-Ausgang modifiziert.

Hinterher wirkt die Schaltung recht unspektakulär, damit es überhaupt funktioniert muss Alles recht gut abgestimmt sein. Da das Celestron-Teleskop für mich weiterhin eine Blackbox ist, die ich nicht tiefer untersucht habe, gibt es wahrscheinlich auch noch besser Lösung.

Ich hoffe ihr könnt euch mit dieser Anleitung ebenfalls eine low cost WiFi Bridge anfertigen. Bei Fragen und Anregungen bitte die Kommentarfunktion benutzen. Zum Abschluss noch ein paar Bilder:

Die Kunst des Timings

Mir ist aufgefallen, dass erstaunlich viele erfahrene Embedded-Entwickler einen Zeitstempel nicht korrekt anwenden können.

Bei den CortexM Controllern wird meist ein 32-Bit-Zähler über den Systick-Interrupt jede Millisekunde hochgezählt. 32-Bit, da es ein 32-Bit-Mikrocontroller ist und dieser aligned Zugriffe (teils auch unaligned) in „single read and single write“ instructions beherrscht. „modify and write“ (Zähler hochzählen) ist hingegen nicht gesichert, jedoch würde man im Hauptprogramm nur den Alten oder den neuen Wert auslesen, was hier absolut okay ist, da die Zählervariable nicht im Hauptkontext konkurierend geschrieben wird.

Nun ist eine unsigned 32-Bit-Variable groß, hat jedoch auch ihre Grenzen. Die Variable läuft nach 49,71 Tagen über und da viele Gerät eine deutlich längere Betriebszeit aufweisen müssen, sollte dies im Programm immer berücksichtigt werden.

Wie also ein nicht blockierende Verzögerung mit Hilfe des Systicks einbauen?

Hier das Beispiel, wie es nicht getan werden sollte:

if(button_clicked()) {
    my_timediff_u32 = GetSystickCnt();
    button_reset_click();
}
if(my_dimefiff_u32 + 1000 >= GetSystickCnt())
    bang();

Läuft die Application bereits 49,71 Tage und man rechnet auf den fast überlaufenden Wert noch mal 1000 (ms) dazu, dann wird der Wert überlaufen und die Bedingung ist ohne Wartezeit wahr!

Weiterhin wurde vom Entwickler geplant, das bang() nach Ablauf des gesetzten Timeouts weiterhin durchlaufen wird. Dies jedoch nicht der Fall ist, wenn my_timediff_u32 + 1000 einen hohen Wert annimmt (z.B. 0xFFFFFFFF) und GetSystickCnt() überläuft… nun dauert es ~ 49 Tage bis bang() wieder aufgerufen wird.

Nächste Stolperfalle -> etwas besser und immer noch falsch:

if(button_clicked()) {
    my_timediff_u32 = GetSystickCnt();
    button_reset_click();
}
if(GetSystickCnt() - my_dimefiff_u32 >= 1000)
    bang();

Durch die Differenzbildung wird der Überlauf abgesichert und erhält auch in Überlaufbedinungen 1000 ms Verzögerung. Rechenbeispiel:

GetSystickCnt() - my_dimefiff_u32 >= 1000
0x100 - 0xFFFFFFF8 > 1000
0x108 > 1000
264 > 1000

Also alles save? Nicht ganz! Ein weiteres 49,71 Tage Problem tritt auf: Ist die Zeit abgelaufen soll bang() durchlaufen werden bis button wieder geclickt wird. Jedoch wird nach ~49 Tagen bang() für die gesetzt Zeit erneut nicht durchlaufen, als ob magisch der Taster gedrückt wurde.

Nun debuggt mal einer diesen Quellcode, der aller 49 Tage komische Dinge tut. Daher werden einige medizientechnischen Produkten sogar beabsichtigt vor diesem Zeitraum deaktiviert und der Benutzer zu einem Reboot aufgefordert. Ja, dies kann in einer FMEA eine entscheidende Rolle spielen.

Da mir diese Problem grundlegend bekannt ist, habe ich bisher immer auf drei Dinge bei der Implementierung geachtet.

1. Einen „Merker“ setzen, ob der Timer bereits übergelaufen ist und die Zeitbedingung gar nicht mehr prüfen.

if(button_clicked()) {
    my_timediff_u32 = GetSystickCnt();
    button_reset_click();
}
if(time_overflow || (GetSystickCnt() - my_dimefiff_u32 >= 1000)) {
    bang();
    time_overflow = 1;
}
else
    time_overflow = 0;

2. Der Timer wird nur zyklisch verwendet. Zum Beispiel bei einer Batteriespannungsmessung wird bei Ablauf der Timer direkt neu aufgespannt.

if(GetSystickCnt() - my_dimefiff_u32 >= 1000) {
    get_accu();
    my_timediff_u32 = GetSystickCnt(); //restart timer
}

3. Wenn es keinen else Zweig gibt und die Funktion bang() etwas fixes setzt, z.B. ein LED am GPIO, dann wäre es auch keine Änderung, wenn die LED nicht mehr gesetzt wird, da sie schon leuchtet. Dieses Konzept wollte ich nur mal benennen, jedoch ist es sehr irreführend und ich kann es nicht empfehlen. Wenn jemand jedoch aufgrund dieses Postes panisch seine alten Quellen checkt: es kann auch zufällig funktionieren!

Davon auszugehen, dass die Applikation keine 49 Tage betrieben wird, ist mir zu unsauber, egal ob es nur eine Haarschneidemaschine ist.

Da das Vorgehen mit dem Merker schnell aufwändig wird, habe ich mir letztens Abhilfe geschaffen und meine „utils.h“ erweitert. Ziel war es, dass neue „Timer-Modul“ ebenfalls mit einfachen uint32_t zu verwenden und nahezu gleichen Call-Syntax wie meine bisherigen Makros: PASSED_MS(_tick, _timeout). Als Merker habe ich mir das MSB geklaut.

#define TIMER_RESET()        (GetSystickCnt() & 0x7FFFFFFFUL)
#define TIMER_GET_MS(_Timer) ((GetSystickCnt() - _Timer) & 0x7FFFFFFFUL)
static inline int TIMER_PASSED_MS(uint32_t *timer, uint32_t timeout_ms) {
    assert_param(ms <= 0x7FFFFFFFUL);
    if(TIMER_GET_MS(*timer) >= timeout_ms)
        *timer |= 0x80000000UL;
    return ((*timer & 0x80000000UL) != 0UL) //bit to logic (bool)
}

Ein winziger Nachteil ist die maximale Timeout Zeit von nur noch ~ 24,86 Tagen. Jedoch wird dies in den wenigsten Programmen benötigt.

Wer nun meint, ist doch alles quatsch ich nehme als Systick einfach eine 64-Bit-Variable, der kann sich ebenfalls aller ~ 49 Tage wundern, wenn er nicht bei jedem Zugriff die Variable mit abgeschaltetem Systick-Interrupt ließt.

Fazit

Ein bisschen Timing ist keine große Sache? Weit gefehlt! Der Einsatz einfacher Zeitstempel erfordert tiefes Wissen über das System und Grundlagen der binären Zahlenverarbeitung. Ich hoffe ich konnte mit diesem Beitrag etwas Aufschluss geben.

Corona-Warn-App – Benutzer scannen

Die Corona-Warn-App scheint nun nach einigem Hin und Her recht gut aufgestellt im Bereich Sicherheit und Datenschutz.

Der einzigste Hack der mir einfallen würde, der sich aber auch nur sehr schwer verhindern lässt: die Beaconpakete mit einer starken Antenne repeaten bzw. “replay attack“.

Da das Empfängerhandy den Signalpegel des eingehenden Paketes verarbeitet, würde eine starke Sendeantenne mehr Nähe suggerieren.

Ein mögliches Scenario wäre:  Ich mag meinen Nachbarn nicht und gönne ihm den anstehenden Urlaub in Spanien schon gar nicht. Ich installiere in einer Zone mit vermutlich hohem Infektionsgeschehen ein „Beacon Scanner“ (kann ein einfaches Handy sein) der alle gescannten Advertisepakete (auch entferntere Personen als 2 m)  per LTE-Brücke auf meinen starken Sender daheim schickt. In hoher Frequenz bringe ich die Personen die z.B. in einer Klinik arbeiten virtuell meinem Nachbarn sehr nahe. Also das Klinikpersonal einschließlich Patienten mit App, welche sich auch nur kurzzeitig in einem 50 m Umkreis um meinen Empfänger befunden haben, werden jetzt für länger 20 Minuten meinem Nachbarn zugeführt.

Wenn er Pech hat und eins der gescannten Beacons wurde als Infektiös gemeldet, bekommt er ein paar Stunden vor Abflug eine sehr hohe Risikomeldung. Wird er fliegen? Würdet ihr fliegen?

Dennoch werde ich mir die App installieren, da das Angriffscenario doch recht abstrakt scheint.

Wer wissen möchte, ob die Nachbarn schon die App haben, der sollte sich die Sensortag App von Texas Instruments (TI) laden.

Mit folgender Filteroption seht ihr nur „Corona-Beacons“ mit aktueller Signalstärke:

 

Zu beachten ist, dass ca. aller 15-20 Minuten die Schlüssel rotieren. Es muss also nicht immer eine andere Person sein. Mit Hilfe der Signalstärke, dem Verschwinden und neu Erscheinen kann man jedoch recht gut abschätzen wohin welcher Schlüssel gerade rotiert ist, jedenfalls bei kleiner Liste.

**Update***

Ich habe heute mein iOS aktualisiert und konnte die Corona-Warn-App nun installieren. Leider hat Apple im neuen iOS auch die Service-ID für das Covid-19 Beacon beim Bluetooth Scan unterdrückt (macht auch Sinn). Damit funktioniert der gezeigte Weg über die Sensortag-App nicht mehr.

Bleibt noch der Weg über Linux:

sudo hcitool lescan --duplicates

…anschließend mit einem Wireshark-Filter die Pakete einsehen:

btcommon.eir_ad.entry.uuid_16 == 0xfd6f

Regelungstheorie COVID-19 Infektionsgeschehen

Zur Zeit findet eine Art Überbietungswettkampf der Wissenschaften statt und welchen Einfluss diese Disziplinen auf die Politik nehmen können. Welche Wissenschaft gibt in dieser Pandemiesituation nun den Grundton vor?

Ich möchte in diesem Blog-Post gar nicht so sehr politisch werden, da weiterhin das Grundthema des Blogs natürlich auf meiner Ausbildung basieren soll. Dies schützt weitestgehende davor Halbwahrheiten in die Welt zu setzen.

Regelungssystem der Regierungen für die Bekämpfung des SARS-CoV-2 Erregers

 

Dennoch möchte das oben gezeigte Blockschaltbild zur Diskussion stellen. Es zeigt das Regelungssystem mit den für diese Pandemie wichtigsten Einflüssen. Wichtig ist natürlich immer relativ, daher steht ein „…“ für weitere wichtige nicht gezeigte Regelstrecken, z.B. Kultur und Soziales.

Interpretation Blockschaltbild

Schön zu sehen ist, dass die Medien Rückmeldungen der einzelnen Systeme im Idealfall ungefiltert erhalten, verarbeiten und der Bevölkerung nach den Grundlagen der Pressfreiheit präsentieren. Dies gilt auch für Facebook-Beiträge, diverse Tweets und fragwürdigen YouTube-Videos. Jeder darf die Lage auf seine Weise interpretieren und seine Ansichten verbreiten. Istwerte der Regelstrecken werden zur Meinungsbildung, führen zu Verhaltensanpassung des Volkes.

Dem parallel, versucht die Politik die Bevölkerung möglichst zielgenau zu den gewünschten Verhaltensweisen zu bewegen, die nötig sind um die vorher festgelegten Sollwerte zu erreichen. Arbeiten Politik und Medien gegeneinander (unterschiedliches Vorzeichen am Additionsblock) ist das Erreichen der Sollwerte schwierig. Staaten in denen die Medien nicht unabhängig berichten können, haben es demnach deutlich einfacher die Sollwertvorgaben zu erreichen.

Eher ungewöhnlich in der Regelungstheorie: Ein System (Politik) übernimmt das Festlegen des Sollwertes und ist gleichzeitig der Regler. In einem ideal beschreibbaren und bekanntem System muss die Sollwertvorgabe nicht immer wieder neu vorgenommen werden. Die Abwägung für die Sollwertvorgaben der einzelnen Systeme basiert auf neuen Erkenntnissen über die Regelstrecken selbst. Nicht nur weil das Infektionsgeschehen so komplex ist, auch alle anderen Systeme haben erhebliche Komplexität die nicht vom Zeitpunkt null an für die Zukunft betrachtet werden können. Ein Ziel die Reproduktionszahl R auf 0,25 zu drücken, muss vielleicht wieder fallen gelassen werden, weil die Lebensmittelversorgung ins Stocken geraten könnte. Diese Anpassung der Sollwerte führt für die Bevölkerung zu einem schwer nachvollziehbaren Tauziehen der Wissenschaften und Lobbyverbänden.

Das Stellglied, das direkt Einfluss auf alle Regelstrecken nimmt, ist das Verhalten der Bevölkerung. Das System „Bevölkerung“ wird auch nicht immer gleich reagieren und ist Störgrößeneinfluss (nicht eingezeichnet) unterworfen. Eine zweite Aufforderung zum Lockdown wird anders behandelt als die Erste. Daher werden z.B. anonymisierte Netzdaten von Mobiltelefonen herangezogen, um die Störgröße direkt und schnell zu erfassen und geeignet gegen zu steuern.

Die Modelle zu den Regelstrecken selbst, kommen von den Wissenschaftlern in ihren Spezialdisziplinen. Da es keinen ökonomischen Pandemie-Soziologen Master of Science gibt, muss jede Wissenschaft auf die prognostizierten Istwertänderungen im eigenem System aufmerksam machen. Dieses nötige Gerangel ist medial im vollen Gange.

An den Ausgängen der Regelstrecken befindet sich der Rückkopplungszweig. Ohne ein Rückkopplung wäre es keine Regelung und das System auch nicht beherrschbar. Somit hat jede Regelstrecke eine hohe Anzahl an Istwertparametern (y), um das System zu beobachten.

Bei COVID-19 ist weitestgehend bekannt, dass Symptome im Durchschnitt erst ab dem 5 Tag der Infektion auftreten und damit schon eine erhebliche Totzeit bei der Messung besteht. Hinzu kommen weitere Verzögerungen: Symptombeginn bis PCR-Abstrich, PCR-Abstrich bis Laboruntersuchung und Laboruntersuchung bis Information des Patienten, bzw. das Einarbeiten der Daten für den Sollwertvergleich (Differenzblock). Durch die Umsetzungen und Lockerungen im Zwei-Wochen-Rhythmus wird die Totzeit abgewartet, dass Maßnahmen direkt bewertet werden können.

Ich hoffe ich konnte in diesem Beitrag zeigen, dass viele komplexe Zusammenhänge mit einem Blockschaltbild einfacher erklärt werden können.

Cloud deep neural network controller [en]

The Cloud DNNC is a project to replace the PID controller from the most common control systems: simple in simple out (SISO) systems with first order plus dead time FOPDT and second order plus dead time (SOPDT) system behavior. Since the DNNC does not require any parameterization (model free), it is very easy to use and no in-depth knowledge of the given process parameters is necessary. By considering the process as a black box, it is even possible to provide a cloud controller as a service. Otherwise a model of the process and controller parameters derived from it would be required.

Of course, the question of what makes sense immediately arises, since process security goes hand in hand with the availability of my server service. Therefore, everyone should be clear: this service is a playground. You are welcome to connect your simulated or real process to the controller and carry out various tests. I do not guarantee service availability. I would then be happy to receive your experience reports so that I can further optimize the controller.

The neural network is permanently optimized in the cloud on various CPU and GPU resources. I will inform you about updates and improvements of the DNNC on this blog.

My final goal is to port the network to a CortexM4 microcontroller. The “deep” in deep neural network is therefore limited by the resources of such a microcontroller.

The following graphic shows the closed control loop:

It is actually as simple as it looks. Basically, the service expects an HTTP GET request with the setpoint (SP) and the actual process value (y (t)). The controller output (u (t)) that is to be applied to the actuator is returned. In order that everything from level to temperature control can be covered, the input and output variables must be scaled and transmitted without units. The value ranges of the DNNC should always be used from 0 to 100%. The same procedure can be found in many industrial controllers.

Process example: temperature control for soldering furnace

Temperature range: 0 ° C to 260 ° C => 0% = 0 ° C, 50% = 130 ° C
Actuator: Triac with full wave control (0 to 50) => 50% = 25 full waves

The DNNC will suggest a manipulated variable with a lot decimal places, but in many cases this can simply be rounded. However, it should not be pushed so far that the DNNC is used as a two-point controller (> 50% = on, <= 50% off); this can work but gives poor controller results.

Comparison of PID and DNNC:

As can be seen, the DNNC loses out against a well-tuned PID controller, but it can score if the process changes and most processes do: Filters become clogged with dirt, flow temperatures are different, fill quantities vary, etc. The selected parameters in the graph show the generalization of the controller.

In principle, any programming language can be used with the help of the HTTP API. I provide a Python script with a class and an example to simulate a process system using the scipy package:

https://github.com/Counterfeiter/CloudDNNC

If you want to control a real process with Hardware in the Loop (HIL), you are cordially invited. Please note the ping times of approx. 70 ms lead to another dead time. It also occasionally happened that requests received a timeout + retransmit and the response came from the server only after four seconds. I therefore recommend regulating “lazy” processes and sending inquiries every second or fewer.

Function and behavior of the controller

The neural network receives the input and output values ​​of the process system as inputs and tries to „estimate“ the further behavior. It therefore approaches the task and is inferior to a controller with a known process model (model based) with regard to control speed. With varying process parameters, the DNNC has a clear advantage. However, the possible process parameters also have their limits.

The design of the DNNC is a compromise between covering additional process parameters or faster setpoint response. If the narrow parameters for a given process are known, a “specialist system” could easily be learned. However, this has also been possible for a long time with Matlab tools and some other systems.

As already mentioned, the DNNC starts with no knowledge of the process when sending the first control variable. As a result, it can only try a very small actor output, there is a risk that the process gain is very high and the dead time is long. As result a large overshoot would be likely. After the DNNC has got a „feeling“ for the dead time of the system after 4 to 5 values, the control variable can be managed more aggressively.

The neural network is trained with the help of reinforcement learning in the Amazon (AWS) cloud. In regular stages, I have several hundred systems evaluated and use them to calculate an average. I plot the systems that got an (abstract) rating below 0 and compare the system parameters.

A few numbers to get a feeling for the rating function:

• If the control output is randomly varied between 0 and 100%, the rating is -835.
• If the setpoint 0.0 is specified and the controller remains at 0.0 u (t), a best value of 904 can be achieved.
• Systems that have a large time constant and high damping cannot achieve a rating above 0, in spite of the perfect controller.

The grid score for the currently hosted network from 02.02.2020 ( DNNCv1.0 ) = 319.7 :

DNNCv1.0 – Grid Score < 0 Systems

Dead times with four time steps and more should therefore be avoided. Optimizations for this are still ongoing. If you look halfway through the graph, you will see: Brown and purple on the way to the 100% setpoint were rated poorly (<0.0), even though the controller was almost fully open. Accordingly, the evaluation scale is certainly in need of improvement, but is sufficient to compare different training processes.

 

Furthermore, it should be considered that these systems are difficult to control (Tu / Tg <1/5) and that a well tuned PID is already reaching its limit:

Source: https://www.automation.siemens.com/sce-static/learning-training-documents/classic/advanced-programming/b03-control-engineering-de.pdf

Just looking at the worst system is frustrating too. Here are all systems with a GridScore of over 500:

DNNCv1.0 – Grid Score> 500 systems

As you can see, no „setpoint 100 %“ system reaches this score, for purely mathematical / physical reasons.

 

Process controller without parameterization? Only half the truth!

In fact, no tuning parameters need to be set, but scaling is necessary. This has a large influence on the stability of the DNNC. The process gain refers to the scaled area. If, for example, a heating coil is available that could heat a water pipe to 100 ° C and it is only a matter of keeping a pipe free of ice (setpoint ~ 4 ° C), it would be more appropriate to set the control value range of the DNNC (0 to 100%) only to 10 or 20% heating power to stay in the stable gain section. Otherwise the process path can also be scaled from -10 to 100 ° C, but this leads to somewhat poorer setpoint tracking.

In addition to the scaling that has an impact on the process gain, the time behavior must also be considered. If the pipe heating mentioned above (which certainly does not become a water heater, as I exaggerated) only comes into the work area after two hours, no controller values ​​should be requested from the server every minute. The dead time until there is a temperature change at the sensor would be much longer than four time steps, in this example.

So the user needs a rough clue about his process and maybe he even has to record a step response. Is the DNNC just a bluff? Ultimately, this is decided by practical use! The DNNC starts to regulate a very wide range of process parameters in order to be able to cover a great deal for everything from seconds to days, from oversized to undersized actuators. This requires scaling with some background knowledge of the process.

outlook

The DNNC will continue to be optimized by me and will be updated occasionally. I will see in the next few weeks how stable my web service will run if there are many inquiries. Here I still lack experience.

A Jupyther notebook is already being planned, which will present a few simulations and should still close some user knowledge gaps. In addition, I have not yet shown how robust the DNNC reacts with 1% measurement noise and load jump, etc.

 

FAQ

Unfortunately, the DNNC was unable to regulate the cooling water of our fuel rods. Where can I claim the costs caused by the super meltdown?

Please use this service at your own risk and set sensible critical switch-off thresholds beforehand.

My self balancing robot keeps falling over. What am I doing wrong?

1. no PTxDT system – could work, but not tested
2. I estimate the offline version of the controller with 200 µs computing time on a CortexM4. For this online version, I recommend trying less gravity.

Is the project open source?

No, the controller itself is not open source. However, I will publish some marginal areas of it, for example the simulation of PTxDT systems with Python and later the framework of my flask backend. So it remains interesting for hobbyists.

Can the DNNC also be optimized according to the actuating energy?

There is currently no effort on my part to do so. Possibly. an additional low-pass filter can be inserted between the DNNC output and the actuator, but this will lower the control quality.

Cloud Deep Neural Network Controller [de]

Der Cloud DNNC ist ein Projekt um den PID-Regler aus den am häufigsten auftretenden Regelstrecken abzulösen: Eingrößensysteme mit PT1DT und PT2DT Streckenverhalten (~PTxDT). Da der DNNC keine Parametrierung erfordert (model free), ist er sehr einfach anzuwenden und es ist kein tieferes Wissen über die gegebenen Prozessparameter nötig. Durch die Betrachtung des Prozesses als Blackbox, ist es überhaupt möglich ein Cloud Controller als Service bereitzustellen. Andernfalls bedürfte es ein Modell des Prozesses und daraus abgeleitete Reglerparameter.

Natürlich kommt sofort die Frage nach der Sinnhaftigkeit auf, da die Prozesssicherheit mit der Verfügbarkeit meines Serverdienstes einhergeht. Darum sollte jedem klar sein: Dieser Service ist eine Spielwiese. Gern könnt ihr euren simulierten oder echten Prozess mit dem Controller verbinden und verschiedene Versuche fahren. Eine Serviceverfügbarkeit garantiere ich nicht. Ich würde mich anschließend über eure Erfahrungsberichte freuen, damit ich den Controller weiter optimieren kann.

Das Neuronale Netzwerk wird in der Cloud auf verschiedenen CPU und GPU-Ressourcen permanent optimiert. Ich werde auf dieser Seite über Updates und Verbesserungen des DNNCs informieren.

Mein finales Ziel ist eine Portierung des Netzwerkes auf einen CortexM4 Mikrocontroller. Das „Deep“ in Deep Neural Network ist also durch die Ressourcen eines solchen Mikrocontrollers limitiert. Erst in dieser Entwicklungsstufe ist der Controller sinnvoll einsetzbar.

Folgende Grafik zeigt den geschlossenen Regelkreis:

So einfach, wie es aussieht, ist es tatsächlich auch. Im Grunde erwartet der Service eine HTTP GET Anfrage mit dem Sollwert (Setpoint SP) und dem Istwert (y(t)). Zurückgegeben wird die Stellgröße (u(t)), die auf das Stellglied anzuwenden ist. Damit von Füllstands- bis Temperaturregelung alles abdeckt werden kann, müssen die Ein- und Ausgangsgrößen skaliert und einheitenlos übertragen werden. Die Wertebereiche des DNNCs sind immer von 0 bis 100 % anzuwenden. Selbes Vorgehen ist bei viele Industriecontrollern zu finden.

Prozessbeispiel: Temperaturregelung für Lötofen

Temperaturbereich: 0°C bis 260°C => 0 % = 0°C, 50 % = 130 °C
Stellglied: Triac mit Vollwellensteuerung ( 0 bis 50) => 50 % = 25 Vollwellen

Der DNNC wird einen Stellwert mit vielen Nachkommastellen vorschlagen, jedoch kann dieser in vielen Fällen einfach gerundet werden. Es sollte jedoch nicht so weit getrieben werden, dass der DNNC als Zweipunktregler eingesetzt wird (> 50 % = an, <= 50 % aus); dies kann funktionieren, gibt jedoch schlechte Regelergebnisse.

Gegenüberstellung PID und DNNC:

Wie zu erkennen ist, hat der DNNC gegen ein gut abgestimmten PID-Regler das Nachsehen, jedoch kann er punkten, wenn der Prozess sich ändert und das tun die meisten Prozesse: Filter setzen sich mit Schmutz zu, Vorlauftemperaturen sind unterschiedlich, Füllmengen variieren etc. Die gewählten Parameter im Graphen zeigen gut die Generalisierung des Reglers.

Mit Hilfe des HTTP APIs kann im Prinzip jede Programmiersprache zum Einsatz kommen. Ich stelle ein Python-Script mit einer Klasse zur Verfügung und einem Beispiel um ein Prozesssystem mit Hilfe vom scipy-package zu simulieren:

https://github.com/Counterfeiter/CloudDNNC

Wer einen echten Prozess mit Hardware in the Loop (HIL) ansteuern will, ist herzlich dazu eingeladen. Bitte beachtet die Ping-Zeiten von ca. 70 ms führen zu einer weiteren Totzeit. Auch kam es gelegentlich vor, dass requests einen timeout + retransmit erfahren haben und erst nach vier Sekunden die Antwort vom Server kam. Ich empfehle daher „gemütliche“ Prozesse zu regeln und sekündliche oder weniger Anfragen zu versenden.

Funktion und Verhalten des Reglers

Das Neuronale Netzwerk erhält die Ein- und Ausgangswerte des Prozesssystems als Eingänge und versucht den weiteren Verlauf „abzuschätzen“. Es tastet sich also an die Aufgabe heran und ist demnach einem Regler mit bekanntem Prozessmodel im Hinblick auf Regelgeschwindigkeit unterlegen. Bei variierenden Prozessparametern ist der DNNC klar im Vorteil. Die möglichen Prozessparameter haben jedoch auch ihre Grenzen.

Die Auslegung des DNNC ist eine Kompromiss zwischen der Abdeckung weiterer Prozessparameter oder schnellerem Setpoint-Tracking. Sind bei einem gegeben Prozess die engen Parameter bekannt, könnte problemlos ein „Spezialisten-System“ angelernt werden. Dies geht jedoch auch schon länger mit Matlab-Tools und einigen anderen Systemen.

Wie schon erwähnt, startet der DNNC beim Senden des ersten Stellwertes mit keinem Wissen über den Prozess. Folglich kann er nur einen sehr kleinen Stellwert versuchen, es besteht die Gefahr, dass die Streckenverstärkung sehr hoch ist und die Totzeit groß. Demnach wäre ein großes Überschwingen wahrscheinlich. Nachdem der DNNC nach 4 bis 5 Werten ein „Gefühl“ für die Totzeit des Systems bekommen hat, kann der Stellwert aggressiver geführt werden.

Das Neuronale Netzwerk wird mit Hilfe von Reinforcement Learning in der Amazon (AWS) Cloud traniert. In regelmäßigen Etappen lasse ich mehrere hundert Systeme bewerten und berechne daraus  einen Mittelwert. Die Systeme, die eine (abstrakte) Bewertung unter 0 bekommen haben, plotte ich und vergleiche die Streckenparameter.

Ein paar Zahlen, um ein Gefühl für die Bewertungsfunktion zu bekommen:

• Wird der Stellausgang zufällig zwischen 0 und 100 % variiert, ergibt sich ein Bewertung von -835.
• Wenn der Sollwert 0.0 vorgegeben wird und der Controller bei 0.0 u(t) bleibt, kann ein Bestwert von 904 erreicht werden.
• Systeme, die eine große Zeitkonstante und hohe Dämpfung aufweisen, können teils trotz perfektem Kontroller nicht über eine Bewertung von 0 kommen.

Der Grid Score für das aktuell gehostete Netzwerk vom 02.02.2020 ( DNNCv1.0 ) = 319,7:

DNNCv1.0 – Grid Score < 0 Systeme

Totzeiten mit vier Zeitschritten und darüber sollten demnach noch vermieden werden. Optimierungen hierzu sind noch im Gange. Wer bei dem Graphen noch halbwegs durchsieht, stellt fest: Braun und Lila auf dem Weg zum 100 % Sollwert wurden schlecht (< 0.0 ) bewertet, obwohl der Regler nahezu voll aufgesteuert hat. Demnach ist der Bewertungsmaßstab sicherlich verbesserungsbedürftig, aber ausreichend um verschiedene Trainingabläufe zu vergleichen.

Weiterhin sollte bei den Systemen bedacht werden, dass diese schon zu den schwer regelbaren Systemen zählen (Tu/Tg < 1/5) und auch ein abgestimmter PID schon an seine Grenze stößt:

Quelle: https://www.automation.siemens.com/sce-static/learning-training-documents/classic/advanced-programming/b03-control-engineering-de.pdf

Nur die schlechtesten System anschauen ist auch frustrierend. Hier noch alle System mit einem GridScore von über 500:

DNNCv1.0 – Grid Score > 500 Systeme

Wie man sieht, erreicht kein „Sollwert 100 %“ System diesen Score, aus rein mathematischen/physikalischen Gründen.

Prozess-Controller ohne Parametrierung? Nur die halbe Wahrheit!

In der Tat müssen keine Tuning-Parameter eingestellt werden, jedoch ist eine Skalierung nötig. Dies hat einen entscheidenden Einfluss auf die Stabilität des DNNCs. Die Streckenverstärkung bezieht sich auf den skalierten Bereich. Steht z.B. eine Heizwendel zur Verfügung, die eine Wasserleitung auf 100 °C erhitzen könnte und es geht nur darum eine Rohrleitung eisfrei zu halten (Sollwert ~ 4 °C), wäre es geeigneter den Stellwertbereich des DNNCs (0 bis 100 %) nur auf 10 oder 20 % Leistung der Heizung anzuwenden, um in der stabilen Streckenverstärkung zu bleiben. Andernfalls kann die Prozessstrecke auch von -10 bis 100 °C skaliert werden, dies führt jedoch zu etwas schlechterem Sollwert-Tracking.

Zusätzlich zur Skalierung die Einfluss auf die Streckenverstärkung hat, muss auch das Zeitverhalten betrachtet werden. Kommt die bereits oben angesprochene Begleitheizung (die sicher nicht zum Durchlauferhitzer wird, wie von mir übertrieben dargestellt), erst nach zwei Stunden in den Arbeitsbereich, sollten keine Reglerwerte im Minutentakt vom Server abgefordert werden. Die Totzeit bis sich eine Temperaturänderung am Sensor ergibt, wäre an diesem Beispiel viel höher als vier Zeitschritte.

Damit benötigt der Anwender einen groben Anhaltspunkt über seinen Prozess und vielleicht muss er sogar eine Sprungantwort aufnehmen. Ist der DNNC nur eine Mogelpackung? Das entscheidet letztendlich der Praxiseinsatz! Der DNNC tritt an, um einen sehr weiten Bereich von Prozessparametern auszuregeln, um für möglichst alle Bereiche von Sekunden bis Tagen, von überdimensioniertem bis unterdimensioniertem Aktor Vieles abdecken zu können. Dafür wird eine Skalierung mit etwas Hintergrundwissen über den Prozess nötig.

Ausblick

Der DNNC wird weiterhin von mir optimiert werden und gelegentlich geupdatet. Ich werde wohl in den nächsten Wochen sehen wie stabil mein Webservice läuft, wenn viele Anfragen kommen sollten. Hier fehlt es mir noch an Erfahrungswerten.

In Planung ist schon ein Jupyther-Notebook, dass ein paar Simulationen präsentiert und noch einige Anwender-Wissenslücken schließen soll. Außerdem habe ich noch gar nicht gezeigt, wie robust der DNNC bei 1 % Messrauschen und Lastsprung reagiert usw.

 

FAQ

Das Kühlwasser unserer Brennstäbe konnte der DNNC leider nicht regeln. Wo kann ich die Kosten, die durch den Super-GAU entstanden sind, einfordern?

Bitte diesen Service auf eigene Verantwortung verwenden und zuvor sinnvolle kritische Abschaltschwellen festlegen.

Mein self balancing robot fällt immer wieder um. Was mache ich falsch?

1. kein PTxDT System – könnte funktionieren, jedoch nicht getestet

2. Die Offline-Version des Reglers wird von mir mit 200 us Rechenzeit auf einem CortexM4 abgeschätzt. Für diese Onlineversion empfehle ich es mit weniger Gravitation zu versuchen.

Ist das Projekt open source?

Nein, der Regler an sich ist nicht open source. Jedoch werde ich einige Randbereiche davon veröffentlichen, z.B. die Simulation von PTxDT Systemen mit Python und später das Gerüst meines Flask Backends. Somit bleibt es auch für Hobbyisten weiterhin interessant.

Kann der DNNC auch nach der Stellenergie optimiert werden?

Derzeit gibt es meinerseits keine Bestrebungen dahingehend. Evtl. kann man einen zusätzlichen Tiefpassfilter zwischen Ausgang DNNC und Aktor einbringen, der jedoch die Regelgüte senken wird.

memcpy speed with newlib

Kurzer Hinweis zur newlib auf einem ARM CortexM.

Es wird ganz gern auf einem CortexM die newlib nano verwendet (siehe STM32 CubeMX etc.). Jedoch sollte man sich bewusst werden, dass für ein paar lächerliche KB Flash die Performance einer Funktion ganz rapide abnimmt: memcpy

Da memcpy z.B. auch im FreeRTOS und in so ziemlich jeder anderen Bibliothek intensiv verwendet wird, kann dies ein ziemlicher Performance-Killer sein.

Beispiel auf einem STM32H7 mit 400 MHz takt (200 MHz RAM Anbindung, D-Cache off) 1024 Byte memcpy vom Flash zum RAM:

eigene memcpy64: 3,8 us

memcpy ohne linker option „-specs=nano.specs„: 5,8 us

eigene memcpy32: 5,8 us

memcpy mit linker option „-specs=nano.specs„: 25 us

Der STM32H7 besitzt einen 64 Bit großen AXI-BUS und kann auch den Flash mit nur zwei wait states lesen, daher ist die 64 Bit Variante die schnellste. Für das „Schlachtschiff“ H7 könnte die newlib demnach noch etwas optimiert werden.

Wird die newlib im nano-Format eingesetzt, wird jedes Byte einzeln angefasst. Ansonsten wird auf einen Blocktransfer gewechselt. Siehe: https://github.com/eblot/newlib/blob/master/newlib/libc/string/memcpy.c

Deutlich zu sehen, dass die Performance um das 4 bis 5 fache gesteigert werden kann. Besonders praktisch ist es, wenn das RTOS beim Queue befüllen kürzer in der critical section verbringt.

Dieser weiterführende Blogbeitrag hat weniger dramatische Performance-Einbrüche festgestellt:

https://www.embedded.com/design/configurable-systems/4024961/Optimizing-Memcpy-improves-speed

Funkklingel mit Bestandsklingelanlage verbinden

In unserer neuen Wohnung haben wir eine Video-Klingelanlage von TCS. Benötigt wird die Anlage mit Videofunktion nicht wirklich, da wir im Erdgeschoss wohnen und unseren eigene Haustür haben, also ohne Etagentür.

Nun haben wir aber auch Garten auf der anderen Hausseite und bei zugezogener Balkontür hören wir die Klingel nicht. Lösung wäre an den TSC-Bus einen TSC-Funkgong anzulernen, das wäre für 120 € möglich.

Oder ein kleiner Hack?

Lösung: Obi Funkgong für 16 €, also fast ein zehntel des Preises! Nur ist ein weiterer Klingelknopf mit der Aufschrift „Garten“ wenig schön. Die Sprechanlage hat jedoch die bei uns ungenutzte Funktion, das Türschloss zu betätigen. Ein Ausgang mit 12-24 V Wechselspannung. Schon mal besser als nichts. Im Datenblatt der Sprechanlage findet sich auch die Tastenkombination für das „Installer Menu“. Darin kann eine bestimmte Funktion freigeschalten werden: immer wenn jemand Klingelt summt die Tür bzw. das Türschloss. Dies ist z.B. für Arztpraxen geeignet, die Ihre Kunden zu den Sprechzeiten hereinlassen möchten.

Mein Gedanke war zuerst: Die 12 V AC versorgen den Funktaster mit Spannung und der Taster wird einfach gebrückt. Ein kurzer Test zeigt: es wird eine Flanke am Taster benötigt, sonst klingelt nichts. Also Batterie einlegen bei gedrückten Knopf ergibt keine Reaktion.

Ich hätte eine Verzögerungsschaltung mit einem Tiefpass bauen können, aber ich hab mich dafür entschieden die Batterie beizubehalten. Die einfache Schaltung in Worten sieht nun so aus:

– Wechselspannung mit einfacher Diode gleichrichten

– Kondensator zur Glättung

– Basisvorwiderstand eines NPN weit in der Übersteuerung bestimmen + NPN über den Funktaster löten. Da dieser beim Drücken das Signal (3,3 V – Pullup) auf GND zieht.

– Drähte an GND und Diodeneingang. Fertig!

Ohne viel Text zieht der Hack dann so aus:

Wer die Schaltungserklärung nicht versteht, kann gern einen Kommentar dalassen, dann erstelle ich noch einen Schaltplan, wenn ich nicht gerade mit dem Handy auf dem Blog schreibe.

Flaschenwärmer Dilemma – Nespresso Aeroccino Hack

Leider komme ich in nächster Zeit nicht mehr so häufig zum Bloggen, da meine Frau und ich unsere beiden Zwillingsmäuse versorgen müssen. Man kann sich vorstellen, hier ist viel zu tun. Um so schlimmer, wenn es an so einfachen Dingen scheitert: möglichst schnell und effektiv die Milch auf 37 °C zu erhitzen!

Prinzipiell gibt es zwei verschiedene Systeme im unteren Preissegment auf dem Markt. Entweder man lässt im Flaschenwärmer Wasser verdampfen und die aufsteigende warme Luft erwärmt die Milch/Pre-Nahrung oder es ist ein Wasserbad das recht zügig warm wird. Leider muss man Milch aus dem Kühlschrank und Wasser mit Zimmertemperatur und unterschiedliche Füllmengen beachten. Dadurch wurde unsere Milch immer zu warm (42 °C) oder auch mal zu kalt. Nach den 3,5 Minuten ist man also mit herunterkühlen beschäftigt.

Das Wasserbadsystem bringt die Pfütze Wasser schnell zum Kochen. Nach ca. 4,5 Minuten ist die Milch gut temperiert. Leider muss man fast die ganze Zeit daneben stehen und messen, wann man die Milch herausnehmen kann. Zum Ende gewinnt die Milch in 2 Sekunden 1 Grad. Da muss man wachsam sein und kann sich nicht nebenher noch um andere Sachen kümmern. Was bei Schlafmangel und schreienden Kindern im Hintergrund nicht wirklich einfach ist. Wenn man Pech hat, ist man in der Spüle wieder mit herunterkühlen beschäftigt.

Im 21. Jahrhundert soll es keinen ordentlichen Flaschenwärmer geben? Uns würde es ja auch genügen, wenn man den Inhalt wärmen kann, ohne dabei wie ein Wachhund daneben stehen zu müssen.

So kam ich darauf unseren Nespresso Milchaufschäumer zu modifizieren. Der Aufschäumer hat auch einen zweiten Aufsatz, der die Milch nur rühren kann. Da Babys Milchschaum mit Spucken quittieren, sollte man auch besser nur diesen Aufsatz verwenden 😉 Weiterhin lässt sich der Aufschäumer ganz wunderbar reinigen und mit kochendem Wasser einmal am Tag desinfizieren.

Das Problem war natürlich, dass die Milch auf ca. 60°C erhitzt wird. Also aufgeschraubt und die Schaltung analysiert: Die Heizung wird mit 230 V betrieben und über ein 9 V Relais eingeschalten. Das Rührwerk besteht aus einem 9 V DC Motor, der per Transistor zugeschalten wird. Die 9 V werden von einem nicht galvanisch getrenntem Schaltnetzteil bereitgestellt und für den Mikrocontroller ATTINY44A mit einem 78L05 auf 5 V heruntergeregelt. Die Temperaturmessung erfolgt über einen NTC und 47 kOhm Spannungsteiler an den Analogeingang eins des Tinys.

Draufsicht der PCB

NTC kann von der PCB abgezogen werden

Obwohl es mich reizen würde ein neues Programm für den Tiny zu schreiben, fehlt mir leider hierfür die Zeit. Mein Angriffspunkt war gefunden: der Spannungsteiler des NTCs. Dazu musste ich erst herausfinden welche Kennlinie der NTC aufweißt. Dazu habe ich genau zwei Messpunkte aufnehmen können:

• kochendes Wasser 100 °C:
• aktuelle Zimmertemperatur 25 °C (ja es wird hier im Sommer warm :-/):

Mit Hilfe dieser praktischen Tabelle von dieser Seite, konnte ich recht einfach den B-Wert des NTCs bestimmen und direkt die ADC-Rohrwerte ablesen. Ein hoch auf den Autor dieser Seite/Tabelle.

http://www.afug-info.de/Download/tab/NTC/

Für meine Versuche habe ich die 47 kOhm entfernt und ein langes Kabel mit einem 250 kOhm Spindelpotentiometer angelötet. Als ich mit der Tabelle die neue grobe Richtung ausgemacht habe (ca. 110 kOhm) konnte ich die ersten Tests fahren.

Poti stat fixem Widerstand (Testlauf)

Testlauf mit Spidelpotentiometer

hier noch einen Tick zu kalt

Der neue „Milchaufwärmer“ ist bei unterschiedlichen Füllmengen etwas am driften. Es ist klar, dass beim Abschalten von 100 ml (min -> sonst spritzt der Rühraufsatz) Flüssigkeit noch viel mehr nachgeheizt wird, als bei 250 ml (max -> sonst läuft es über). Für mich ist der neue Widerstand 125.600 Ohm ideal (120 k + 5,6 k in Serie). 250 ml werden auf ca. 38,5 °C erwärmt und kühlen beim Gießen in die Fläschchen auf ca. 37 °C herunter. Weiterhin hat der ATTINY ADC pro Grad noch ca. 8 Digits und nichts geht im Rauschen des ADCs unter!

 

Ein kleiner Wermutstropfen ist die Hysterese. Wird ca. 33 °C warme Flüssigkeit eingegossen, springt die Heizung nicht an. Dies ist aber auch kein UseCase für uns. Bei abgekochtem Wasser mit Zimmertemperatur (bis 28 °C) ist es kein Problem.

Möchte man nach dem erhitzen noch Pre-Nahrung einrühren ist es ideal die Taste für zwei Sekunden zu drücken, dann springt nur der Rührer ohne Heizung an und man kann die passenden Messlöffel dazu geben. Andererseits muss man das Gerät dann wieder ausspülen und man kann natürlich auch das Fläschchen schütteln.

Wie bei allen Flaschen- und Milchwärmern gilt natürlich Kopf einschalten! Das Gerät kann 1000 mal funtionieren und dann die Milch viel zu heiß machen. Fühlen und Nachmessen bleibt also auch bei dieser Konstruktion pflicht.

Hinweise zum Öffnen:

Für die Spezialschrauben auf der Unterseite lässt sich recht einfach ein passender Schlitzschraubendreher finden. Nach dem Aufschrauben (Schrauben fallen nicht heraus) bitte nur mit der Hand den metallenen Teil nach oben ziehen. Der Taster bleibt drin und darf nicht versucht werden vorher herauszubekommen, da ihr ihn sonst beschädigt. Das Unterteil und das Oberteil sind nur durch einen O-Dichtring und zwei Steckkontakten gehalten. Es sollte auch nicht zu sehr oder gar nicht gedreht werden, beim herausziehen.

Fazit:

Meine Frau und ich sind absolut zu frieden. Wir können innerhalb von 25 Sekunden auf Knopfdruck die kühlschrankkalte Milch auf 38 °C erwärmen und müssen dazu nicht mal daneben stehen, da es passend abschaltet. In die Fläschchen kippen, noch mal nachmessen und fertig! Das spart Nerven!

Der umgebaute Aeroccino ist von seinem orginalem Kollegen nicht zu unterscheiden.