Skip to content
EcoSimLab
DeutschEnglish
Docs navigation
How to work on repos

How to work on repos

Which repositories to clone per set and dev set — the actual setup steps then follow in the READMEs of the respective repos.

This page explains how to work on the EcoSimLab repos — for external and internal use alike. Externally: for open-source contributors who want to work on a single tool without setting up the whole stack. Internally: as an overview that is otherwise only passed on by word of mouth.

At its core it is a collection of links and clone targets: which repos to clone together, per set or dev set. From the clone onwards, the READMEs/docs of the individual repos take over — this page does not repeat any installation or setup steps (guiding principle: the tool pages advertise, the docs instruct, no duplication — the same principle, one level up).

The specific clone commands and repo URLs are deliberately still missing here: the tool repos currently live in the internal GitLab (git.imis.uni-luebeck.de) and are not yet public. Once the repos have been published, the git clone links will be added per entry.

Dev-Sets

Usage sets (Lab, Video, LEM) cover finished use cases for researchers. Dev sets are smaller, purpose-built tool combinations for developing and testing the integration between two or more tools — they are not meant for running a study.

Important background: EcoSimLabPy without BeamNG makes no sense for real driving (for real data the two are effectively one package). “Tool X + EcoSimLabPy [+ BeamNG]” is therefore usually just the full live stack, not a self-contained, smaller dev set. The real lever for lightweight dev sets is a BeamNG mock that provides driving data directly via MQTT and thus replaces BeamNG.tech and EcoSimLabPy together (see the still open points below).

The following list is a draft — three of the five entries still rest on unconfirmed assumptions about the mock.

1 — SCA ↔ BeamNG (full stack) · confirmed

  • Repos: StudyControlApp · EcoSimLabPy · real BeamNG.tech
  • Purpose: test the MQTT connection against a real data stream. Example confirmed by Jan.

2 — SCA on its own · confirmed

  • Repos: StudyControlApp only (no data source)
  • Purpose: develop the frontend/backend/UI of the StudyControlApp without any driving data having to flow at all. Confirmed (Jan: “you can also develop the SCA on its own”).

3 — Any MQTT consumer ↔ BeamNG mock · unconfirmed (plausible)

  • Repos: an MQTT consumer (e.g. EcoInterfaces or StudyControlApp) · BeamNG mock
  • Purpose: lightweight integration test without real BeamNG.tech/EcoSimLabPy — the mock takes over both at once.
  • Still open: depends on the BeamNG mock existing and being usable (not yet settled, see below).

4 — Controller tuning needs the real stack · unconfirmed (plausible)

  • Repos: EcoMPC or Steering-Controller · vehicle models · EcoSimLabPy · real BeamNG.tech
  • Purpose: closed control loop — the controller reacts to the real physics response. A mock that only replays data presumably cannot react to it, so it is no substitute.
  • Still open: the assumption “the mock does not react to controller output” still needs to be checked with the team.

5 — Cockpit-Display-Replay ↔ real EcoInterfaces repo · confirmed (open task)

  • Repos: Cockpit-Display-Replay · EcoInterfaces (eco-displays) — no BeamNG needed
  • Purpose: a known pending task — switch the replay plugin over to the external eco-displays package instead of the old internal copy.

Still open

This page is still a skeleton; its scope and content are deliberately marked as open (a known open point from phase 0). Specifically still to be clarified:

  • Clarify the BeamNG mock in more detail — no repo has been reviewed, so far it has only been mentioned verbally (a documented gap in the inventory). It presumably publishes on the same MQTT topics as EcoSimLabPy (from_beamng_py/beamng_state among others), but with synthetic instead of real simulator data. Does it get a tool entry of its own? Is it reusable in itself (e.g. as a licence-free entry point for EcoInterfaces without a simulator licence)?
  • Dev sets 3 and 4 rest on unconfirmed assumptions about the mock (which topics, whether replay only or also reactive) — to be clarified with Jan/the team.
  • Add the specific repo URLs / clone commands as soon as the repos are public.
  • Tool docs and set docs (the two other docs categories) have no content yet — they will get pages as soon as the material for them is available.