You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+44-31Lines changed: 44 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,33 @@
1
-
# Electrostatic-Library
2
-
> A library template utilizing the Electrostatic-Sandbox SDK, acting as an extension pack.
3
-
4
-
This is a template that builds a cross-platform native library for Linux variants, Android variants, and AVR MCU variants linking them against the Electrostatic-Sandbox SDK libraries. The library is built into static archives, and dynamic libraries. The template is also provided by `examples` module in which a single source file with a `main` function could be compiled and run on its respective system.
3) If planned Microcontroller development; ATMega32 and/or ATMega328p are the currently supported ones.
12
-
4) If planned Android development; all Android variants are supported.
1
+
# Delta-Engine
2
+
3
+
A realtime Newtonian-based physics and hardware engine library with an API designed to address problems of simulation and real object dynamics; the idea is to couple building a physics simulator with emulating IO using the same abstraction via polymorphism and encapsulation (e.g., building a human joint simulator on a 3D game engine and deploying it on a hardware stepper motor module to emulate the same motion using electronic components in a different system using the same code).
4
+
5
+
## General List of supported features
6
+
-[ ] N-dimensional Physics Spaces.
7
+
-[ ] CPU-based Realtime monitoring.
8
+
-[ ] Support for Classical Linear Newtonian Mechanics.
9
+
-[ ] Support for Classical Rotational Newtonian Mechanics.
10
+
-[ ] Operates its pipeline using Newton's Laws of Motion.
11
+
-[ ] Uses pure vectorial structures from the _Electrostatic SDK_.
12
+
-[ ] Wires the software simulation with your hardware abstraction layer that controls the outside environment based on the provided physical model.
13
+
14
+
## Problems and solutions preview
15
+
| Problems | Solutions |
16
+
|----------|-----------|
17
+
| N-dimensionality: ||
18
+
| Creating physics spaces: ||
19
+
| Motion-based runtime environment: ||
20
+
| Attaching and detaching objects with physical properties: ||
21
+
| Equilibrium and forces: ||
22
+
| Transforming objects using external linear momentums: ||
23
+
| Transforming objects using external linear forces: ||
24
+
| Transforming objects using external angular momentums: ||
25
+
| Transforming objects using external angular forces: ||
26
+
| Transforming objects using other objects in space (Newton's third law): ||
27
+
| Collision detection of objects in the physics space: ||
28
+
| Collision avoiding objects in the physics space: ||
29
+
| Updating objects in realtime based on CPU slices: ||
30
+
| Physical objects groups and group physics: ||
13
31
14
32
## Setup the Electrostatic Environment
15
33
This will install missing dependencies (CLI tools and toolchains) in `/opt/electrostatic-sandbox` that shall be utilized by the SDK build front-end and CMake to build the applications.
@@ -18,6 +36,20 @@ This will install missing dependencies (CLI tools and toolchains) in `/opt/elect
> Windows devices will require Windows-Subsystem for Linux (WSL) and a distribution package to be installed; make sure to setup them on your machine via the powershell:
41
+
> 1) Run a new powershell or a windows terminal powershell session as administrator.
42
+
> 2) Set the execution policy of the current session for the current process as "Bypass" to enable running unauthorized scripts, which will be reverted normally to the default "restricted" policy when this session is over:
43
+
> ```powershell
44
+
> Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
45
+
> ```
46
+
> 3) Run the script:
47
+
> ```powershell
48
+
> setup-wsl-debian.ps1
49
+
> ```
50
+
> 4) Reboot if needed, and follow-on to enable BIOS/UEFI CPU virtualization if necessary.
51
+
> 5) The script enables the WSL and windows virtualization features, download WSL Debian Distribution binaries, and sets up the `usbipd` utility for routing usb ports across servers.
52
+
> 6) Continue with setting up and customizing your development environment.
21
53
22
54
## Build the application binary (.elf)
23
55
This will build the application binary to all supported platforms; usually if a new build routine is to be built, it has to go here.
Add your dependencies in the `libs` directory with the system directory of choice if required (in case of platform-dependent binaries); the build script finds all libraries listed under this directory through this code snippet:
## Adding new examples to test the introduced APIs
48
72
* Adding new examples could be achieved by creating new source code (single source files) under the `examples` module, and using the following command to compile and run the example:
> This command links the specified source example against the `Electrostatic-Sandbox SDK` libraries and the `Electroextension` library (your native library).
55
79
56
80
* Adding new examples for microcontroller programming is much the same, but will require uploading as a post-compilation script.
57
-
58
-
## Excluding parts of the source code (dissociating the source code into modules)
59
-
This could be attained through the build routines of the supported systems by decomposing the source directory into sub-directories and pass them as source modules to the compilation front-end (Ccoffee); the following shows the use of all the source code as a single module:
## Build front-end automata, CMake, and Toolchains
63
-
Essentially, the build architecture of the Electrostatic-Sandbox SDK is based on the idea of creating a front-end scripted API that creates a building automata, which entails taking an input and passing into a chain of states, and eventually ending with a terminal state; thus the recognition of the machine to the building holds if the terminal state is being reached by the program counter. The initial input to the automata is mainly a building routine instruction and the outputs are proceeded and could be found at the filesystems cmake-build and build, where the terminal output is produced.
64
-
65
-
The build of the Electrostatic-applications is much simpler than the SDK; it's literally a subset of it.
66
-
67
-
For more; refer to the [build architecture of the Electrostatic-Sandbox SDK](https://github.com/Electrostat-Lab/Electrostatic-Sandbox/blob/master/electrostatic-sandbox-framework/docs/system-build/architecture.md).
0 commit comments