DaRUS (University of Stuttgart)
Not a member yet
2037 research outputs found
Sort by
Experiment Videos on Setpoint Stabilization of Nonholonomic Mobile Robots and Their Formations Using Geometry-Conforming Model Predictive Control
No full textThe provided videos document experimental results on setpoint stabilization of various wheeled mobile robots and their formations using tailored model predictive control (MPC) schemes. The controllers are formulated at the kinematic level, i.e., they employ kinematic models of the robots to predict their future behavior and use the robots' velocities as control inputs. The resulting velocity commands are then executed by onboard low-level velocity controllers running at 100 Hz. Three different robot kinematics are considered: a differential-drive robot, the same kinematics with an attached trailer, and a rear-wheel-driven car-like robot. In addition to single-robot control, the stabilization of differential-drive robot formations is also demonstrated using a distributed realization of the proposed geometry-conforming model predictive controllers. For each case, two MPC variants without additional stabilizing constraints or costs are implemented and experimentally evaluated. First, MPC schemes employing tailored, geometry-conforming stage costs are used. The resulting closed-loop trajectories of the robot positions are shown as orange lines in the videos, while the desired setpoints are indicated by red crosses. Second, for comparison, MPC schemes based on conventional quadratic stage costs are implemented, with all other controller parameters kept identical. The corresponding closed-loop trajectories are shown as solid green lines in the videos. For the considered formation control scenarios, the formation mean is additionally highlighted by a dashed violet line. For more details on the implementation of the controllers and the actual parameters used, please refer to the related publication.
The experiments demonstrate that only the controllers employing the tailored geometry-conforming stage costs are able to reliably steer the robots to the desired setpoints with high accuracy. This finding also holds for the formation control of multiple differential-drive robots. In contrast, controllers based on conventional quadratic stage costs fail to achieve reliable setpoint stabilization. This is a direct consequence of the underlying nonholonomic geometry of the considered wheeled mobile robots, which is not adequately captured by quadratic stage costs. At a high level, interpreting the state-dependent part of the stage cost as a distance measure to the desired setpoint highlights the inherent problem of conventional quadratic stage costs. For nonholonomic systems, the distance between two configurations cannot be represented by the Euclidean distance in the state space, not even locally.
Instead, meaningful distances must be measured along feasible paths that respect the nonholonomic constraints. To account for this, concepts from sub-Riemannian geometry are incorporated into the design of the geometry-conforming stage costs, resulting in cost functions with mixed exponents. Intuitively, directions that are harder to control are penalized more strongly close to the desired setpoint than directions that are easier to control.
The naming of the videos follows the appearance in the related publication.
Note that, while trajectories corresponding to quadratic stage cost controllers are shown as dashed green lines in the related publication for visual clarity, they are displayed as solid green lines in the provided videos. In addition to the standard Cartesian coordinate formulation, supplementary videos are provided in which the controllers for the differential-drive robot are based on a polar coordinate representation, both for the single-robot control task and for the formation control scenario. This way, the single-robot robot and the formation locally approach their desired setpoints along circular arcs rather than straight-line paths
Replication Data for: "Ethylene Oligomerization Under Confinement Using Supported Cr(II) and Cr(III) Catalysts"
No full textAll primary data files (NMR, GC-MS, BET, DSC, ICP-OES and XAS) associated with this publication can be found here. Synthesized ligands (L1-L2, CAAC-1) and polymers (PEs) were characterized via nuclear magnetic resonance (NMR) spectroscopy and the spectra can be found in NMR folder. BET data, DSC data, XAS data and GC-MS and NMR Spectra are specified according to the numbering in the publication
Precipitable Water Vapor Tables from ECMWF ERA5 Re-Analysis for SOFIA FIFI-LS Flights
No full textSOFIA Precipitable Water Vapor (PWV) Products for all flights with FIFI-LS between the year 2014 and 2022.
Each FITS file contains a HDU "DATA", which is a binary table extension with columns for
Precipitable Water Vapor (PWV), Longitude, Latitude and Atmospheric Pressure
as a function of in-flight time. The source for positional data
is the primary GPS sensor of SOFIA (see POSSRC keyword).
PWV values were derived from the ERA5 Re-Analysis from ECMWF
(Hersbach, H., 2020, DOI:10.1002/qj.3803).
Note: For use of PWV values for atmospheric transmission correction
by the instrument pipeline software, a specific instrument dependent
conversion must be performed. Please refer to the respective
documentation in the SOFIA Redux module for FIFI-LS for further details.
Derivation of the ECMWF PWV values and specific instrument
correlations for FIFI-LS are explained in detail in, e.g.,
Fischer et al., 2021, DOI:10.1088/1538-3873/abf1ca and
Iserlohe et al., 2021, DOI:10.1088/1538-3873/abef76.
Percentiles, Pk, for given geographical position and flight altitude
of SOFIA and season of the observations are derived
from a 10 year statistics presented in
Iserlohe et al., 2022, DOI:10.1088/1538-3873/ac82c5.
Pk means that there is a k% probability of observing a PWV value less than Pk in flight.
The FITS files also contain some water vapor maps of the region of the flight path for data validation purposes.
</p
Replication Data and Scripts for: Asymmetric Ionic Liquids for Enhanced Performance of Nanoporous Electrical Double Layer Capacitors
No full textSimulation data and scripts accompanying the paper "Asymmetric Ionic Liquids for Enhanced Performance of Nanoporous Electrical Double Layer Capacitors". This dataset contains videos, plot_data and the scripts from MD-Simulations of asymmetric ionic liquid models in a plate-capacitor. For details about the files, please refer to the README
Data for: "The Effect of Particle Shape on their Trajectories in Particle Laden Flows"
No full textThis dataset contains the scanning electron microscope (SEM) images that are used for the particle shape analysis. The images are generated with the TESCAN Vega3 microscope. The uploaded images are the raw images. Three sample holders are scanned. The images are the basis for the analysis in the Conference Paper "The Effect of Particle Shape on their Trajectories in Particle Laden Flows" presented at AIAA SciTech 2026. (2025-12-09
Twico Control Engine
No full text
Twico Control Engine
Twico Control Engine
Twico Control is a Flask-based orchestration engine for digital materialisation /
digital twin workflows.
It coordinates virtual actors (software representations) and their paired
physical actors (robots, tools, sensors), executes tasks in a controlled order,
forward information to external services, and optionally synchronises state of the local DB with a
cloud database via REST API.
A web UI is included for managing actors, tasks, jobs, and monitoring execution.
Status: research / prototyping-friendly codebase. Contributions and issues are welcome.
What problem it solves
In a typical digital materialisation process you have:
Tasks to execute (move, read data, fabricate, etc.)
Physical actors that do the work (robots, PLCs, devices)
Virtual actors that encapsulate communication + pre/post-processing
Services that generate tasks or react to task completion
Twico Control acts as the execution core: it keeps a local “authoritative” state,
dispatches tasks to actors, listens for events, and updates external systems.
Key concepts
Actor (Virtual Actor): a Python class that implements a standard interface
(actors/ActorBase.py) and handles: connection, task preparation (preSend), task dispatch,
completion monitoring, and response handling (postSend).
Task: an executable unit that is assigned to a main_actor with extra per-actor
parameters under actors_data.
Engine: a Flask server that runs the UI + API endpoints and coordinates task execution.
RabbitMQ: optional event bus for “task received” / “task complete” style workflows.
Execution model (high level)
The engine runs continuously and coordinates execution across actors:
Ensure all required virtual actors are registered and connected.
For each available actor:
fetch the next task from the local DB (or tasks queue)
call preSend(task) then send the task to the paired physical actor
wait for completion / acknowledgements (depending on your communication pattern)
call postSend(response) and log results
trigger any linked services
In parallel, background listeners can:
ingest new tasks (e.g. via RabbitMQ)
propagate task completion updates to a cloud DB (if REST API is configurated)
Project structure
TWICO_Release/
├── actors/
│ ├── __init__.py
│ ├── ActorBase.py
│ ├── RMQ_setup.py
│ ├── DemoActor/
│ │ ├──__init__.py
│ │ └── DemoActor.py
│ ├── ServiceConnectedActor/
│ │ ├──__init__.py
│ │ └── ServiceConnectedActor.py
│ └── TaskInjectingActor/
│ │ ├──__init__.py
│ └── TaskInjectingActor.py
├── apps/
│ ├── actors/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── authentication/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── home/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── Logger/
│ │ ├──__init__.py
│ │ ├── logs/
│ │ ├── Logger.py
│ ├── RabbitMQ/
│ │ ├──__init__.py
│ │ └── listener.py
│ ├── run/
│ │ ├──__init__.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── static/
│ │ └── assets/
│ ├── tasks/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── templates/
│ │ ├── actors/
│ │ ├── auth/
│ │ ├── dashboard/
│ │ ├── includes/
│ │ ├── layouts/
│ │ ├── run/
│ │ └── tasks/
│ ├── .env.example
│ ├── __init__.py
│ └── config.py
├── Examples/
│ ├── Basic/
│ │ ├── basic_tasks.py
│ ├── Parallel_actors/
│ │ ├── parallel_actors_tasks.py
│ ├── Self_injecting_actor/
│ │ ├── self_injecting_actor_tasks.py
│ ├── Task_injecting_service/
│ │ ├── task_injecting_service.py
│ │ ├── task_injecting_service_tasks.py
│ └── tasks_builder.py
├── .gitignore
├── CHANGELOG.md
├── CONTRIBUTING.md
├── docker-compose.yml
├── LICENSE
├── README.md
├── requirements.txt
└── run.py
Notable folders
actors/ — Virtual actor implementations (your integration layer)
ActorBase.py defines the interface for all actors
DemoActor/ provides an example actor
apps/ — Flask application code (blueprints, models, services)
apps/authentication/ login + license gating
apps/tasks/ task models, services, and UI routes
apps/actors/ actor registration/management in the UI
apps/RabbitMQ/ RabbitMQ listener
apps/Logger/ logging utilities
apps/templates/ HTML templates for the UI
apps/static/backups folder that save current state of tasks in the DB after execution or when
clearing tasks from DB.
Examples/ — example scripts and task JSON
Requirements
Python 3.10+
A virtualenv or conda environment (recommended)
Optional but recommended:
RabbitMQ server (local, Docker, or remote)
A REST API backend for cloud synchronisation (if you use that workflow)
Quick start (local)
1) Create and activate an environment
Using conda:
conda create -n Twico python=3.10
conda activate Twico
Or with venv:
python -m venv .venv
# Windows
.venv\Scripts\activate
2) Install dependencies
pip install -r requirements.txt
3) Configure environment variables
Create a .env in the project root (do not commit it) based on
.env.example.
AUTHOR_NAME=Your Name
APP_VERSION=0.1.0
SERVER_NAME=127.0.0.1:5000
SECRET_KEY=change-me
API_URL=
ASSETS_ROOT=/static/assets
DB_ENGINE=sqlite
DB_NAME=db.sqlite3
RABBIT_MQ_HOST=localhost
RABBIT_MQ_PORT=5672
RABBIT_MQ_USER=guest
RABBIT_MQ_PASS=guest
RABBIT_MQ_VH=/
4) Run
python run.py
Open the UI at:
http://127.0.0.1:5000
Working with tasks
Tasks can be loaded from:
the cloud REST API (if configured)
a local JSON file (see Examples folder)
A task have the following structure:
{
"name": "A_temp_0",
"type": "Move",
"main_actor": "DemoActor_A",
"description": "",
"message": "Moving DemoActor to position",
"job": 1,
"level": 1,
"index": 0,
"element_id": [],
"actors_data": {
"DemoActor_A": {
"X": 1,
"Y": 2,
"Z": 3,
"Speed": 0.2
}
}
}
where the actors_data feild can contain any key-value pair.
Adding a new actor
Create a new folder under actors/ (e.g. actors/MyRobotActor/)
Implement the interface in ActorBase (connect, send, monitor, etc.)
Make sure the file name and the class name are the same as the folder name.
Ensure the actor is importable (package with __init__.py)
Register/configure it via the UI (apps/actors/) or your project-specific bootstrap code
RabbitMQ (optional)
If you use RabbitMQ, you can run a local instance with Docker:
docker compose up -d rabbitmq
See docker-compose.yml in this repo for a ready-to-use configuration.
Documentation
This repository is compatible with Sphinx autodoc (docstrings → HTML docs).
If you add a docs/ folder, you can build API docs automatically.
Docs for the folder can be found in apps/static/docs or under the docs in the UI navigation sidebar.
Author / Maintainers
Lior Skoury (original author)
</html
Data for: Feed injection in liquid chromatography: Reducing the effect of large-volume injections from purely organic diluents in reversed-phase liquid chromatography
No full textPrimary data files and processed data of the journal article from the Tallarek Group. Data was generated by a diode-array detector (DAD). The recorded peaks were evaluated using total numerical integration to determine their first and second statistical moments, corresponding to the center of mass and variance. The reported plate heights (H) represent the average of duplicate measurements for the analyzed compounds. The numbers 0.25-19 indicate the Qr-value, which is the ratio between the feed injection speed and the volumetric flow rate of the mobile phase
Replication Data for: Time-Optimal Feedrate Planning for Real-Time CNC Machining via Transformation Between Parametric and Time Spaces
No full textSimulation and experimental dataset for feedrate optimization algorithm validated on the KUKA KR210 robot and an industrial milling machine.
This dataset belongs to the publication "Time-optimal feedrate planning for real-time CNC machining via transformation between parametric and time spaces" (doi: 10.1016/j.jmapro.2026.01.016) A detailed description of the setup can be found in the publication.
The dataset contains the following folders (Feel free to contact the dataset owner if you have any questions about the dataset)
Simulation 1
Planning results in simulation study 1 on the KUKA KR210 robot, where the spline parameters, generated setpoints, and runtime measurements are provided.
Simulation 2
Benchmark results with the state of the art in simulation study 2 on a two-axis bufferfly-shaped toolpath. The spline parameters, generated setpoints and the related g-code are provided.
Simulation 3
Analysis of the regularization in simulation study 3, where the resulting jerk fft values and finishing times are provided with their corresponding regularization factors.
Experiment
Experimental validation with 3D freeform tracking on an industrial milling machine. The generated setpoints, spline parameters of the toolpath, and the measured motion data on the machine are provided, along with the associated g-code for the numerical control kernel.
</ul
Supplementary Material for Sequential Quadratic Sum-of-squares Programming for Nonlinear Control Systems
No full textThis repository contains supplementary material for the paper "Sequential Quadratic Sum-of-squares Programming for Nonlinear Control Systems" submitted to IEEE Transactions on Control Systems Technology. It contains the MATLAB source code to reproduce the results from the paper.Requirements and Setup:
The example package itself does not not need to be installed. Only CaΣoS,
MOSEK v11.1 and
CasADI v3.6.7 are needed.
1. Download CasADi v3.6.7 and add it to your Matlab path.
2. Download and install MOSEK, and add the solver to the Matlab path.
3. Add the CaΣoS root folder (the one that contains the directory +casos) to your Matlab path.
If installed correctly, you can execute the corresponding files as outlined below for reproduction. Unzip the corresponding folder and execute the desired MATLAB script.
The files can be also found in the corresponding
Github Repository.
In case you encounter any issues or for questions, please contact the corresponding authors
Atmospheric transmission models for FIFI-LS: altitude 36kft, 39deg O3
No full textThis dataset contains atmospheric transmission models calculated by a modified version of ATRAN ("SDC ATRAN"). They are to be used as the default models for FIFI-LS data reduction with SOFIA Redux
The models are generated from a modified "SDC ATRAN" model based on Steve Lord's ATRAN. The most significant modification is a correction of 17O16O isotopologue abundance coefficients.
The models are stored in FITS binary table format with the columns "wavelength" and "transmission". All models of the same altitude (and same wavelength range) have the same number of wavelength elements.
File naming convention:
atran_sdc_xxK_yydeg_zzpwv_39deg_2nlayer_40-300mum_bt.fits
where xx is the flight altitude in kft, yy is the zenith angle in degree, and zz the
precipitable water vapor value in micron.
This dataset contains models calculated for a 2 layer atmospheric model with an ozone profile identified by "39deg".</p