
# From desktop panel to Android tablet: a read-only Qt viewer for a ROS tugger robot

Warehouse **tugger robots** pull trolleys from A to B on their own. When something
looks wrong (the robot stops, hesitates near a trolley, refuses to move), the first question
on the floor is always the same: *what does the robot see right now?*

The robot already has a control HMI, which is the screen you use to send missions and move it.
What was missing was the opposite: a **view-only** screen anyone can look at, which can't send
anything to the robot. It should show the lidar scan, the safety scanner's fields and whether the
motors' safe torque off (STO) is cut, live, on a tablet.

This post is about how that tablet app came to be. It started from an existing Qt desktop panel
and ended as **Tugger Live Viewer**, a portrait Android app with exactly one button. Along the
way: a tiny protocol instead of rosbridge, Qt Widgets on Android, testing with a recorded rosbag
through a WireGuard tunnel, and doing the LGPL properly when you hand an APK to a client.


![The tablet app in portrait: lidar sectors, live scan, and the scan, safety-scanner and safety-card status lines](/images/blog/tugger-live-viewer-tablet.jpg)

## The robot side: two computers and a read-only monitor

The robot runs **ROS 1 (Melodic)** on two computers:

- a **main PC** with the ROS master, navigation and the docking logic;
- a **Raspberry Pi** for the hardware: four 2D lidars merged into one scan, a SICK safety
  scanner, odometry and the CAN bus.

Instead of exposing ROS to the outside world, a small C++ node, `client_monitor`, runs on the
main PC. It reads the ROS graph through the master's XML-RPC API, subscribes to a handful of
topics, and serves a **newline-delimited JSON** stream on a TCP port. It is strictly read-only:
it publishes nothing, calls no service and sets no parameter.

```json
{"t":"lidar","topic":"/rectangle_laserscan","hz":12.0,"age":0.03,
 "sick":{"front_protective":false,"rear_protective":true,"scn":1},
 "lidars":[{"name":"front_lidar","x":0.7,"y":0,"yaw":0,"visible":[[-1.5708,1.5708]]}]}
```

Why not rosbridge? I had three reasons:

- **The clients don't need ROS.** A Qt app speaks TCP and JSON; that's all.
- **Bandwidth over a VPN.** A raw `LaserScan` is big. The monitor folds each scan into 720
  angular bins (0.5°), keeps the **nearest** return per bin, so obstacles survive the
  downsampling, and sends them as base64 `uint16` millimetres. That is about 2 KB per scan,
  capped at 5 Hz.
- **Nothing is subscribed unless someone is watching.** The scan and safety subscriptions
  exist only while at least one client asks for them, so an idle robot pays nothing.

```cpp
// Nearest return per angular bin, uint16 millimetres, 0 = no return.
const double bin_width = 2.0 * M_PI / bins;
for (size_t i = 0; i < scan.ranges.size(); ++i) {
  const double r = scan.ranges[i];
  if (!std::isfinite(r) || r < scan.range_min || r > max_range) continue;
  double a = std::fmod(scan.angle_min + i * scan.angle_increment + M_PI, 2.0 * M_PI);
  if (a < 0) a += 2.0 * M_PI;
  const int bin = std::min(bins - 1, int(a / bin_width));
  const uint16_t mm = uint16_t(std::min(65535.0, std::max(1.0, std::round(r * 1000.0))));
  if (out[bin] == 0 || mm < out[bin]) out[bin] = mm;
}
```

The safety scanner's status message is a custom type, but it is only 8 bytes (an `int32`
scenario and four booleans). The monitor reads it with `topic_tools::ShapeShifter` and checks
its MD5 instead of depending on the message package. If the format ever changes, the panel says
"unexpected message type" instead of showing garbage.

## The desktop panel first

The first client was a **Qt 5 Widgets** desktop panel for Linux and Windows. It shows the
machines, the ROS stack, the node tree and the lidar view, and it can record a session into
SQLite and replay it later. Getting the Windows build working mostly meant boring things: a
Windows branch for CPU, memory and disk stats, `windeployqt`, and keeping a 20 GB history out of
the *roaming* profile.

The part that matters for this story: the panel was split so that the **connection**
(`MonitorClient`) and the **lidar drawing** (`LidarView`) don't know anything about the window
around them.

## Qt Widgets on Android: better than its reputation

The common advice is "Qt Widgets don't belong on mobile, use QML". For a **phone**, yes. For a
**10–11" tablet** showing one dense, read-only screen, Widgets turned out to be perfectly fine.
The tablet app is a separate folder that compiles the desktop panel's connection and lidar files
**unchanged**; only the window is new. A fix in the lidar view reaches both apps.

Building with **Qt 5.15 + CMake + NDK r21** works, with a few traps:

- **On Android the app is a shared library**, loaded by Qt's Java activity:

  ```cmake
  if(ANDROID)
    add_library(${PROJECT_NAME} SHARED ${SOURCES})   # libtugger_live_viewer_<abi>.so
  else()
    add_executable(tugger-live-viewer WIN32 ${SOURCES})
  endif()
  ```

- **Qt 5.15.2 silently drops `ANDROID_MIN_SDK_VERSION`.** The values are computed, but the
  deployment-settings template has no placeholder for them, so the APK quietly declared
  Android 5 with target 28. The fix is a custom `build.gradle` in the package source directory
  with the versions written in.
- **Windows paths in that JSON break the build.** CMake writes the SDK path unescaped into a
  JSON file, so `D:\Android\sdk` turns into escape sequences. Use forward slashes.
- **The Gradle daemon kept the build "running" forever** because it held the log handle open.
  Setting `GRADLE_OPTS=-Dorg.gradle.daemon=false` fixed that.
- **Touch:** desktop widgets scroll with scroll bars. One line, `QScroller::grabGesture(...)`,
  gives finger flicking. For the lidar view, a `QPinchGesture` handler turned the wheel zoom
  into a pinch zoom, and desktop touchpads get it for free.

## Iterating with the people who use it

The first tablet build was basically the desktop panel squeezed into landscape. Then came the
first real-device screenshot, and the feedback was blunt: *remove the machine table, remove the
host editing, remove the ROS tree, remove docking, remove the lidar-rates button. Portrait only.*

Each removal made the app better. The final screen has a header with the robot's state and the
VPN status, the lidar view, three status lines (scan freshness, safety-scanner fields, STO and
its inputs), and **one** button: *About*.

One surprise: the app asks Android for `portrait`, but on a Xiaomi tablet running HyperOS
(Android 16), `adb shell wm get-ignore-orientation-request` printed **true**. On that tablet, the
system simply ignores what apps ask for on large screens. The answer was the system rotation
lock, not code.

## Testing without the robot: a rosbag behind WireGuard

The tablet must reach the robot over **WireGuard** in production, and I didn't want the test
setup to differ from that path. So I built a mock robot that looks exactly like the real one
from the tablet's side: same IP address, same port, a real `tun0` interface on the tablet.

**1. A rosbag-driven mock monitor in Python.** It reads a 125-second recording from the real
robot with the pure-Python [`rosbags`](https://pypi.org/project/rosbags/) package (no ROS
install, works on Windows), and replays it in a loop. It produces the same messages as the C++
monitor: the same binning, the same raw 8-byte safety-scanner decoding, and the lidar mounts
read from the robot's real YAML configuration. One Windows-specific catch: `rosbags` builds
`PosixPath` objects, which Python 3.13 refuses to instantiate on Windows, so the workaround is
to swap in `PurePosixPath`.

**2. A user-space WireGuard endpoint in Go.** `wireguard-go` ships an in-memory network stack
(gVisor's netstack). With it, a 200-line program can **be the robot inside the tunnel**: it owns
the robot's IP address and forwards its TCP port to the local mock. It needs no TUN driver and
no administrator rights.

```go
tun, tnet, _ := netstack.CreateNetTUN([]netip.Addr{tunnelIP, robotIP}, nil, 1420)
dev := device.NewDevice(tun, resilientBind{conn.NewDefaultBind()}, logger)
dev.IpcSet(config) // keys, peer, allowed IPs
dev.Up()
ln, _ := tnet.ListenTCPAddrPort(netip.AddrPortFrom(robotIP, 9870))
// accept → net.Dial("127.0.0.1:9870") → copy both ways
```

Two lessons from that part:

- **On Windows, a UDP `recv` can fail with `WSAECONNRESET`.** It's the ICMP "port unreachable"
  from an earlier packet, for example when the tablet's tunnel isn't up yet. `wireguard-go`
  treated it as fatal and stopped receiving for good. A small `Bind` wrapper that ignores error
  10054 fixed it.
- **Let the PC open the tunnel.** Without admin rights you can't add an inbound firewall rule,
  but a stateful firewall lets the replies of an outgoing flow back in. So the PC starts the
  handshake towards the tablet, and the tablet's WireGuard app answers. (On one Wi-Fi network,
  the PC's security suite dropped the replies anyway; on another, it worked within seconds.
  Always check which network you're on before debugging the tunnel.)

The app itself has no idea any of this is a mock. Pointing it at the real robot will be a
WireGuard profile change, not a code change.

## Shipping an APK with Qt: doing the LGPL properly

Handing the APK to a client means **distributing Qt**, and Qt 5.15 open source is LGPLv3. That
does **not** mean the app's code has to be public. It means:

- Tell users Qt is used and under which licence. That's the *About* screen, with the LGPLv3 and
  GPLv3 texts.
- Keep the third-party notices of what's **inside** Qt (zlib, libpng, FreeType, HarfBuzz,
  libtiff…). Qt declares them in `qt_attribution.json` files, so a short Python script turns
  the source archives into one notices file: 66 components.
- **Ship the exact Qt source** with the APK. Then there's no "written offer valid three years"
  to maintain.
- **Let users replace Qt.** Dynamic linking covers the native `.so` files. But Qt's Android
  Java part (`QtAndroid.jar`) is compiled into `classes.dex`, so the delivery also includes the
  packaging files (manifest, `build.gradle`, icons) needed to rebuild the whole APK with another
  Qt.

The thing to watch is adding a Qt module without checking its licence: a few are GPL-only in
the open-source edition.

## Delivery: a private repository, Git LFS and one command

Deliveries go to a private GitLab repository the client can read. The APK and the Qt source
(about 70 MB) go through **Git LFS**, and each version is a tag. The README warns that cloning
without LFS gives you 130-byte pointer files instead of an APK, which saves a support call.

Publishing is one PowerShell script. It refuses to run unless you're on an up-to-date, clean
`main`, the version matches in four files, the tag is free and the Android `versionCode` goes
up. Then it builds, commits, tags, pushes, and re-clones to check that the APK really is 17 MB
and not a pointer. A `-DryRun` mode does everything in a throwaway clone.

## What I'd keep

- **A tiny purpose-built protocol beats a general bridge** when the client is read-only and the
  link is a VPN.
- **Split connection and drawing from the window early.** It made the Android port mostly
  packaging work.
- **Qt Widgets are fine on tablets** for dense, read-only screens.
- **Test through the production network path**, even for the mock. Here that meant WireGuard,
  not "localhost".
- **Remove features.** The best version had one button.

Next up: the WireGuard server on the robot's network for the first live test, a proper release
signing key, and eventually Qt 6.


How a Qt 5 desktop monitoring panel for a ROS 1 robot became a portrait Android tablet app: a tiny JSON protocol instead of rosbridge, Qt Widgets on Android, a rosbag-driven mock behind a user-space WireGuard tunnel, and getting the LGPL right for delivery.

From desktop panel to Android tablet: a read-only Qt viewer for a ROS tugger robot


# Building a Structured LLM Wiki from Scientific Sources

This article documents the practical implementation of a **structured LLM knowledge ingestion workflow**.

The objective was to transform **scattered web pages and peer-reviewed articles** into a **queryable knowledge system** capable of supporting structured reasoning.

Inspired by the **LLM Wiki architecture**, the workflow focuses on building a persistent knowledge layer before querying any model.

---

# 1. Creating a Dedicated Knowledge Workspace

The first step was to initialize a **clean knowledge environment**.

## Create a New Obsidian Vault

This vault acts as the central repository for all knowledge artifacts.

Structure:

```
Vault/
 ├── Clipping/
 ├── PDFs/
 ├── Wiki/
 └── Logs/
```

This separation ensures:

- traceability  
- modular structure  
- predictable ingestion  

---

# 2. Setting Up the Agentic Environment

The ingestion workflow is executed inside an **agent-assisted development environment**.

Environment used:

- Antigravity  
- Claude Code  
- Obsidian Vault (mounted workspace)  

This enables:

- repeatable prompts  
- automated indexing  
- structured content generation  

---

# 3. Initializing the LLM Wiki Schema

The wiki structure is initialized using the **Karpathy LLM Wiki prompt**.

Reference:

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

This schema defines:

- page organization  
- indexing rules  
- linking strategy  
- maintenance logic  

Example:

```
index.md
topics/
concepts/
references/
log.md
```

This creates the **foundation of the knowledge graph**.

---

# 4. Capturing Source Material

Two categories of sources were collected:

## Web Sources

Captured using:

**Obsidian Web Clipper**

Each page was:

- reviewed  
- saved as Markdown  
- placed into:

```
Clipping/
```

---

## Scientific PDFs

Peer-reviewed, open-access papers were manually collected and stored in:

```
PDFs/
```

Source discipline included:

- publication validation  
- relevance filtering  
- topic alignment  

This ensured **high signal-to-noise ratio**.

---

# 5. Indexing the Clipping Folder

The first transformation step begins here.

Raw Markdown files are converted into structured entries.

## Prompt Used

```
Index the Markdown files in the Clipping folder
and create initial wiki entries with topics,
concepts, and references.
```

This produces:

- topic pages  
- concept definitions  
- source references  

At this stage:

**the knowledge graph begins to form.**

---

# 6. Ingesting Scientific PDF Articles

Scientific articles are processed using a structured ingestion prompt.

Reference:

https://gist.github.com/artemmelnyk-extern/e9e54d962284838d6c246a99caf04125

Each article is:

1. Renamed consistently  
2. Processed using the prompt  
3. Converted into structured wiki pages  

Expected outputs:

- structured summaries  
- extracted concepts  
- cross-links  
- references  

This step significantly expands the knowledge network.

---

# 7. Querying the Knowledge Base

After ingestion, the system becomes **queryable**.

Not searchable.

Queryable.

That distinction is fundamental.

Example interaction:

```
Query:
Explain the relationship between Topic A and Topic B
based on the ingested sources.
```

The answer now reflects:

- structured context  
- linked knowledge  
- curated sources  

Not raw text fragments.

---

# 8. Visualizing the Knowledge Graph

The Obsidian graph provides a visual confirmation of structure.

Each:

- node = structured knowledge  
- edge = contextual relationship  

This visualization confirms:

**the transformation from documents to knowledge.**

---

# Architecture Overview

```
Raw Sources
      ↓
Clipping
      ↓
Indexing
      ↓
PDF Ingestion
      ↓
Linked Wiki
      ↓
Queryable Knowledge
```

This architecture transforms:

**Information → Knowledge → Reasoning**

---

# Result

After full ingestion:

- knowledge became modular  
- relationships became visible  
- querying became meaningful  

The system evolved from:

**file storage**

to:

**knowledge infrastructure**

---

# Key Takeaways

1. Knowledge must be structured before reasoning  
2. Source quality determines reasoning quality  
3. Linking is as important as content  
4. Indexing creates the first real structure  
5. Querying is the final step — not the first  

---

# Conclusion

This workflow demonstrates how modern LLM systems benefit from **structured knowledge ingestion** rather than raw document retrieval.

The shift is not about smarter models.

It is about **better knowledge architecture**.


A practical workflow for building a structured LLM knowledge base using Obsidian, Claude Code, and curated scientific sources.

Building a Structured LLM Wiki from Scientific Sources


# Implementing NMEA 2000 Temperature Telemetry on STM32F334

This article documents the development of a **dual-message CAN bus system** implementing NMEA 2000 compliance for industrial temperature monitoring on an STM32F334C8T6 microcontroller.

## Project Evolution: v0.0.1 → v0.0.3

### v0.0.1: Initial CAN Implementation
Started with basic CAN transmission at 250 kbps, sending a simple DEADBEEF test pattern to validate hardware and toolchain.

### v0.0.2: Temperature Sensor Integration
Integrated STM32's internal ADC temperature sensor with factory calibration, combining DEADBEEF pattern and temperature data in a single message.

### v0.0.3: NMEA 2000 Compliance
Separated messages into two distinct protocols:
- **A1 Message**: High-frequency heartbeat (30 Hz)
- **T1 Message**: NMEA 2000 compliant temperature telemetry (1 Hz)

---

## NMEA 2000 Protocol Implementation

### Why NMEA 2000?
NMEA 2000 is the industry standard for marine and industrial sensor networks, providing:
- **Interoperability**: Works with standard displays and logging equipment
- **Structured data**: Well-defined Parameter Group Numbers (PGNs)
- **Robust networking**: Based on CAN bus with 29-bit Extended IDs

### PGN 130312: Temperature Standard

The T1 message implements **PGN 130312 - Temperature**, a standardized format for temperature telemetry:

```
Extended 29-bit CAN ID: 0x19FD0801

Bit Structure:
  Bits 26-28: Priority = 6 (low priority for slow-changing data)
  Bit 25:     Reserved = 0
  Bit 24:     Data Page = 1
  Bits 16-23: PDU Format = 0xFD
  Bits 8-15:  PDU Specific = 0x08
  Bits 0-7:   Source Address = 0x01 (device address)
  
PGN Calculation:
  PGN = (Data Page << 16) | (PDU Format << 8) | PDU Specific
  PGN = (1 << 16) | (0xFD << 8) | 0x08 = 130312
```

### Message Format

**T1 Data Payload (8 bytes):**
```
Byte 0: SID (Sequence ID) - Increments with each message
Byte 1: Temperature Instance (0 = single sensor)
Byte 2: Temperature Source (1 = Inside Temperature)
Byte 3-4: Temperature in Kelvin × 100 (uint16, little-endian)
Byte 5-7: Reserved (0xFF)
```

**Example CAN Message:**
```
slcan0  19FD0801  [8]  09 00 01 3B 72 FF FF FF

Decoding:
  SID: 0x09 (9)
  Instance: 0x00 (single sensor)
  Source: 0x01 (inside temperature)
  Temperature: 0x723B = 29243
    → Kelvin = 29243 / 100 = 292.43K
    → Celsius = 292.43 - 273.15 = 19.28°C
```

---

## Message Architecture

### A1 Message: High-Frequency Heartbeat
- **CAN ID**: 0x0A1 (Standard 11-bit)
- **Rate**: 30 Hz (33ms period)
- **Payload**: `DE AD BE EF 00 00 00 00`
- **Purpose**: Fast status indication and bus presence

### T1 Message: Temperature Telemetry
- **CAN ID**: 0x19FD0801 (Extended 29-bit)
- **Rate**: 1 Hz
- **Payload**: NMEA 2000 PGN 130312 format
- **Purpose**: Industrial-standard temperature reporting

---

## Implementation Details

### Temperature Sensor
STM32F334's internal temperature sensor (ADC1_IN16) with factory calibration:
```c
// Factory calibration values at 30°C and 110°C
uint16_t *TS_CAL1 = (uint16_t*)0x1FFFF7B8;
uint16_t *TS_CAL2 = (uint16_t*)0x1FFFF7C2;

// Linear interpolation
float tempCelsius = 30.0f + (rawADC - *TS_CAL1) * 
                    (110.0f - 30.0f) / (*TS_CAL2 - *TS_CAL1);
```

### Main Loop Timing
```c
while (1) {
  HAL_Delay(33U);  // 30Hz base rate
  
  // A1: Send every cycle (30 Hz)
  uint8_t a1Data[8] = {0xDE, 0xAD, 0xBE, 0xEF, 0x00, 0x00, 0x00, 0x00};
  HAL_CAN_AddTxMessage(&hcan, &txHeaderA1, a1Data, &canMailbox);
  
  // T1: Send every 30 cycles (1 Hz)
  if (++t1Counter >= 30) {
    t1Counter = 0;
    uint16_t tempKelvin = (uint16_t)((tempCelsius + 273.15f) * 100.0f);
    uint8_t t1Data[8] = {
      nmea2000_sid++,         // SID
      0x00,                   // Instance
      0x01,                   // Source (Inside)
      (uint8_t)(tempKelvin),  // Temp low byte
      (uint8_t)(tempKelvin >> 8), // Temp high byte
      0xFF, 0xFF, 0xFF        // Reserved
    };
    HAL_CAN_AddTxMessage(&hcan, &txHeaderT1, t1Data, &canMailbox);
  }
}
```

---

## Hardware Validation

Using SocketCAN on Linux with SLCAN adapter:

```bash
candump slcan0

# Output showing both messages:
slcan0  0A1   [8]  DE AD BE EF 00 00 00 00  # A1 @ 30Hz
slcan0  0A1   [8]  DE AD BE EF 00 00 00 00
...
slcan0  19FD0801  [8]  09 00 01 3B 72 FF FF FF  # T1 @ 1Hz (19.28°C)
```

---

## Design Decisions

### Priority Level 6
Chose **priority 6 (low)** for temperature data because:
- Temperature changes slowly (not time-critical)
- 1 Hz update rate is sufficient
- Higher priority reserved for critical control messages

### Source Address 0x01
Used **source address 0x01** (instead of 0x00) because:
- 0x00 can cause conflicts in multi-device networks
- Each device should have a unique address (0-251 range)
- Enables proper device identification on NMEA 2000 networks

### Temperature Source = 1 (Inside Temperature)
Best match for MCU internal temperature among NMEA 2000 options:
- Represents the internal environment of the device
- Alternative could be Source 3 (Engine Room) for electronics enclosures

---

## Toolchain

- **Microcontroller**: STM32F334C8T6 (ARM Cortex-M4, 64KB Flash)
- **Compiler**: arm-none-eabi-gcc 13.2.1
- **Debugger/Programmer**: st-flash 1.8.0 (STLink v2)
- **CAN Interface**: SLCAN adapter for testing
- **Build System**: GNU Make
- **Version Control**: Git with semantic versioning

---

## Results

Successfully implemented a production-ready dual-message CAN system:

✅ **A1 heartbeat** transmitting at 30 Hz  
✅ **T1 NMEA 2000** temperature at 1 Hz  
✅ Temperature accuracy: ±1°C (factory calibrated)  
✅ Binary size: 8,672 bytes (13% of 64KB flash)  
✅ NMEA 2000 PGN 130312 compliant  
✅ Hardware validated on CAN bus

---

## Future Enhancements

- Implement CAN receive for bidirectional communication
- Add additional NMEA 2000 PGNs (voltage, current, etc.)
- Implement address claiming for dynamic addressing
- Add error handling for CAN bus-off states
- Power consumption optimization (sleep modes)

---

## Repository

Full source code available on GitHub:  
[STM32F334C8T6-CAN](https://github.com/artemmelnyk-extern/STM32F334C8T6-CAN)

**Release**: v0.0.3 (2026-01-18)

---

## Conclusion

This project demonstrates successful integration of NMEA 2000 standards into embedded systems, providing a foundation for industrial-grade sensor telemetry. The dual-message architecture balances fast status updates with standardized data reporting, making it suitable for both diagnostic purposes and integration with commercial NMEA 2000 displays and logging equipment.

The separation of messages allows flexible system architecture where high-frequency heartbeats ensure system health monitoring while low-frequency telemetry conserves bus bandwidth and follows industry best practices.


Building a dual-message CAN bus system with NMEA 2000 PGN 130312 compliance for industrial temperature monitoring on STM32 microcontroller.

Implementing NMEA 2000 Temperature Telemetry on STM32F334


# Building a Secure Full-Stack LLM Platform on iarium.com

This article documents the full installation and configuration of a **secure Large Language Model (LLM) platform** hosted on `iarium.com`.  
The objective is to deploy a **production-grade AI stack** with:

- Hardened SSH access  
- Strict firewalling (UFW)  
- Intrusion protection (Fail2Ban)  
- Local LLM inference (Ollama)  
- Web interface (OpenWebUI in Docker)  
- HTTPS reverse-proxy with automatic certificates (Caddy)  

All steps below were executed on a Debian-based VPS.

---

## 1. Server Hardening (SSH, UFW, Fail2Ban)

### SSH Configuration

```bash
sudo nano /etc/ssh/sshd_config
```

Only specific IPs were allowed to connect to port 22.

### Install Fail2Ban

```bash
sudo apt install fail2ban
sudo reboot
```

### Firewall Reset & Reconfiguration

```bash
sudo ufw --force reset
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from YOUR_IP to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw logging on
```

### Monitoring

```bash
sudo ufw status numbered
sudo journalctl -u fail2ban.service -n 200 -o cat
```

---

## 2. Installing Ollama (LLM Backend)

### Installation

```bash
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
```

### Pulling Models

```bash
ollama pull llama3.1:8b-instruct
ollama pull llama3
ollama pull phi3
```

### Exposing the API Externally

```ini
[Service]
Environment=OLLAMA_HOST=0.0.0.0
Environment=OLLAMA_ORIGINS=*
```

Reload:

```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```

### API Test

```bash
curl http://127.0.0.1:11434/api/version
```

---

## 3. Running OpenWebUI (Front-End)

```bash
sudo docker run -d --name openwebui   -p 3000:8080   --add-host=host.docker.internal:host-gateway   -e OLLAMA_BASE_URL=http://host.docker.internal:11434   -v openwebui_data:/app/backend/data   --restart unless-stopped   ghcr.io/open-webui/open-webui:main
```

### Backend Status Check

```bash
sudo docker ps
sudo docker logs -f openwebui | grep ollama
```

---

## 4. HTTPS Reverse-Proxy Using Caddy

### Install Caddy

```bash
sudo apt install caddy
```

### Example Caddyfile

```caddy
iarium.com {
    reverse_proxy 127.0.0.1:11434
}

chat.iarium.com {
    reverse_proxy 127.0.0.1:3000
}
```

Reload:

```bash
sudo systemctl reload caddy
```

### DNS Diagnostics

```bash
dig +short chat.iarium.com
host chat.iarium.com
```

---

## 5. Final End-to-End Tests

```bash
curl -I http://127.0.0.1:11434/api/version
curl -I http://127.0.0.1:3000
curl -I https://iarium.com/api/version
curl -I https://chat.iarium.com
```

---

## 6. Result: A Fully Secure LLM Platform

Architecture:

```
                 +----------------------+
                 |      Internet        |
                 +-----------+----------+
                       HTTPS | 80/443
                             |
+------------------------------------------------------+
|                      Caddy Proxy                     |
|   iarium.com/api → 127.0.0.1:11434 (Ollama API)      |
|   chat.iarium.com → 127.0.0.1:3000 (OpenWebUI)       |
+----------------------+-------------------------------+
                       |
               +-------+--------+
               |    UFW + F2B   |
               +-------+--------+
                       |
         +-------------+-------------+
         |                           |
+--------+--------+        +---------+--------+
|    Ollama LLM    |        |   OpenWebUI     |
|  (local models)  |        |  (Docker)       |
|  11434/tcp       |        |  3000/tcp       |
+------------------+        +-----------------+
```

---

## 7. Asking 
```
curl http://5.135.138.96:11434/api/generate -d '{ "model":"llama3",  "prompt":"Explique la différence entre un serveur et un client en 3 points." }'
```  

## Conclusion

The platform deployed on `iarium.com` is now a **secure, production-grade AI stack**, capable of running modern LLMs locally with a clean web interface served over HTTPS.



Full installation guide for a hardened LLM platform using Ollama, OpenWebUI, Caddy, UFW, and Fail2Ban.

Building a Secure Full-Stack LLM Platform on iarium.com



# Raspberry Pi SSH Access via VPS - Installation Guide

## Overview
This setup creates a **reverse SSH tunnel** from your Raspberry Pi to your VPS, allowing you to SSH into your Pi from anywhere through the VPS.

## Architecture
```
[Your Computer] → [VPS:22] → [Tunnel:2222] → [Raspberry Pi:22]
```

## Step-by-Step Installation

### Step 1: VPS Setup

1. **SSH into your VPS:**
   ```bash
   ssh root@YOUR_VPS_IP
   ```

2. **Create tunnel user:**
   ```bash
   sudo useradd -m -s /bin/bash rpi-tunnel
   sudo -u rpi-tunnel mkdir -p /home/rpi-tunnel/.ssh
   sudo -u rpi-tunnel chmod 700 /home/rpi-tunnel/.ssh
   sudo -u rpi-tunnel touch /home/rpi-tunnel/.ssh/authorized_keys
   sudo -u rpi-tunnel chmod 600 /home/rpi-tunnel/.ssh/authorized_keys
   ```

3. **Configure SSH daemon:**
   ```bash
   sudo nano /etc/ssh/sshd_config
   ```
   
   Add at the end:
   ```
   Match User rpi-tunnel
       AllowTcpForwarding yes
       PermitOpen localhost:2222
       GatewayPorts no
   ```

4. **Restart SSH:**
   ```bash
   sudo systemctl restart sshd
   ```

### Step 2: Raspberry Pi Setup

1. **SSH into your Raspberry Pi:**
   ```bash
   ssh pi@RASPBERRY_PI_IP
   ```

2. **Generate SSH key (if not exists):**
   ```bash
   ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""
   ```

3. **Display public key:**
   ```bash
   cat ~/.ssh/id_rsa.pub
   ```

4. **Copy this key to VPS** (from RPi):
   ```bash
   ssh-copy-id -i ~/.ssh/id_rsa.pub rpi-tunnel@YOUR_VPS_IP
   ```
   
   Or manually: Copy the output and add it to `/home/rpi-tunnel/.ssh/authorized_keys` on VPS

5. **Test connection:**
   ```bash
   ssh rpi-tunnel@YOUR_VPS_IP
   ```
   (Should connect without password, then exit)

6. **Create tunnel script:**
   ```bash
   nano ~/rpi-tunnel.sh
   ```
   
   Paste:
   ```bash
   #!/bin/bash
   VPS_IP="YOUR_VPS_IP"
   VPS_USER="rpi-tunnel"
   REMOTE_PORT=2222
   LOCAL_PORT=22

   while true; do
       ssh -N -R ${REMOTE_PORT}:localhost:${LOCAL_PORT} \
           -o ServerAliveInterval=30 \
           -o ServerAliveCountMax=3 \
           -o ExitOnForwardFailure=yes \
           ${VPS_USER}@${VPS_IP}
       
       echo "Tunnel disconnected. Reconnecting in 10 seconds..."
       sleep 10
   done
   ```
   
   Make executable:
   ```bash
   chmod +x ~/rpi-tunnel.sh
   ```

7. **Test the tunnel:**
   ```bash
   ./rpi-tunnel.sh
   ```
   (Leave it running, open new SSH session to continue)

### Step 3: Make Tunnel Persistent (Auto-start)

1. **Create systemd service:**
   ```bash
   sudo nano /etc/systemd/system/rpi-tunnel.service
   ```
   
   Paste (replace `pi` with your username):
   ```ini
   [Unit]
   Description=Raspberry Pi Reverse SSH Tunnel
   After=network-online.target
   Wants=network-online.target

   [Service]
   Type=simple
   User=pi
   ExecStart=/home/pi/rpi-tunnel.sh
   Restart=always
   RestartSec=10

   [Install]
   WantedBy=multi-user.target
   ```

2. **Enable and start service:**
   ```bash
   sudo systemctl daemon-reload
   sudo systemctl enable rpi-tunnel
   sudo systemctl start rpi-tunnel
   ```

3. **Check status:**
   ```bash
   sudo systemctl status rpi-tunnel
   ```

### Step 4: Connect to Raspberry Pi

1. **From anywhere, SSH to your VPS:**
   ```bash
   ssh root@YOUR_VPS_IP
   ```

2. **Then connect to RPi through tunnel:**
   ```bash
   ssh -p 2222 pi@localhost
   ```

3. **Optional: Create shortcut script on VPS:**
   ```bash
   echo 'ssh -p 2222 pi@localhost' > ~/connect-rpi.sh
   chmod +x ~/connect-rpi.sh
   ```

## Troubleshooting

### Check if tunnel is active on VPS:
```bash
sudo netstat -tlnp | grep 2222
```

### View Raspberry Pi tunnel logs:
```bash
sudo journalctl -u rpi-tunnel -f
```

### Manual tunnel test from RPi:
```bash
ssh -N -R 2222:localhost:22 rpi-tunnel@YOUR_VPS_IP
```

### Reset everything:
**On VPS:**
```bash
sudo pkill -u rpi-tunnel
```

**On RPi:**
```bash
sudo systemctl stop rpi-tunnel
```

## Security Notes

- Only `localhost` connections to port 2222 are allowed on VPS
- The tunnel user has minimal privileges
- SSH keys are used instead of passwords
- Tunnel auto-reconnects if dropped

## One-Line Direct Connection (Advanced)

From your computer, connect directly:
```bash
ssh -J root@YOUR_VPS_IP -p 2222 pi@localhost
```

This uses SSH jump host to connect through VPS in one command.


 Raspberry Pi SSH Access via VPS - Installation Guide

Raspberry Pi SSH Access via VPS


# 🚀 Introducing Sensor Data Uploader: Effortless Sensor Telemetry from Edge Devices

We’re excited to announce the first public release of **Sensor Data Uploader**, a lightweight and efficient open-source tool designed to **collect, process, and transmit sensor data** from edge devices to your backend or cloud platform — reliably and securely.

---

## 🔧 What Is It?

**Sensor Data Uploader** is a C++-based command-line application designed to run on embedded Linux systems, Raspberry Pi, and industrial gateways. It reads local sensor data, formats it, and sends it over HTTP using `libcurl`. It also integrates seamlessly with **systemd**, allowing it to be managed like a proper Linux service.

---

## 💡 Why Did We Build It?

Managing sensor fleets in industrial or research environments often means:

- Dealing with fragmented data sources  
- Writing repetitive upload scripts  
- Fighting flaky Wi-Fi or limited compute

We needed something:

- **Simple** enough to configure  
- **Reliable** on low-power hardware  
- **Easy to deploy** via `.deb` packages  

So we built one!

---

## ✅ Key Features

- 📦 Lightweight binary with no runtime dependencies  
- 🌐 Configurable HTTP POST endpoint  
- 🔐 Secure and retry-capable upload logic  
- 🔁 Systemd service ready for automation  
- 🧪 Fully open-source & CI-packaged for Debian systems  

---

## 📥 How to Install

You can install it in seconds from our APT repository:

```bash
echo "deb [trusted=yes] https://melnyk.ovh/apt/binary-amd64/ ./" | sudo tee /etc/apt/sources.list.d/melnyk.list
sudo apt update
sudo apt install sensor-data-uploader
```

Then start and check logs:

```bash
sudo systemctl enable --now send-sensor-probe.service
journalctl -u send-sensor-probe.service -f
```

---

## 📡 Ready for the Field

The tool is now running in field trials and internal deployments. It’s designed to scale — plug it into your own MQTT broker, database, or cloud function.

---

## 🤝 Contributions Welcome

This is just the beginning. We're planning:

- JSON config parsing  
- MQTT and WebSocket backends  
- Optional local buffering  

If you're building an IoT project or managing edge sensors — we’d love your feedback or contributions!

---

## 🔗 Links

- **GitLab Repo:** [🔗 [link-to-repo](https://gitlab.com/didactic/cpp/send-sensor-probe#)]
- **Debian APT Repo:** [https://melnyk.ovh/apt/](https://melnyk.ovh/apt/)
- **License:** BSD License

Runs a shell command to collect sensor or system output

A modern C++17 utility that collect PC sensors data and upload as a file via HTTP POST

# The Future of Automotive Software Development: Navigating Innovation in Electric Vehicles

The automotive industry is undergoing a profound transformation, driven by the rapid adoption of electric vehicles (EVs) and the integration of advanced software systems. As an embedded software developer specializing in electric cars, I’ve witnessed firsthand how software is becoming the backbone of modern automotive innovation. In this blog post, I’ll explore key trends, challenges, and opportunities shaping the future of automotive software development.

## The Rise of Software-Defined Vehicles

Electric vehicles are no longer just about battery packs and motors. They’re increasingly software-defined, meaning that the vehicle’s functionality, from basic operations to advanced features, is determined by software. Software-defined vehicles (SDVs) allow manufacturers to:

- Update functionality over-the-air (OTA).
- Enable real-time diagnostics and predictive maintenance.
- Integrate with smart ecosystems, including IoT and renewable energy grids.

## Challenges in Embedded Automotive Software

1. **Real-Time Constraints**:
   Automotive systems demand real-time performance. For example, safety-critical systems like braking and steering must respond within milliseconds.

2. **High Reliability and Safety Standards**:
   Standards like ISO 26262 ensure functional safety, requiring rigorous testing and validation processes.

3. **Scalability and Modularity**:
   With the complexity of modern EV architectures, developers need scalable software solutions that can adapt to different vehicle platforms.

4. **Cybersecurity Threats**:
   As connectivity increases, so does the potential for cyber-attacks. Ensuring robust security measures is non-negotiable.

## Emerging Trends to Watch

### 1. Artificial Intelligence and Machine Learning

AI is transforming how vehicles perceive and interact with their environment. Applications range from autonomous driving algorithms to adaptive energy management systems. For embedded developers, this means integrating AI models efficiently within hardware constraints.

### 2. Vehicle-to-Everything (V2X) Communication

V2X technology enables vehicles to communicate with each other, infrastructure, and pedestrians. This not only improves safety but also enhances traffic management and energy efficiency in EVs.

### 3. Unified Software Platforms

Automotive giants are consolidating software development with unified platforms. These platforms streamline development, deployment, and updates, ensuring a consistent experience across different vehicle models.

### 4. Open-Source Collaboration

Open-source initiatives are gaining traction in the automotive world. By leveraging community-driven frameworks, developers can accelerate innovation while reducing costs.

## Opportunities for Developers

The shift towards software-defined vehicles presents immense opportunities for developers:

- **Collaborating on Cross-Disciplinary Teams**: Software engineers now work alongside hardware designers, data scientists, and cybersecurity experts.
- **Contributing to Sustainability**: Developing software that optimizes energy efficiency aligns with global sustainability goals.
- **Building Career-Defining Projects**: The automotive domain offers unique challenges and rewards, making it a fertile ground for career growth.

## Conclusion

As EVs continue to evolve, embedded software developers will play a pivotal role in shaping the future of mobility. By embracing innovation, addressing challenges, and leveraging emerging trends, we can drive meaningful change in the automotive landscape. The journey ahead is both exciting and demanding, but it’s undoubtedly a road worth traveling.

What are your thoughts on the future of automotive software? Let’s discuss in the comments below!



The automotive industry is undergoing a profound transformation, driven by the rapid adoption of electric vehicles (EVs) and the integration of advanced software systems.

The Future of Automotive Software Development


# Transforming Healthcare with AI: The Future of Precision Medicine

Healthcare is on the cusp of a technological revolution, with artificial intelligence (AI) at its forefront. From diagnosing diseases to personalizing treatments, AI is reshaping how we approach medicine and patient care. As a developer in this dynamic field, I’ve witnessed the transformative potential of AI-powered solutions in healthcare. This blog post delves into the current trends, challenges, and opportunities that AI brings to precision medicine.

## The Promise of AI in Healthcare

AI technologies, particularly machine learning (ML) and deep learning, are being applied across a wide spectrum of healthcare applications, including:

- **Disease Diagnosis**: AI models trained on medical images and data are achieving unprecedented accuracy in identifying conditions like cancer, heart disease, and neurological disorders.
- **Predictive Analytics**: AI algorithms analyze patient data to predict disease onset, enabling early intervention and improved outcomes.
- **Drug Discovery**: AI accelerates the drug development pipeline by identifying promising compounds and predicting their efficacy.
- **Personalized Treatment Plans**: By analyzing genetic, clinical, and lifestyle data, AI tailors treatments to individual patients, enhancing efficacy and minimizing side effects.

## Challenges in Adopting AI in Healthcare

1. **Data Privacy and Security**:
   Medical data is sensitive and highly regulated. Ensuring AI systems comply with standards like HIPAA and GDPR is crucial.

2. **Bias in AI Models**:
   AI systems can perpetuate biases present in training data, leading to unequal treatment recommendations for different patient groups.

3. **Integration with Existing Systems**:
   Healthcare institutions often rely on legacy systems. Seamlessly integrating AI solutions into these environments requires robust interoperability.

4. **Regulatory Hurdles**:
   The approval process for AI-based medical devices and software is stringent, involving rigorous testing and validation.

## Emerging Trends in AI-Driven Healthcare

### 1. Natural Language Processing (NLP) in Medical Records

NLP tools are revolutionizing how we handle unstructured medical data. From summarizing patient histories to automating administrative tasks, NLP improves efficiency and reduces burnout for healthcare professionals.

### 2. AI in Remote Patient Monitoring

With wearable devices and IoT, AI algorithms monitor patient health in real-time, enabling proactive care and reducing hospital readmissions.

### 3. Digital Twins in Medicine

Digital twin technology creates virtual replicas of patients to simulate treatments and predict outcomes, offering a glimpse into truly personalized medicine.

### 4. AI-Assisted Surgery

AI is enhancing surgical precision through robotic systems that assist surgeons in complex procedures, reducing risks and improving recovery times.

## Opportunities for Developers

The intersection of AI and healthcare opens exciting avenues for innovation:

- **Developing Ethical AI Models**: Building systems that prioritize fairness, transparency, and inclusivity.
- **Collaborating Across Disciplines**: Working with clinicians, biostatisticians, and data scientists to create impactful solutions.
- **Leveraging Big Data**: Harnessing vast healthcare datasets to uncover insights and drive discovery.
- **Fostering Accessibility**: Ensuring AI solutions are affordable and accessible to underserved populations.

## Conclusion

The integration of AI in healthcare is not just a technological shift but a paradigm shift in how we envision medicine. By addressing challenges and harnessing the power of emerging trends, developers and healthcare professionals can together pave the way for a future where precision medicine becomes the norm.

How do you see AI shaping the future of healthcare? Share your thoughts in the comments below!



Healthcare is on the cusp of a technological revolution, with artificial intelligence (AI) at its forefront.

All Blogs

From desktop panel to Android tablet: a read-only Qt viewer for a ROS ...

Building a Structured LLM Wiki from Scientific Sources

Implementing NMEA 2000 Temperature Telemetry on STM32F334

Building a Secure Full-Stack LLM Platform on iarium.com

Raspberry Pi SSH Access via VPS

A modern C++17 utility that collect PC sensors data and upload as a fi ...

The Future of Automotive Software Development

Transforming Healthcare with AI