1.6 dev environment
I know you all want to get started.
However, here are a few introductory words on how to create a 'work environment' for lua development that takes advantage of existing tools, especially on the topics of editors and the Ethos simulator.
Anyone who is already programming will want to continue using their 'favorite editor.'
Those who are just starting and wondering which editor to use, I would like to give two recommendations:
An open-source/free software project that is widely used. Advantages are easy application, 'lua' enabled (color coding/highlighting of coding), it is portable, has several additional add-ons, etc.
Definitely widely used and welcome if quick familiarization and easy application are more important than the number of features.
As the name suggests, from Microsoft. VS Code is also free, functionally even more extensive than Notepad++. If you want to publish your projects on GitHub, VS Code is especially suitable because there are add-ons to synchronize files directly with git (push/pull/commit, etc.).
VS Code can be extremely customized, but it requires corresponding familiarization with the config files. The lua code support 'out of the box' is even more extensive than with Notepad++, e.g., you can already see in color whether defined variables or functions are actually used in the coding (colored gray, etc.). VS Code has more functionality than Notepad++, but it also requires more familiarization time.
[VS Code Webseite](https://code.visualstudio.com/) 
The Ethos simulator is an excellent tool to test your scripts during the development phase without needing the transmitter. It is currently only available for Windows and Linux. It is possible to run it in under Windows in a virtual machine on a Mac.
Firstly, the PC/notebook/Mac has significantly more performance overall, and you can work somewhat more smoothly than directly on the transmitter. 'Coding > Testing > Analyzing > Coding' cycles are simply faster on the simulator.
Additionally, the transmitter does not wear out as quickly. On the other hand, there are of course limitations, as not all functions (e.g., trim operation, certain telemetry situations) can be replicated (as of Ethos 1.5.x). Personally, I use the simulator for around 90% of development efforts.
The latest simulator can be found in the latest Ethos release (latest) on GitHub.
The simulator is mainly operated via mouse.
Control elements such as switches, sticks, etc., are emulated via the keyboard. (If you do not have a numeric keypad, you can use the Windows On-Screen Keyboard ( Go to Start , then select Settings > Accessibility > Keyboard, and turn on the On-Screen Keyboard toggle. )
To replicate telemetry on the simulator (only fixed values), the RF module must be turned on in the simulator. If the model memory does not yet have telemetry sensors, then define them in the telemetry menu via the 'Discover new sensors’. All typical sensors will be found.
**Starting from version 1.5.12, the use of folders and paths has been significantly redesigned. **
Previously, model files were centrally stored in the user environment, while the simulator itself ran with all other folders (audio, bitmaps, scripts, etc.) in its installation path.
For each "environment," such as specific simulator releases, betas, work environments, development environments, etc., a separate installation was necessary, sharing a model directory.
This led to problems when using simulators of different release versions simultaneously.
Now (version 1.5.12), a hardware-specific "user environment" is created under the ".ethos" folder in the Windows user path.
It contains the folders logs, models, and scripts, as well as the radio.bin file including transmitter settings. All other folders are located in the installation path:
**Starting from version 1.5.12, parameters can be used to specify which specific folder is used for which specific purpose (audio, system, scripts, etc.) when starting a simulator (re-routing). **
-
--system-directory: System directory (e.g., i18n, bitmaps) -
--user-directory: Typical user directories (logs, models, etc.) -
--scripts-directory: Folder for scripts -
--radio-settings: Specifies a dedicated "radio.bin" file
set SIMEXE=D:\Programme_U\Ethos\x18.12
set SIM=0 environment A
d:
cd %SIMEXE%
simulator.exe --system-directory "D:\Programme_U\Ethos\x18 n\%SIM%\system" --user-directory "D:\Programme_U\Ethos\x18 n\%SIM%" --scripts-directory "D:\Programme_U\Ethos\x18 n\%SIM%\scripts"
The folder of the work environment "0 environment A" should then look like this: ("own" sound files, model files, scripts, radio.bin)
Another work environment could be easily created without additional simulator installation by using another customized batch file and another "environment folder," e.g.: ** „0 environment B“**
Der Simulator kann ein Debug-Fenster zur Verfügung stellen, in dem alle Systemmeldungen inklusive Lua-Debug-Code und Fehler präsentiert werden. (Lua-Debug-Code ist nichts anderes als ein print-Befehl in bestimmten Codezeilen, um Statusinfos und Werte im Ablauf auszugeben.)
Um das Debug-Fenster im Simulator zu erhalten, muss der Simulator über die Command-Shell gestartet werden:
Beispiel:
- Command-Shell öffnen (
cmd.exe) - In das Verzeichnis des Simulators navigieren
- Eingabe:
simulator.exe
Alternativ kann ein Batch-File generiert und gestartet werden, z.B. für einen Simulator, der unter D:\Programme\Ethos\X18 installiert wurde:
d:
cd "D:\Programme\Ethos\X18"
"D:\Programme\Ethos\X18\simulator.exe"Links erscheint das Debug-Fenster zum gestarteten Simulator (rechts, Teilausschnitt).
Die Ethos Suite kann ebenfalls während der Lua-Script-Entwicklung genutzt werden.
Sie wird meistens „on top“ zum Simulator angewendet. Der Simulator stellt z.B. ausschließlich konstante Telemetriewerte zur Verfügung, kann derzeit Trimmereingaben nicht entsprechend verarbeiten und zeigt ein anderes Performanceverhalten auf. Ab dem Moment, wo ein „Real-World“-Testing notwendig ist, kommt die Suite zum Einsatz.
Dabei wird der Sender (z.B. im Suite-Modus) mit dem Rechner verbunden und die Suite gestartet. Durch Verwendung der Suite im „Dev-Tool-Menü“ kann der Sender durch die Suite gesteuert zwischen Betriebsmodus und Entwicklermodus umgeschaltet werden.
Der „Entwicklermodus“ ist quasi der Suite-Modus mit gemounteten Laufwerken, sodass die Lua-Files einem Editor zur Verfügung stehen. Ist ein Lua-File des Senders im Editor geöffnet, sollte der Editor in der Lage sein, das File im Speicher zu halten, auch wenn die Datei im Betriebsmodus des Senders gerade nicht zur Verfügung steht.
Durch diese Art der Umschaltung lassen sich schnell Anpassungen im Code vornehmen und praktisch testen. Es muss kein Kabel umgesteckt werden, und der Sender muss nicht manuell in den Suite-/Seriell-Modus versetzt werden.
Der besondere und wesentliche Vorteil liegt darin, dass einem direkt ein Terminalfenster zur Verfügung steht, in dem Debug-Informationen des Senders in Echtzeit dargestellt werden können. Diese Debug-Infos sind außerordentlich hilfreich bei der Suche nach Fehlern und deren Ursachen.
Wenn im Testmodus auch das Modell eingeschaltet werden sollte: Um beim Umschalten Schäden durch versehentliches Anlaufen von Antriebsmotoren etc. zu verhindern, müssen Propeller demontiert werden und ggf., je nach Modellkonfiguration, weitere Sicherheitsmaßnahmen getroffen werden.
Gerade wurde von Debug-Informationen gesprochen. Was versteht man darunter?
Allgemein gesagt, ist Debug-Information alles an (textlicher) Information des Senders oder des Simulators, was dem Entwickler hilft, Fehler und deren Ursachen aufzuspüren.
Beispiel: gerade wurde beschrieben, wie das debug Fenster im Sim gestartet wird. Nehmen wir nun an, der Simulator zeigt im Script einen Fehler an:
die Zeile 2507 im main.lua konnte also nicht ausgeführt werden.
Schauen wir uns den Codebereich an:
Es sollte der Wert einer Telemetriequelle (source) der Variablen sourceVal zugewiesen werden, das funktionierte nicht. Offensichtlich ist die Quelle nicht angelegt angelegt worden (Fehlermeldung „..nil value (local‘source`)“
Schauen wir uns an, welchen Namen der Sensor in dem Moment hatte. Dazu ergänzen wir den Code und lassen uns via print Befehl etwas „debug Infos“ ausgeben:
Der Sim gibt nun aus:
Als Name eines Telemetriesensors ist „5“ bestimmt falsch, sorgen wir im Coding also für den richtigen Sensornamen (z.B. „RSSI“), ist der Fehler behoben.
Im debug Fenster des Sims werden solche Infos einfach ermöglicht.
Wie aber erhalte ich debug Infos direkt vom Sender ? Eine Möglichkeit wurde gerade beschrieben: via Suite und den dev-tools. Dort existiert ein Terminalfenster, was die Informationen darstellt.
Welche Alternative gibt es?
Dazu muss man wissen, dass diese Infos als eine Art „serielle Textübertragung“ via USB gesendet werden.
Die Technik der seriellen Übertragung gibt es fast seit Anfang der Computertechnik, ein HW Standard der seriellen Übertragung war einmal die RS232 Schnittstelle, die immer noch via USB emuliert werden kann.
Zur Darstellung verwenden wir mit Sicherheit kein antikes Textterminal (es sei denn jemand besitzt z.B. noch DEC VT510 Geräte..) sondern wir überlassen das einer Software App.
Eine sehr geläufige und kostenlose Anwendung ist das Programm „Putty“:
Download Putty
Diese App visualisiert die Daten (Textnachrichten), die aus dem Sender kommen.
Die Daten werden in einer bestimmten Geschwindigkeit gesendet und „landen“ auf einer bestimmten „virtuellen“ Schnittstelle per Emulation. Ist das Programm Putty installiert, muss zunächst diese Kommunikationsschnittstelle eingerichtet werden.
Prinzipiell ist es möglich, dass mehrere Geräte zeitgleich seriell mit einem Rechner kommunizieren wollen. Jedes Endgerät muss dazu eine eigene Schnittstelle „bedienen“. Die früheren physikalischen RS232- bzw. „Com“- (Communication-) Schnittstellen waren am Host daher mehrfach vorhanden und durchnummeriert (Com1: bis Com32: und mehr). Die USB-Schnittstelle emuliert nun einen bestimmten Port, je nachdem auf welchem USB-Port der Sender verbunden wurde, welche OS-Version genutzt wird, und welcher Treiber installiert ist.
Wir müssen via Gerätemanager herausfinden, auf welchem Port der Sender zugewiesen wurde. Dazu wird der Sender mit dem Rechner verbunden und in den seriellen Modus versetzt.
Öffne den Gerätemanager und überprüfe, auf welche sogenannte COM-Schnittstelle der Sender verbunden wurde.
Unter Putty definieren wir nun eine Sitzung mit genau dieser COM-Schnittstelle und den Parametern 115000 Baud (Geschwindigkeit). Diese Angaben sind im Bild rot markiert:
Wir speichern die Sitzung unter einen eindeutigen Namen (z.B. „ethos 11“) und drücken „Save/Speichern“ (blau)
Jetzt kann man per „öffnen/open“ ein Terminalenster starten, das uns Infos vom Sender ausgibt.