It's been a while !

These last weeks, I've been making the last significant architectural changes to the Fripuck2 firmware. Let me walk through what has been done !

Remote → STM

A quick reminder

Until now, I focused my work on moving data from the robot to the remotely connected computer. As a reminder, here is how that path works:

1. Sensor data is collected on the STM chip of the robot, which I call the 'controller'.
2. It gets serialized into a Flatbuffer and sent over an SPI connection to the ESP chip (the 'radio' chip).
3. The radio chip connects to a remote client over wifi and sends the data over a continuous UDP stream.

On top of that, the radio chip is also responsible for taking incoming data from the SPI connection and feeding it to the Lua VM running on the ESP. As of the last devlog, this hasn't changed much and is still working fine.

The reverse path

What I worked on is the opposite direction: from the remote client to the controller chip.

The remote client serializes its commands (if it has multiple ones to send) into a Flatbuffer and sends it to the radio chip. This time, I use a persistent (keepalive) TCP connection. This is important: if a sensor read is lost during transmission, it doesn't really matter, but instructions shouldn't be lost. TCP ensures packets arrive and get resent if they are lost.

Once the Flatbuffer arrives on the ESP, it is parsed, maybe passed to the Lua VM for a custom event, and transformed into another representation before being sent to the controller chip.

COBS + UART instead of Flatbuffers + SPI

While I used Flatbuffers + SPI to send sensor data to the radio chip, I chose COBS + UART to send commands to the controller chip. The reason is the significant difference in data volume between the two directions. Command packets are sent (1) less often and (2) are much smaller. Because of this, serializing a new Flatbuffer would have been wasteful, and fighting with the complicated SPI slave connection was too much of a hassle at the time.

COBS, on the other hand, is a much simpler byte-stuffing algorithm used to frame serial data. All it does is ensure that a certain value (typically 0) marks the end of a packet and the beginning of a new one. This is necessary when multiple command packets are sent back-to-back, because we need to be able to tell them apart. The rest of the protocol is rather simple: an opcode, followed by a fixed struct and a CRC.

Why not forward the remote's Flatbuffer directly ?

You might wonder why I don't simply relay the Flatbuffer the remote client sent. There are a few reasons:

• It contains data the controller doesn't need. Some commands activate actuators connected to the radio chip, and others are strictly meant to interact with the on-board Lua VM. Those never need to reach the controller chip.
• The Lua VM can send instructions too. In that case I would have to serialize a new Flatbuffer anyway, which is more demanding than COBS, since COBS doesn't need to build an object at all.
• The Lua VM can intercept the remote's commands. When it does, the original packet can't be relayed as is. It would have to be deserialized and re-serialized to keep only the commands the Lua VM didn't catch, which is very inefficient.

The only real disadvantage is that, unlike Flatbuffers, COBS packets can't be read without a bit of decoding computation. But since commands are infrequent, the overhead is negligible.

Robot movement

The first thing I tried to get working after the Remote → Radio → Controller connection was set up is the robot's movement. Before, I had already written a simple set_speed() function for testing, but I wanted more advanced kinematic controls: acceleration, deceleration, moving specific distances, drawing arcs, etc.

Going metric

The first step was finally converting the stepper motor step count to metric units. This is rather simple to calculate. The robot is two-wheeled and has a wheel radius (r) of 20.5 mm. The stepper motors take 1000 steps[^turn-step] for a full wheel revolution, and one revolution moves the robot forward by one wheel circumference. We can therefore calculate the distance per step:

$$\text{meters per step} = \frac{2 \pi r}{1000} \approx 0.129 \text{ mm}$$

[^turn-step]: The GCtronic Wiki states that the motor takes 20 steps for a revolution, with a 50:1 gear ratio, which means the wheel takes 1000 steps for a full revolution.

The distance between the two wheels, $d$ = 53 mm, doesn't matter here. It only comes into play when the robot turns, as we will see below.

The control loop

Now that I had metric units, the only thing left to do was to precisely calculate, at any given moment $t$, at what frequency the stepper motors should turn, and in which direction. A task runs this calculation every 20 ms (50 Hz). The basic chain of operations is:

1. Check the current velocity.
2. Decide whether the robot should accelerate or decelerate, and calculate the new target velocity. To know when to start braking, I compare the distance remaining with the stopping distance $\frac{v^2}{2a}$.
3. Calculate the exact speed of both wheels from the target velocity and the radius of the arc the robot should drive.
4. Adjust the stepper motor timers.

In C, the operations roughly look like this:

#define DT 0.02f  // control loop period (s)

// Called every 20 ms
void control_step(void) {
    // Update the velocity
    float remaining = target_distance - distance_traveled();
    float stop_distance = (v * v) / (2.0f * decel);

    if (remaining <= stop_distance)
        v = fmaxf(v - decel * DT, 0.0f);  // brake
    else if (v < target_speed)
        v = fminf(v + accel * DT, target_speed);  // speed up
    else if (v > target_speed)
        v = fmaxf(v - decel * DT, target_speed);  // slow down

    // Convert to one speed per wheel
    float v_left, v_right;
    calculate_wheel_speeds(v, radius, &v_left, &v_right);

    // Convert m/s to steps/s and update the timers
    set_motor_speed(MOTOR_LEFT,  mps_to_steps(v_left));
    set_motor_speed(MOTOR_RIGHT, mps_to_steps(v_right));
}

The real version is a small state machine (idle, accelerating, coasting, cruising, decelerating), and it also reads new trajectories from a queue to handle sequential movements. But the idea is the same.

From one velocity to two wheels

Step 3 is where the wheel distance $d$ comes in. The radius parameter describes the arc the robot should follow, and it has four cases:

• INFINITY: the robot drives straight.
• 0.0: the robot spins in place to the left.
• -0.0: the robot spins in place to the right (signed zeros are useful here).
• Anything else: the robot draws an arc, positive for left and negative for right.

For an arc, the wheel on the inside of the curve has to go slower than the one on the outside:

$$v{left} = v \left(1 – \frac{d}{2R}\right) \qquad v{right} = v \left(1 + \frac{d}{2R}\right)$$

void calculate_wheel_speeds(float v, float radius, float* v_left, float* v_right) {
    if (isinf(radius)) {  // straight
        *v_left  = v;
        *v_right = v;
    } else if (radius == 0.0f) {  // spin in place
        float dir = signbit(radius) ? -1.0f : 1.0f;  // -0.0 = right, 0.0 = left
        *v_left  = -dir * v;
        *v_right =  dir * v;
    } else {  // arc
        float k = WHEEL_DISTANCE_M / (2.0f * radius);
        *v_left  = v * (1.0f - k);
        *v_right = v * (1.0f + k);
    }
}

Connecting everything together

Now that the robot is moving, I could set up my first complete robot control command. This involved creating Lua and Python APIs to control the motors, and building the instruction packets that carry those commands to the robot.

Both APIs expose the same functions:

• drive(speed): the simplest one. Moves straight, forever, at the given speed.
• move(distance, speed): moves straight for a given distance.
• arc(distance, radius, speed): drives along an arc of the given radius for a given distance.
• turn(radians, speed): turns in place by a given angle.
• set_wheels(left, right): sets the velocity of each wheel directly, for students who need that level of control.

Technically, all of these (apart from set_wheels) are the exact same command. They are shorthands with different mandatory arguments, to make them easier to use. On top of those, they all accept the same optional arguments: accel and decel for the acceleration and deceleration, radius for drawing arcs, and two flags. The first one, synchronous, makes a movement wait for the previous one to finish before it starts. Without it, a new movement simply replaces the current one. The second one, notify, is meant to tell you when the movement is done (it isn't wired up yet).

Python API

Let's start with the Python API, since it involves the extra step of packaging instructions into a Flatbuffer before sending them over TCP to the radio chip. All the movement functions simply call _send_trajectory with different default arguments, which then calls _queue_or_send. That last function is what makes batching possible:

def _queue_or_send(self, intent):
    if self._command_queue is not None:
        self._command_queue.append(intent)  # we are inside a batch, wait
    else:
        self._build_and_send([intent])  # otherwise, send right away

Instead of serializing and sending every function call individually, I added a batch function that groups multiple commands into a single Flatbuffer:

@contextmanager
def batch(self):
    """Group multiple commands into a single network packet."""
    self._command_queue = []           # start queuing instead of sending
    try:
        yield                          # run the code inside the `with` block
    finally:
        commands = self._command_queue
        self._command_queue = None     # back to sending immediately
        if commands:
            self._build_and_send(commands)

This means that when calling

with robot.batch():
    robot.move(distance=1.0, speed=0.5, synchronous=True)
    robot.turn(radians=math.pi, speed=0.5, synchronous=True)

the API groups both calls and sends them to the robot in a single packet. The synchronous flags make the robot finish the move before it starts turning. For now, batch() only groups the commands, it doesn't set that flag for you[^note-sequence].

[^note-sequence]: Making batch() set synchronous automatically is not implemented yet. Synchronous operations need to work across multiple kinds of actuators and sensors, not just movement as it currently stands.

Beyond this, it is all pretty standard Flatbuffer code, up until the reception of the packet on the radio chip, where it is decomposed into a static struct and sent to the controller. See the section about the information exchange with the controller to see how it works.

Lua API

On the Lua side, we don't have the convenience of named parameters, so the optional parameters go in a table. Essentially, this looks like:

robot.drive(0.5, {distance=1.0, accel=0.1})

This makes it fairly easy to implement all the other functions, since they all share the same optional arguments. Each function only passes the options it accepts to the parser (the others are NULL). The only exception is arc, where speed is a required entry of the options table.

Here is the drive implementation in C, to show how the options are parsed:

static void parse_options(lua_State* L, int idx, float* dist, float* speed, float* rad,
                          float* acc, float* dec, bool* sync, bool* notify) {
    if (lua_istable(L, idx)) {
        if (dist != NULL) {
            lua_getfield(L, idx, "distance");
            if (!lua_isnil(L, -1)) *dist = luaL_checknumber(L, -1);
            lua_pop(L, 1);
        }
        if (acc != NULL) {
            lua_getfield(L, idx, "accel");
            if (!lua_isnil(L, -1)) *acc = luaL_checknumber(L, -1);
            lua_pop(L, 1);
        }
        // and so on...
    }
}

static int l_drive(lua_State* L) {
    float speed = luaL_checknumber(L, 1);  // mandatory argument

    // Defaults for a continuous drive
    float dist = INFINITY, rad = INFINITY;
    float acc = default_accel, dec = default_decel;
    bool sync = false, notify = false;

    parse_options(L, 2, &dist, NULL, &rad, &acc, &dec, &sync, &notify);  // optional table

    command_move_trajectory(speed, dist, rad, acc, dec, notify, sync);
    return 0;
}

Notice command_move_trajectory. This last function builds the packet that gets sent to the controller chip. Let's see how it gets built and interpreted by the controller.

Exchanging the information

Once the Flatbuffer sent by the Python API has been parsed, or the Lua function has been called, both end up in the exact same place: command_move_trajectory. This function takes all the parameters we built previously and fills a fixed, packed struct that starts with an opcode, which tells the controller what kind of instruction it is. The struct is then handed to uart_send, which puts it in a queue. A dedicated transmitter task takes packets out of that queue, encodes them with COBS, appends the 0x00 delimiter and writes them to the UART. This way, whoever sends a command (the TCP handler or the Lua VM) never has to wait for the UART.

void command_move_trajectory(float speed, float distance, float radius, float accel,
                             float decel, bool notify, bool synchronous) {
    move_trajectory_payload_t payload = {
        .opcode = MOVEMENT_OPCODE,
        .options = {.speed = speed, .distance = distance, .radius = radius,
                    .accel = accel, .decel = decel,
                    .notify = notify, .synchronous = synchronous},
    };
    uart_send((uint8_t*)&payload, sizeof(payload));  // goes into the TX queue
}

void uart_transmitter(void* arguments) {
    for (;;) {
        xQueueReceive(uart_tx_queue_handle, &packet, portMAX_DELAY);

        result = cobs_encode(encoded_buffer, sizeof(encoded_buffer) - 1, packet.payload, packet.length);
        encoded_buffer[result.out_len] = 0x00;  // delimiter
        uart_write_bytes(UART_NUM_1, encoded_buffer, result.out_len + 1);
    }
}

On the controller side, the UART is set up in “receive to idle” mode: the interrupt fires when the line goes quiet, which means a whole burst of back-to-back packets can be sitting in the buffer. The callback splits the buffer on the 0x00 bytes, decodes every frame with COBS, and passes it on:

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef* huart, uint16_t size) {
    uint16_t start = 0;
    for (uint16_t i = 0; i < size; i++) {
        if (uart_rx_raw_buffer[i] != 0x00) continue;  // not the end of a frame yet

        if (i > start) {  // ignore empty frames
            result = cobs_decode(uart_decoded_buffer, sizeof(uart_decoded_buffer),
                                 &uart_rx_raw_buffer[start], i - start);
            if (result.status == COBS_DECODE_OK)
                prepare_and_send_instruction(uart_decoded_buffer, result.out_len);
        }
        start = i + 1;  // the next frame starts after the delimiter
    }
    HAL_UARTEx_ReceiveToIdle_IT(huart, uart_rx_raw_buffer, UART_ENCODED_BUFFER_SIZE);  // listen again
}

prepare_and_send_instruction copies the decoded bytes into a zero-filled unified_instruction_payload_t, so a packet that is shorter than expected can't make us read garbage, and pushes it onto a FreeRTOS queue. We are still inside an interrupt at this point, so we can't run the instruction right away: start_trajectory can block on a queue, which isn't allowed in an ISR. Instead, a dedicated instruction task waits on that queue and runs the instruction according to its opcode:

void instruction_handler(void* arguments) {
    unified_instruction_payload_t payload = {0};
    for (;;) {
        xQueueReceive(instruction_queue_handle, &payload, portMAX_DELAY);

        switch (payload.opcode) {
            case MOVEMENT_OPCODE:
                start_trajectory(payload.move_trajectory.distance, payload.move_trajectory.speed,
                                 payload.move_trajectory.radius, payload.move_trajectory.accel,
                                 payload.move_trajectory.decel, payload.move_trajectory.notify,
                                 payload.move_trajectory.synchronous);
                break;
            // ...
        }
    }
}

start_trajectory then pushes the trajectory into the queue read by the motion control loop from the previous section. The same switch also handles the other instructions, like enabling modules (for now, it only controls the LEDs).

Put together, a call like robot.move(...) travels from Python to a Flatbuffer over TCP, to the radio chip, over UART with COBS to the controller, into the trajectory queue, and finally to the stepper motor timers.

Conclusion

With this, the whole chain works: a single call in Python or Lua ends up as a trajectory driving the stepper motors. Along the way, it travels through TCP, the radio chip, COBS over UART, and the controller's motion loop. This was the last big architectural piece of the Fripuck2 firmware.

From here, the work shifts to features. Next month, I'll mostly be polishing what I've done and adding support for more of the robot's sensors and actuators, specifically the camera and the microphones.

See you soon !

Avant de travailler chez les Poquemont, je n’imaginais pas à quel point l’avenir se décide tôt. Leurs enfants n'en sont encore qu'à des problèmes de maths basiques, mais ils sont déjà destinés à des écoles prestigieuses, Paris Dauphine, Sciences-Po, HEC. Ma modeste fac d’Histoire à moi ne tient pas la comparaison. Chaque jour de la semaine lorsqu’ils sortent de classe, je suis celle qui s’occupe de passer en revue leurs devoirs, sur la table ronde de la grande cuisine. La gouvernante va les chercher à l'école. Une institution privée de très bonne réputation, dans l’arrondissement voisin. Je prends le relais après ma journée de cours, lorsqu’ils passent la porte de l’appartement cossu, en écoutant la petite m'expliquer pourquoi elle préfère la robe mouchetée à l'Alezan. Leur mère m'en parle avec fierté : l'aînée, Delphine, adore monter à cheval le week-end. Louis est plus taciturne, à 10 ans. Son père dit que cela l’orientera vers Normal Sup. La gouvernante s'occupe des tâches ménagères dans la maison, puis elle commence à préparer le repas lorsque je termine avec les devoirs. C'est d’ailleurs à cela qu'on reconnaît un mode de vie “simple”. Les Poquemont n'ont qu'une gouvernante, elle fait à la fois office de femme de ménage et de cuisinière. Parfois secondée par sa propre nièce, pour les occasions. Les dîners vraiment importants de Monsieur se font souvent au ministère, où il y a une cuisine avec grand Chef. Mais la famille Poquemont a choisi de ne pas déménager au domicile prévu avec la haute fonction. Ici, on est à deux pas du Ministère de toute façon. La voiture avec chauffeur suffit à conserver une vie à peu près normale, depuis l'immeuble de famille. Les plafonds à caisson, le parquet en chêne de Hongrie, les cours d'escrime et le catéchisme du dimanche après-midi, ce n'était pas mon monde à moi. J’ai de la chance d’avoir été prise. L’environnement est propice au calme, le poste est bien payé, les Poquemont répètent qu’un bon artisan mérite un bon salaire. À part les trajets en métro, bien m’acquitter de cette tâche ne me demande pas de grands efforts. Un diplôme Bac +3 était exigé, mais il faut surtout savoir rester discrète, être attentive aux petites traditions et aux convenances. Ne pas avoir de tatouages apparents. Madame Poquemont – Élise – n’a rien de tyrannique, elle est même très humaine. Je crois que c’est le mot qu’elle utilise le plus depuis que je la connais. D’ailleurs c’est elle qui avait insisté pour me prendre, alors que je n'étais pas passée par une agence de placement et que je n’avais aucune recommandation de la part d’autres bonnes familles. Très sympathique, et tolérante, elle semble toujours ravie de me voir en compagnie de ses enfants. Ma bienveillance « irradie », d’après elle. Et les enfants m'adorent, ce qui est réciproque. Comme son mari, Élise Poquemont travaille beaucoup elle aussi. Elle m'apprend parfois des choses sur son monde, qui me paraît si distant et dans lequel elle nage avec aisance. Par exemple, je n'avais aucune idée des règles implicites concernant le versement de dividendes. Élise Poquemont m'a tout expliqué : les actionnaires attendent toujours d'une entreprise qui commence à verser des dividendes que les paiements suivants ne diminuent pas. Tout équipe dirigeante qui baisserait les dividendes déclencherait une guerre au sein d'un groupe. C’est le mot qu’elle a employé. Oui, il y a des grandes guerres armées, mais d’autres conflits tout aussi importants se jouent dans les grands conseils d’administration, sans violence physique, et sans effusions de sang. Les enfants eux-mêmes ont des choses à m'apprendre. Par exemple je n'avais jamais joué au Gin Rami, un jeu de cartes dont Louis raffole. Un jour, il y a même joué avec l'ambassadeur de Monaco. Les Poquemont ont un lien ancien avec la petite principauté, mais lorsque l’enfant se met à réciter des listes de noms et de titres de noblesses, je dois en général l’inciter à revenir à ses devoirs. Je ne sais pas pourquoi les lignées généalogiques le passionnent à ce point. Ce garçon a une mémoire impressionnante, mais il a aussi tendance à se laisser trop facilement distraire par son imagination, lorsque les exercices de l’école deviennent rébarbatifs pour lui… Et comme je le comprends. On leur en demande tant à cet âge. Louis préfère parfois s’imaginer à la place de François Grimaldi, le fondateur de la dynastie qui s’empara pour la première fois de la forteresse Monégasque en se déguisant en moine. Un exploit digne d’une épopée romanesque, surtout pour un enfant. Mais mon rôle à moi c’est de m’assurer que le cahier d’exercice est dûment terminé chaque soir.

Ce matin, c’est madame Poquemont qui avait l’air totalement distraite de ses préoccupations habituelles. Troublée même. Je l’ai entendue paniquer pour la première fois, elle tenait son téléphone d’une main crispée, à l’autre bout de l’appartement de 135 m² : « Bernard, c’est terrible, il faut faire quelque chose. » Je ne faisais que passer par le couloir qui mène à la salle d’eau, je crois avoir entendu distinctement cette phrase : « Avec sa nature, il ne survivra pas là-bas, tu le sais bien ! » Elle qui ne perd jamais son calme, sa voix a chancelé. Je l’avais pourtant vue faire face à l’adversité du comité de quartier, et aux concurrences entre parents d’élèves. Je ne savais pas, je ne me doutais pas, que des malheurs plus grands pouvaient atteindre celles et ceux qui vivent parfaitement à l’abri. Aujourd’hui, au téléphone, j’avais eu l’impression qu’elle pleurait un fils. De qui pouvait-elle s’inquiéter comme ça ? Je n’aurais jamais osé le lui demander. Pendant toute la durée de l'appel, alors que nous nous tenions à l'écart dans la cuisine, Rosie, la gouvernante, balançait sa tête de gauche à droite, les yeux fermés, presque aussi affectée que sa patronne qui en avait perdu l’appétit depuis la veille. Rosie me l’a raconté sans chercher à faire de secret, avec des mots simples : « Son neveu qu’elle adore, il doit partir. À la guerre. »

[CC BY-SA]

These last two weeks, I've been busy working on the radio module of the e-puck2, specifically embedding a Lua VM onto its ESP32 chip, which handles remote communication. This work is part of my Fripuck project, my bachelor thesis aimed at adapting the e-puck2 software to better suit the needs of the University of Fribourg.

In this post, I'll explain why I wanted to introduce a Lua VM into the project, present the API, and talk about the C implementation.

Why add a VM?

First, a quick reminder of who this software is for. At the University of Fribourg, the e-puck2 robot is used to introduce students to mobile robotics. Fripuck is the name I've given to the new software I'm writing for the platform.

These robots are currently controlled remotely over Wi-Fi via a Python API built by a previous student during their own thesis. While that was a huge step up from the raw C API used before, remote control still comes with inherent drawbacks, either due to API abstractions or issues fundamentally linked to wireless telemetry.

Adding an on-board Lua VM allows students to program the robot directly without needing a continuous network connection. This allows them to investigate network latency, resource constraints, and the classic problem of dividing work between on-device and off-device execution. Scripting behavior in Lua is also vastly simpler than setting up toolchains, compiling C, and flashing new firmware to the robot, a high hurdle for first-year students who might be completely new to programming.

It's worth noting that the Lua scripting engine isn't meant to replace the remote Python API entirely. Remote controlling remains the primary way to interact with the robot, especially since Lua on an embedded chip isn't practical or fast enough for heavy sensor data analysis. Instead, the VM acts as a complementary tool: ideal for low-latency tasks, reactive behavior, or simple on-device configuration.

Why Lua?

Choosing Lua over other scripting options was a deliberate choice on my part. It gets its fair share of criticism: array indices famously start at 1, it is far less ubiquitous than Python, and its single complex data structure, the table, takes some getting used to.

However, Lua has its advantages in embedded contexts: it is easy to integrate into C programs via its clean, well-documented C API, while remaining fast, flexible, and lightweight. Compared to other embeddable languages like MicroPython, Lua is generally less RAM-hungry and features a cleaner architecture for constrained hardware. I'll also admit to a personal fascination with the technology, and this project felt like the perfect sandbox to explore it thoroughly.

(If you are curious about Python support, GCtronic, the makers of the robot, maintain an official [MicroPython port](https://www.gctronic.com/doc/index.php?title=e-puck2PCsidedevelopment#Micropython) of the e-puck2 software)._

Architecture and API

The two Lua environments I am most familiar with are game engines (like PICO-8 or LÖVE) and Neovim. From them, I borrowed two common patterns: update loops and hooks.

Update Loops & Hooks

Update loops are standard in game engines and other frameworks. I chose to expose two: init() and update(), following PICO-8 terminology. Students write an init() function for startup tasks, followed by an update() loop that runs at roughly 20Hz (~50ms delta time).

Alongside the loop, students can register hooks, callback functions triggered immediately when an event occurs, such as a sensor read or an incoming command from a remote controller.

Here is what a complete user script looks like:

-- Declare local variables for fast lookup
local last_side = "center"
local side = "center"

function init()
    -- Register a hook to the ground sensors to track a black line
    robot.on("telemetry:ground", function(ground)
        -- Lua arrays start at 1!
        local difference = ground[1] - ground[3]
        
        if math.abs(difference) > 20 then 
            if difference < 0 then side = "left"
            else side = "right" end 
        else side = "center" end

        if side ~= last_side then 
            print("Black line on the " .. side .. " side.") 
        end

        last_side = side
    end)
end

local counter = 0
local total_dt = 0

-- Runs every 50ms; prints average delta time every 100 iterations
function update(dt)
    counter = counter + 1
    total_dt = total_dt + dt
    if counter > 100 then 
        local average = total_dt / counter 
        print("Over 100 iterations, the average dt is: " .. average .. "s.")
        counter = 0
        total_dt = 0
    end
end

This script does two things: it listens to the "telemetry:ground" hook to log which side of the robot detects a black line whenever new readings arrive, while the update() loop continuously averages execution timing over 100 cycles.

This structure provides the flexibility of simple update loops while allowing students to handle asynchronous data sources independently.

Handling Single-Threaded Execution

Lua is strictly single-threaded, meaning the main update loop and event hooks cannot run concurrently. To prevent race conditions, I implemented an execution queue. Incoming hooks are queued up and processed sequentially before calling the update function. This keeps event processing prioritized without colliding with the main loop.

C API Implementation

Before looking at the implementation details, here is a quick primer on how the Lua C API operates.

All interactions between the host C code and the Lua engine pass through a virtual stack. When a C function is called from Lua, we pop the input arguments off the stack, perform our logic, and push any return values back onto the stack. The same stack-based pattern applies to everything: defining tables, assigning metatables, or invoking Lua callbacks.

Exposing Userdata

Exposing C data types to Lua as userdata was new territory for me. The cleanest way to manage custom data types in Lua is through metatables.

Metatables attach custom behavior (using metamethods like __index for field lookups or __len for array length operators) to tables or userdata. Through metatables, C functions can define exactly how Lua reads or writes underlying C memory.

For example, the "telemetry:ground" hook exposes a 3-element array corresponding to the floor-facing infrared sensors. Here is how that lookup is handled in C:

// Static buffer storing current sensor telemetry
static uint16_t ground[3] = {0, 0, 0};

// The __index metamethod function
static int l_ground_index(lua_State* L) {
    if (lua_type(L, 2) == LUA_TNUMBER) {
        int i = lua_tointeger(L, 2);
        if (i < 1 || i > 3) return luaL_error(L, "Index %d out of range [1,3]", i);
        
        // Convert 1-based Lua index to 0-based C array index
        lua_pushinteger(L, ground[i - 1]);
        return 1; // Number of return values pushed to stack
    }

    ESP_LOGW(TAG, "Lua ground array called with unknown key.");
    return 0;
}

// Handler for the '#' length operator (always 3 for ground sensors)
static int l_ground_len(lua_State* L) {
    lua_pushinteger(L, 3);
    return 1;
}

Next, we map these C functions to a metatable structure:

static const luaL_Reg ground_mt[] = {
    {"__index", l_ground_index},
    {"__len", l_ground_len},
    {NULL, NULL},
};

To register this metatable in Lua, we create it in the registry, populate its methods, and assign it when creating the userdata:

// 1. Create a new metatable named "Ground" on top of the stack
luaL_newmetatable(L, "Ground");

// 2. Register functions into the metatable on top of the stack
luaL_register(L, NULL, ground_mt);

// 3. Pop the metatable off the stack now that it's registered
lua_pop(L, 1);

Then, when instantiated, we allocate our ground_t userdata inside Lua and attach the metatable:

typedef uint16_t ground_t[3];

// Create userdata memory inside Lua (pushes it to the top of stack)
ground_t* g = (ground_t*)lua_newuserdata(L, sizeof(ground_t));

// Retrieve the "Ground" metatable and push it to the top of stack
luaL_getmetatable(L, "Ground");

// Attach the metatable to our userdata (located at stack index -2) and pop the metatable
lua_setmetatable(L, -2);

Managing Callbacks

Allowing users to define hook callbacks in Lua requires three straightforward steps in C:

1. Store a reference to the user's function in the Lua registry when registered.
2. Push the function and its arguments onto the virtual stack when the event triggers.
3. Execute the function using lua_pcall() (it stands for protected function call, which manages errors).

Here is a simplified view of executing a callback:

if (lua_type(L, narg) == LUA_TFUNCTION) {
    // The callback function is the second argument (after hook identifier)
    lua_pushvalue(L, 2); // Push function onto stack
}

// Call the function on the stack with 1 argument and 0 return values
if (lua_pcall(L, 1, 0, 0) != LUA_OK) {
    ESP_LOGE(TAG, "Error running hook callback: %s", lua_tostring(L, -1));
    lua_pop(L, 1); // Remove error message from stack
}

In the real system, function references and event userdata are stored safely inside the Lua registry for persistent, repeated invocation.

Improvements and Future Work

My Lua VM implementation is progressing well, but a few key tasks remain:

• Mutation vs. Allocation: Currently, data passed through hooks reuses the same memory reference across calls to minimize heap allocations on the ESP32. However, this means users cannot easily save historical readings without copying them, which might prove confusing.
• Direct Property Access: I want to support direct variable queries (like robot.ground[1]) within the main update loop without requiring dedicated hooks.
• Connecting Actuators: The e-puck2 hardware relies on two chips: the ESP32 (handling radio and running our Lua scripts) and an STM32 main controller (managing motors, low-level sensors, and passing telemetry to the ESP32). The final missing piece is wiring Lua commands back across the internal bus to control the physical actuators on the STM32, which will be my main focus for the rest of August.

Now that I am back from vacation, I managed to get a few things done ! Here is a list of the key areas I managed to make progres in: 1. Project managment, to have a better overview of what was done and what I need to achieve; 2. A smarter packaging system to manage multiple sensors at once; 3. Reducing memory usage by implementing static FlatBuffers using a custom emitter.

1. Project Managment

First, I finally took the time to look into project managment software, and stumbled on Kaneo, a rather minimal kanaban application that also includes a backlog and a Gantt chart. I wanted something that was easy to self-host (there is a Dokploy template for it) and a small enough featureset I wouldn't waste time learning how to use it. Now, if you want to follow the project's development, you can take a look at my kanban board !

Visually writing down what has to be done and has already been done helps me to prioritize certain features over others, and helps me stay motivated by seing the steady progress, so I am glad I finally took the time to configure everything.

2. Smarter packaging

Before, every single sensor provided its own _pack() function. This function was used to take as all the data that the sensor had accumulated since the last _pack() call and add it to the common Flatbuffer. Then, a central telemetry task would call the _pack() functions sequentially and then finally send out the final, serialized packet.

While this worked for testing purposes, it came with several issues: + It required to write extremely similar code each time I added a new sensor; + There was no check wether the packaged data exceeded the remaining available space; + Starvation was guaranteed since the sensors would alwas package in the same order.

The first issue was kind of fixed by using a large macro that could automatically generate the _pack() function for you, but the two other issues remained. To fix them, I decided to throw away this implementation to switch to a sensor-agnostic implementation with a priority system.

Generalizing the packaging

In FlatBuffer (specifically flatcc), you would typically use specialized functions for each datatype defined in your .fbs schema. To be able to handle any sensor, we use the underlying flatcc_ functions. These typically abstract away the datatype to an id, alignment and size variables. This enables us to register a sensor to the telemetry system by providing only three values, instead of providing a whole function, simplifying the work of the user.

Now we have a generic_pack() function to use instead of the ~10 individual pack functions. Since this generic function is provided by the telemetry task and not the sensor task, it has also much more context allowing for more granular control of how the data gets packaged.

Data from the sensors is appended using this (simplified workflow):

flatcc_builder_start_vector(B, size, alignment, max_count); // prepare to build scrap vector in heap
flatcc_builder_append_vector(B, byte_buf + (start_idx * size), count); // copy section of sensor data to the scrap vector
flatcc_builder_ref_t vec_ref = flatcc_builder_end_vector(B); // get offset of built scrap vector
flatcc_builder_ref_t* table_slot_ref = flatcc_builder_table_add_offset(B, id); // get offset of the sensor's final vector
*table_slot_ref = vec_ref; // map the scrap vector to the sensor's final vector
// repeat the above steps for each sensor, each with its own size, alignment and id
FripuckProtocol_Sensors_SensorBatch_end_as_root(B); // finaly commit the full FB

Currently those three values have to be digged up in the generated flatcc files, which is not ideal. In theory, these values can be calculated or referenced in the generated code, which would be ideal in the long run.

Priority System

To reduce starvation, and make sure time sensitive data gets priority, a priority system was made. A priority and age is assigned to each sensor when registering them, to determine the order in which the sensors get packaged, and thus which one can package the most data. That process is rather simple, simply adding age_step to the age of the sensor at each iteration to track how much time has passed since last data was sent, and then adding the age to the priority for the final priority. The sensor which gets the highest priority gets picked next.

This system prevents starvation but isn't optimal. Ideally, taking into account how much data the sensor has collected or what would optimally fill the FB packet would also be interesting metrics to determine the priority, but this simple system currently is sufficient for my needs.

Puting it all together

With these two new systems as well as a limit tracker, we can now create a simple packaging loop to package and send our data:

void pack_loop(flatcc_builder_t* builder, uint32_t budget) {
    for (; budget > 0;) {
        // Priority check
        struct sensor_info* s = update_age_and_pick_sensor();
        if (s == NULL) continue;

        // Managing the remaining space and packaging the sensor data.
        uint32_t bytes_written = 0;
        generic_pack(builder, &s->fb_data, budget, &bytes_written);
        budget -= bytes_written;
    ...

Adding to that a simple timeout that will not block the pack_loop when only few or slow sensors are running, and we have a much better system than before ! However, this doesn't solve our initial problem of high memory use, which requires the next adaptation:

3. Static FlatBuffers

First, we need to understand how FlatBuffers works. Here is what it is according to the docs:

FlatBuffers is an efficient cross platform serialization library [...].

To achieve this serialization, flatcc (the C implementation of FlatBuffers) first creates the individual objects and vectors that go into the final FB object, and in a second step, it compacts down those individual blocks into a single, continuous memory block that is ready to be sent. A unique twist on the serialization is that instead of growing the sequential block in only one direction, it starts in the center of the available space (offset 0), and grows data to the left (negative offset) and metadata (the position and type of the data) to the right (positive) offset.

                  ┌───────┬────────┐
                  │   FB buffer    │ Emitter ctx
                  └───────┼────────┘
                    Data  │ Vtable (metadata)
 - negative offset ◄───── │ ─────► + positive offset
                          │
                       offset 0

One major issue when using the default flatcc configuration, is that it builds this serialized block in the heap, meaning we need to allocate a huge chunk of data on the heap when the serialization starts. Since we only have so much heap space to begin with, this is a no go.

Luckily for us, the flatcc developers go us coverd and provide a custom initialization command which enables us to provode our own emitter (the object responsible for building the serialized block). This way, we can assign a static buffer to it, which prevents fragmentation and doesn't reaquire a bunch of free heap space. It is also possible to define a custom allocator, which is used when creating the temporary vectors and objects before serializing them, but this is overkill for our needs.

The custom emitter is divided into three parts: – The emitter context (ctx), which holds all the data the emitter function needs to build the serialized buffer; – The emitter function (custom_builder_emit_fun), which is called each time an object or vector needs to be added to the final buffer, and appends the data and the metadata to the respective ends of the buffer; – And finally the buffer itself, where the data will be added.

We define the buffer as simply a static array of bytes, with a “center”. Typically the center (or offset 0) won't be perfectly in the center of the static buffer, since flatcc generally produces much more data (left side) than metadata/Vtable (right side)

#define STATIC_FB_BUFFER_SIZE (2 * 1024)                       // 2KB static payload buffer
#define FB_BUFFER_OFFSET_ZERO (STATIC_FB_BUFFER_SIZE * 3 / 4)  // Index of offset 0
static uint8_t fb_buffer[STATIC_FB_BUFFER_SIZE] = {0};

Then, we need to define the context which will be passed through different function calls. To be able to build the buffer and correctly determine its size, we need to store a reference to the buffer, its capacity, the offset of the center, the min and max offsets.

typedef struct {
    uint8_t* buf;
    size_t capacity;
    flatbuffers_soffset_t zero_offset;  // Center (offset +0) of the buffer
    flatbuffers_soffset_t min_offset;   // Tracks the lowest negative offset emitted
    flatbuffers_soffset_t max_offset;   // Tracks the highest positive offset emitted
} static_emitter_context_t;

Then begins the hard part, the emitter function. It has to strictly follow the following function definition:

int custom_builder_emit_fun(void* emit_context, 
                            const flatcc_iovec_t* iov, 
                            int iov_count, 
                            flatbuffers_soffset_t offset, 
                            size_t len);

Let's go through the different arguments: – emit_context is a pointer to the context we defined earlier. – iov is an array containing data+size pairs of information we need to copy to the buffer. – iov_count is the number of elements in that array. – offset is the offset (positive or negative) where we need to write the data to. – len is the combined length of all the iov entries.

Then, the workflow is pretty simple. 1. We loop through the iov entries, 2. We calculate the final address in the buffer where the data needs to be copied to, 3. Update the offset before writing the next entry.

In code, this translates to the following (omitting bound checks and details):

for (int i = 0; i < iov_count; ++i) {
    size_t elem_len = iov[i].iov_len;
    if (elem_len == 0) continue;

    // Calculate the final address to write to 
    uint8_t* dest = &ctx->buf[ctx->zero_offset + offset];

    // copy 
    memcpy(dest, iov[i].iov_base, elem_len);
    
    // update the entry
    offset += (flatbuffers_soffset_t)elem_len;
}

Then, simply pointing to the lowest negative offset gives you a valid FB, no additional steps !

Wrappingn it up

---

Now that I’m back from vacation, I’ve managed to make progress on several key areas: 1. Project management, to get a clearer overview of what’s done and what’s left to achieve; 2. A smarter packaging system to handle multiple sensors more efficiently; 3. Reducing memory usage by implementing static FlatBuffers with a custom emitter.

1. Project Management

First, I finally took the time to explore project management tools and came across Kaneo, a minimal Kanban application that also includes a backlog and a Gantt chart. I wanted something easy to self-host (there’s a Dokploy template for it) with a small enough feature set that I wouldn’t waste time learning how to use it.

If you want to follow the project’s progress, you can now check out my Kanban board!

Visually tracking what needs to be done and what’s already completed helps me prioritize features and stay motivated by seeing steady progress. I’m glad I finally set this up.

2. Smarter Packaging

Previously, each sensor had its own _pack() function. This function would take all the data the sensor had accumulated since the last _pack() call and add it to a shared FlatBuffer (FB). A central telemetry task would then call these _pack() functions sequentially and send out the final serialized packet.

While this worked for testing, it had several issues: – It required writing nearly identical code for each new sensor. – There was no check to ensure the packaged data didn’t exceed the available space. – Starvation was inevitable since sensors were always processed in the same order.

The first issue was partially fixed using a macro to auto-generate the _pack() function, but the other two remained. To address them, I decided to scrap this approach and switch to a sensor-agnostic implementation with a priority system.

Generalizing the Packaging

When using FlatBuffers, you typically use specialized functions for each datatype defined in your .fbs schema. To handle any sensor, we use the underlying flatcc_ functions, which abstract the datatype into an ID, alignment, and size. This allows us to register a sensor in the telemetry system by providing just these three values, instead of an entire function, simplifying the user’s work.

Now, we have a single generic_pack() function replacing the ~10 individual pack functions. Since this generic function is provided by the telemetry task rather than the sensor task, it has more context, enabling finer control over how data is packaged.

Sensor data is appended using this simplified workflow:

flatcc_builder_start_vector(B, size, alignment, max_count); // Prepare to build scrap vector in heap
flatcc_builder_append_vector(B, byte_buf + (start_idx * size), count); // Copy section of sensor data to the scrap vector
flatcc_builder_ref_t vec_ref = flatcc_builder_end_vector(B); // Get offset of built scrap vector
flatcc_builder_ref_t* table_slot_ref = flatcc_builder_table_add_offset(B, id); // Get offset of the sensor's final vector
*table_slot_ref = vec_ref; // Map the scrap vector to the sensor's final vector
// Repeat the above steps for each sensor, each with its own size, alignment, and ID
FripuckProtocol_Sensors_SensorBatch_end_as_root(B); // Finally commit the full FlatBuffer

Currently, these three values (ID, alignment, size) must be manually extracted from the generated flatcc files, which isn’t ideal. In theory, they could be calculated or referenced in the generated code, which would be a better long-term solution.

Priority System

To prevent starvation and ensure time-sensitive data gets priority, I implemented a priority system. Each sensor is assigned a priority and an age when registered. These determine the order in which sensors are processed and how much data they can package. The process is straightforward: at each iteration, age_step is added to the sensor’s age to track the time since its last data was sent, and then the age is added to the priority to compute the final priority. The sensor with the highest priority is selected next.

This system prevents starvation but isn’t perfect. Ideally, we’d also consider how much data a sensor has collected or how to optimally fill the FlatBuffer packet. However, this simple system currently meets my needs.

Putting It All Together

With these two new systems and a limit tracker, we can now create a simple packaging loop to package and send data:

void pack_loop(flatcc_builder_t* builder, uint32_t budget) {
    for (; budget > 0;) {
        // Priority check
        struct sensor_info* s = update_age_and_pick_sensor();
        if (s == NULL) continue;

        // Manage remaining space and package sensor data
        uint32_t bytes_written = 0;
        generic_pack(builder, &s->fb_data, budget, &bytes_written);
        budget -= bytes_written;
        ...
    }
}

Adding a simple timeout ensures the pack_loop doesn’t block when only a few or slow sensors are running. This results in a much better system than before. However, it still doesn’t address the initial problem of high memory usage, which brings us to the next adaptation:

3. Static FlatBuffers

First, let’s recap how FlatBuffers works. According to the docs:

FlatBuffers is an efficient cross-platform serialization library for C++, Java, Python, Go, and more.

Unlike traditional serialization formats (e.g., JSON or Protobuf), FlatBuffers does not serialize or deserialize data in the conventional sense. Instead, it directly constructs a binary buffer in memory, where data is organized for zero-copy access. This means you can read fields directly from the buffer without parsing or deserialization steps. To build this buffer, flatcc (the C implementation of FlatBuffers) follows a two-step process:

1. It first creates intermediate vectors and tables (temporary structures) for each object defined in your .fbs schema.
2. It then compacts these into a single, contiguous memory block ready for transmission. A unique aspect of FlatBuffers is its bidirectional growth mechanism. Instead of growing the buffer in one direction, it starts at the center (offset 0) and grows:
3. Data (e.g., vectors, scalars) toward negative offsets (left).
4. Metadata (e.g., VTables, which store field layouts for tables) toward positive offsets (right). This minimizes alignment gaps and ensures the final buffer is tightly packed.

                  ┌───────┬────────┐
                  │   FB buffer    │ Emitter ctx
                  └───────┼────────┘
                    Data  │ Vtable (metadata)
 - negative offset ◄───── │ ─────► + positive offset
                          │
                       offset 0

But why does it matter ? By default, flatcc allocates this final buffer on the heap, which is problematic for embedded systems with limited memory. Fortunately, flatcc allows us to provide a custom emitter—a callback function that redirects buffer construction to a static memory region of our choosing. This avoids dynamic allocation entirely. It’s also possible to define a custom allocator for temporary vectors and objects before serialization, but that’s overkill for our needs.

The custom emitter consists of three parts: – The emitter context (ctx), which holds all the data the emitter function needs to build the serialized buffer. – The emitter function (custom_builder_emit_fun), called each time an object or vector needs to be added to the final buffer. It appends data and metadata to their respective ends of the buffer. – The buffer itself, where the data is stored.

We define the buffer as a static byte array with a “center.” Typically, the center (offset 0) isn’t perfectly centered in the static buffer, as flatcc usually generates more data (left side) than metadata/vtable (right side):

#define STATIC_FB_BUFFER_SIZE (2 * 1024) // 2KB static payload buffer
#define FB_BUFFER_OFFSET_ZERO (STATIC_FB_BUFFER_SIZE * 3 / 4) // Index of offset 0
static uint8_t fb_buffer[STATIC_FB_BUFFER_SIZE] = {0};

Next, we define the context passed through function calls. To build the buffer and correctly determine its size, we need to store a reference to the buffer, its capacity, the center offset, and the min/max offsets:

typedef struct {
    uint8_t* buf;
    size_t capacity;
    flatbuffers_soffset_t zero_offset;  // Center (offset +0) of the buffer
    flatbuffers_soffset_t min_offset;   // Tracks the lowest negative offset emitted
    flatbuffers_soffset_t max_offset;   // Tracks the highest positive offset emitted
} static_emitter_context_t;

Now, the tricky part: the emitter function. It must strictly follow this definition:

int custom_builder_emit_fun(void* emit_context,
                            const flatcc_iovec_t* iov,
                            int iov_count,
                            flatbuffers_soffset_t offset,
                            size_t len);

Let’s break down the arguments: – emit_context: A pointer to the context we defined earlier. – iov: An array containing data+size pairs of the information to copy to the buffer. – iov_count: The number of elements in that array. – offset: The offset (positive or negative) where the data should be written. – len: The combined length of all iov entries.

The workflow is straightforward: 1. Loop through the iov entries. 2. Calculate the final address in the buffer where the data should be copied. 3. Update the offset before writing the next entry.

In code, this looks like (omitting bounds checks and minor details):

for (int i = 0; i < iov_count; ++i) {
    size_t elem_len = iov[i].iov_len;
    if (elem_len == 0) continue;

    // Calculate the final address to write to
    uint8_t* dest = &ctx->buf[ctx->zero_offset + offset];

    // Copy
    memcpy(dest, iov[i].iov_base, elem_len);

    // Update the offset
    offset += (flatbuffers_soffset_t)elem_len;
}

Once all data is written, the lowest negative offset points to the start of a valid FlatBuffer—no further processing needed!

---

Wrapping Up

While I haven’t been able to work on the project as much as I’d have liked, I’m glad to see it moving forward again. I’m also happy to see my memory issues disappear, hopefully for good 😅.

Over the next month, I’ll try to dedicate as much time as possible to the project. Right now, I’m focusing my efforts on getting the camera to work and laying the initial foundations for the laptop → e-puck commands. This involves coordinating the radio and controller chip, as well as the Lua VM I’ve started implementing.

C you next month!

Project Github page: https://github.com/Uhrbaan/fripuck2

Speed Without Compromise: A Practical Guide to Slashing Your CNC Production Cycle

In the world of precision engineering, there is a constant tug-of-war between speed and quality. When you are sourcing custom CNC parts, the pressure to reduce cnc lead time can often lead to “shortcuts” that result in scrapped parts or dimensional inaccuracies.

However, reducing lead time doesn’t have to mean compromising on tolerances. By optimizing the workflow from the initial design phase to the final inspection, manufacturers and engineers can achieve rapid cnc machining without sacrificing an ounce of precision.

Here is a practical, step-by-step guide to streamlining your CNC production cycle.

1. Optimize for Manufacturability (DfM)

The most significant delays in CNC machining often happen before the machine even starts. “Design for Manufacturing” (DfM) is the process of designing parts specifically to be easy to machine.

• Avoid Deep Pockets: Deep, narrow slots require long tools that vibrate (chatter), forcing the machinist to slow down the feed rate.
• Standardize Radii: Using standard tool diameters for internal corners prevents the need for custom tooling or complex multi-axis movements.
• Simplify Tolerances: Don’t apply a ±0.001 tolerance to every dimension if only two critical holes actually require it. Over-tolerancing increases inspection time and scrap rates.

By focusing on these details during cnc prototyping, you can identify bottlenecks early and ensure the transition to full-scale production is seamless.

2. Strategic Tooling and Process Selection

Choosing the right process for the right geometry is key to speed. Many projects fail to optimize by using a single machine for a complex part when a hybrid approach would be faster.

• The Milling vs. Turning Split: For cylindrical components, utilize specialized CNC turning services to achieve high speeds and superior surface finishes. For complex prisms or blocks, leverage high-speed CNC milling services.
• Tooling Presets: Use tool presetters to measure tool lengths and diameters offline. This means the machine doesn't sit idle while the operator manually probes tools.
• High-Feed Cutters: Invest in high-feed milling cutters that can remove large volumes of material quickly while maintaining a stable cut, drastically reducing roughing time.

3. Implement a “First-Article” Fast Track

Waiting for a full batch to be completed before inspecting them is a recipe for disaster. If the first part is wrong, the entire batch is scrap.

To reduce lead time, implement a First-Article Inspection (FAI) process: 1. Machine a single piece. 2. Conduct a full dimensional report. 3. Get immediate sign-off before proceeding to the rest of the lot.

This is particularly critical in high-stakes sectors like aerospace cnc machining, where material costs are high and tolerances are razor-thin. Finding an error on the first part saves days of wasted production.

4. Streamline Material Sourcing and Fixturing

The machine cannot run if it is waiting for material or if the setup takes four hours.

• Standard Stock Sizes: Design your parts to fit standard raw material sizes. Custom-ordering specialized billets adds weeks to your cnc lead time.
• Modular Fixturing: Use “zero-point” clamping systems. These allow a technician to swap a workpiece in seconds with micron-level repeatability, meaning the machine spends more time cutting and less time in “setup mode.”
• Batching Similar Parts: If you have multiple custom CNC parts with similar geometries, machine them in a single setup (multi-part fixturing) to reduce the number of times the machine needs to be recalibrated.

Final Thoughts

Reducing lead time is not about pushing the machine to its breaking point; it is about removing the “waste” from the process. By combining smart DfM, strategic tool selection, and rigorous first-article checks, you can achieve the speed of rapid cnc machining while maintaining the quality standards your project demands.

Whether you are iterating a prototype or scaling a production run, the key is to optimize the workflow long before the “Cycle Start” button is pressed.

Field notes from the workbench this week. I spent most of the afternoon squaring up a jig so repeat cuts land in the same place every time, which saved more effort than any single clever trick. Small tolerances add up: a fraction of a millimetre off at the start becomes a visible gap by the end. I keep a running log of what worked and what wasted time, because memory is unreliable after a long session. Cheap calipers, a sharp pencil, and patience beat expensive tools used carelessly. Next up is tidying the bench and labelling the offcuts so the next build starts faster.

Over the last two months, I was busy with my exam sessions and wasn’t able to make as much progress as I would have liked. However, I did start planning a smarter serialization approach for sensor data. Currently, all samples are packed one after another, which causes FlatBuffers to use too much RAM. The core idea is to track how much data has been packed so far and use a priority system to decide which packets get packed first. I don’t have much to show yet, though.

During that time, I also met with my professors to discuss the project, which forced me to clarify what I want to achieve with Fripuck. I identified four key improvements I could bring:

• Data analysis
• Networking
• Asynchronous API
• On-board programming

Data Analysis

The current API and firmware for the robot focus on real-time data, and it is up to the user to store and analyze it. My goal is to allow the firmware to save multiple data points in batches and send them at once, providing higher time resolution. The API would then store this historical data, allowing users to query it.

Improved Networking

A major annoyance when working with the robot is unstable networking. When 10 students work simultaneously on 10 different robots, the network can fail. The new API should be able to reconnect the robot as quickly as possible to avoid disrupting the user.

Asynchronous API

This is another step toward improving time resolution. Currently, the Python API used to communicate with the robot relies on a single .go_on() call that sends instructions and waits for sampled data. This causes the program to spend most of its time waiting for a network response, making the robot feel unresponsive. My goal is to make data exchange happen in the background so it doesn’t interfere with the user’s code. I also want to decouple the sending and receiving of data.

On-board Robotics

Currently, the robot can only be controlled remotely, or the user must modify the robot’s firmware (which is not suitable for the target audience). I would like to add a small on-board interpreter, likely using Lua (since it is lightweight and easy to embed), to configure the robot and execute simple commands. This would allow users to change robot-specific features without recompiling the firmware or let students test latency when running scripts on-board or over the network.

---

Going Forward

This summer, I’ll have plenty of time to work on this project and, hopefully, complete 80% of it. Right now, the most urgent tasks are to configure my new OS (I distro-hopped to openSUSE) and create a roadmap of the features I need to implement. On the academic side, I need to identify measurable goals to evaluate the success of my project.

— Et alors, il y avait quoi sur ce papier ?

Le bar aux couleurs ocre et bois est encore peu fréquenté. Sur la table carrée, Agathe a étalé quelques objets sortis de son sac, un carnet, un livre, et le téléphone mis en mode vibreur pour mieux profiter du moment.

— Je sais pas, j'y suis pas allé. — Quoi, t'es même pas descendu voir, par curiosité ?

L'espace autour est devenu son terrain familier pour une heure. Je contemple le verre toujours plein en face d’elle. Elle n’en a bu qu’une toute petite gorgée, alors que le mien est déjà à moitié vide.

— Non, j'ai décidé ça à pile ou face.

Agathe reste immobile un instant. Pas un mouvement de cils. Elle doit être vraiment sérieuse, elle me demande :

— Mais tu fais vraiment tous tes choix comme ça ? — Les décisions qui demandent un effort, oui.

Elle ne touche toujours pas à son verre. Avec elle, je ne ressens aucun jugement. Pour ça que j'ose avouer ce que je ne dirai jamais à l'autre.

— Franchement, je sais que c'est facile à dire, mais tu devrais changer de psy. — Je suis obligé de la voir, c’est la psy du travail. J'ai des convocations obligatoires pour pouvoir conserver mon chômage.

Un geste de dépit, sa main plonge dans le petit bol de cacahuètes.

— Ça me dégoûte ce chantage aux allocations…

Les cacahuètes restent dans sa main comme si son écœurement était en rapport avec l'appétit. Je garde le silence, alors elle finit par se mettre à grignoter sa prise. Elle réfléchit.

— Hmm… mais alors, ça veut dire que pour venir me rejoindre tu n'as pas choisi non plus ? Pas très valorisant… C’est un lancer de pièce qui a répondu oui à mon invitation ?

Elle a changé de ton. Son petit air ironique, je vois bien qu'elle voudrait détendre l'atmosphère. Mais à elle, je ne peux pas mentir.

— Ben oui.

Ses yeux partent en coin vers la grande vitre du bar par laquelle on voit passer vélos et trottinettes. Elle continue de mâchonner les billes jaunes qu'elle s'enfile une par une. J'aimerais lui montrer que j’apprécie son attention. Je dis quelque chose, très maladroit, un truc facile, pour remplir le silence.

— Tu sais, ma psy c'est toi.

Là ses sourcils se soulèvent. Elle agrippe le contenant qu’elle s’apprête à vider du peu de bière restant, avant de me dire, sans mentir elle non plus :

— Mouais. Tu sais que c'est une charge mentale ça pour les femmes, de servir de confidente aux mecs ?

Je baisse les yeux pour afficher une prise de conscience. Elle ne rigole qu'à moitié.

— Je vais quand même te donner un vrai avis. Et tu es obligé de l'écouter jusqu'au bout, tu l'as bien cherché.

Sans m’en rendre compte j’ai descendu ma conso pendant qu’on se parlait. Ça y est, maintenant mon verre est vide, et je n’ai rien de très intelligent à répondre :

— Ça va me coûter combien ? — Zéro, justement c'est ça le problème du travail féminin gratuit. Mais je vais quand même te dire… peut-être qu'il faut que tu l'entendes de la bouche de quelqu'un…

Agathe vide d'un trait le fond de bulles dans sa chopine, avant de la laisser retomber lourdement sur la table.

— … Je pense, enfin je crois, que la menace de la guerre, ça nous atteint plus ou moins. Même quand on ne le montre pas. Comme toi, tu vois tu ne m'en parles jamais, mais peut-être que tu devrais te poser sérieusement la question.

Je reste muet. Par respect pour cet effort envers moi. Et parce que la moindre évocation du sujet me fait mal au ventre.

— … Tu devrais te demander s'il n'y a pas un rapport.

Un réflexe m'échappe en entendant ça, j'inspire fort par le nez, je m'en veux tout de suite. Je n'avais ni l'intention de montrer de l'agacement ni de laisser transparaître à quel point la question pouvait me toucher. Mais ça ne l'empêche pas de continuer :

— Tu crois pas que t'en remettre au hasard, au lieu de faire tes propres choix, ça a un rapport avec la menace qui nous plane dessus ?

Je continue à me taire. Tous mes efforts, je fais tout ce que je peux, pour ne pas lui envoyer d’autres signaux désagréables. Une amie comme ça on n'en trouve pas sous chaque dessous-de-verre.

— … Je suis pas psy, d'accord, mais ton lancer à pile ou face, c'est pas sain, c’est pas bon pour toi. Moi je crois qu’il y a un lien inconscient.

Je sais pas si c'est mon comportement, mais Agathe a soudain retrouvé une voix de fille trop gentille, la voix qu'elle a quand elle est émue :

— … Un lien avec cette horreur de tirage au sort pour nous envoyer à la guerre.

[CC BY]

La porte est restée ouverte un moment. Je n'ai pas compris pourquoi tout de suite. Jusqu'à ce que les grosses roues d'un fauteuil électrique franchissent le seuil. La personne installée dedans a glissé sous la lumière et les roues se sont immobilisées. Elle pilote d'un doigt sur un petit joystick. Elle est de dos. Une femme maquillée, avec un pantalon noir et un manteau très classe, des escarpins, et un chapeau qui lui fait comme un gâteau sur la tête. Je n'avais jamais vu quelqu'un porter un chapeau entortillé comme ça avec des rubans et de la mousseline, sauf dans des fêtes déguisées. Un mec la suit. Il est raide lui, dans son costume noir avec une cravate grise. Il est allé faire un signe à la conductrice, mais au lieu de sortir elle a déclenché l'ouverture du coffre de la Porsche, qui monte lentement. Et la femme en fauteuil, derrière, attend en regardant le mouvement ascendant du haillon, avec le mec en blazer qui est revenu à côté d'elle se poster comme un piquet, regard droit, les mains l'une sur l'autre devant les cuisses. Le vent souffle, on voit danser les ombres d'arbres projetées par un lampadaire. Et ce chapeau de grande bourgeoise, il me fascine. Tellement ridicule, mais imposant à la fois. On ne peut pas l'éviter du regard. Il y a deux autres en costume noir qui arrivent. Un homme avec une femme assez jeune, qui transportent à bout de bras une longue planche en bois toute ficelée. Les costumes noirs c'est pour les domestiques. Je le sais parce que mon frère a bossé dans un hôtel de luxe. Devant le coffre ouvert, les deux employé⋅es s'arrêtent. On dirait qu'illes attendent des instructions. La femme en fauteuil fait des tout petits mouvements du menton. Son cou ne peut pas bouger, mais ses lèvres articulent des phrases. Les autres l'écoutent apparemment : après son intervention, le gars et la jeune déposent très doucement le colis tout plat à l'entrée du coffre, et illes se mettent à le faire coulisser dedans avec précaution. J'avais tort au sujet des bourges je crois, c'est un couvre-chef qui fait la différence.

Sauf qu'il y a un problème. Ça ne rentre pas jusqu'au fond. Le fauteuil se déplace maintenant. La dame au chapeau fait le tour du coffre pour venir inspecter. Les manutentionnaires ressortent une partie de ce chargement pas très épais mais qui doit être cher précieux. Illes le font coulisser encore un coup pour que ça rentre en diagonale cette fois. Le résultat n'a pas l'air satisfaisant non plus, alors le fauteuil se remet à tournoyer. Elle fait des demi cercles méticuleux en roulant, puis se fige et pivote pour se tourner parfaitement en face du coffre. C'est sûrement un tableau de valeur dans l'emballage. Ou un grand tirage photographique, un truc de collectionneuse d'Art. La portière s'ouvre enfin à l'avant. La situation doit être désespérée pour la forcer à sortir. La conductrice met les pieds dehors sans se presser. Des cheveux châtains courts, lunettes de soleil passe-partout. Elle ouvre une portière à l'arrière, tout aussi calmement, et se penche à l'intérieur du véhicule. Elle n'a pas adressé un regard aux autres. Je les regarde s'agiter quand le bout de planche qui dépassait disparaît entièrement. Tout le monde veut inspecter le résultat. La conductrice se redresse, avant de refermer la portière. Elle fait quelques pas, toujours sans précipitation, en direction du groupe qui contemple le cul du SUV. Avec la femme au chapeau enflé, elle échange un ou deux mots, pendant qu'une bourrasque chahute cette coiffe qui couronne le fauteuil électrique. La fermeture du haillon de coffre se déclenche à distance, et le chapeau ne s'est pas envolé, il est sûrement très bien attaché. La chauffeuse, une main dans la poche, surveille patiemment le mouvement de fermeture. Tout le monde observe le coffre attentivement. Quand il n'y a plus rien à voir, elle retourne sans précipitation s'asseoir au volant. Le vent se remet à souffler. Comme dans mes craintes, tout se précipite. La voiture commence à rouler, vers la barrière du parking. La dame en fauteuil se retourne vers la porte arrière du casino. Deux des employé⋅es sont déjà rentré⋅es. La barrière se soulève, la Porsche franchit cette démarcation. Elle va s'éloigner silencieusement. Je recentre ma visée sur la backdoor. Les pneus cannelés du fauteuil qui s'approchent de la lourde issue de secours. Un coup de vent secoue les grandes ombres autour. Le fauteuil s'est engagé, il disparaît derrière l'acier du battant de porte. Quelques secondes suspendues, avant que cette ouverture ne se replie définitivement.

Mes jumelles braquées sur le carré de lumière déserté, je contemple l'absence soudaine. Elle laisse un goût que je ne sais pas expliquer. Les histoires ont un début, un milieu, et un néant. Je n'arrive pas à me décrocher de cette scène remplie brusquement par le néant, sous l'éclairage automatique qui va bientôt s'éteindre. Illes ont disparu.

Tous les récits qui étincellent. Et jamais de conséquences.

Le vide ne règne pas totalement. Une feuille de papier vole. Happée dans la lumière. Elle décrit une jolie courbe en montant à la verticale, avant de flotter un instant et de redescendre devant ce mur crépi où on s'agitait il y a une minute.

Un simple bout de papier qui pourrait raconter tellement. Est-ce qu'elle leur appartenait, perdue par maladresse dans les déplacements autour du véhicule ? Un bon de commande, un reçu de gains, une note d'instructions, ou même une bête liste de courses...

Un nouveau coup de vent tire la feuille volante dans la direction opposée. À Quelques mètres, dans les buissons qui bordent l'aberration écologique, elle est allée terminer ses volutes.

Je reste les yeux fixés sur cette forme accidentelle prise dans les branchages. Le cœur qui bat à nouveau. L'excitation dépasse même le malheur d'avoir froid et de se sentir seul. Je ne pense qu'à une chose. Descendre là-bas pour récupérer cette feuille de papier. Un petit risque à prendre, comme une nouvelle mise.

C'est la pièce qui va décider. Précipite les conséquences.

Pile, ou face.

[CC BY]

Le vent qui souffle avant minuit vient de se lever. Dans la vallée on dit que ça annonce un temps nuageux. J'enfouis mon menton dans le cache-cou de cycliste, devant le ciel étoilé, et je repense à la boucle qu'il faudra réintégrer une fois mon cul décollé de ce banc. Un sample de réalité qui tourne entre quatre murs. Le hasard décidera de l'heure de mon retour, mais quelque soit le prochain résultat du lancer de la pièce de monnaie, je sais que je reviendrai toujours dans un salon carrelé blanc. Encore une vérité qui laisserait la psy sans voix : les propriétaires dallent leurs appartements tristes comme des labos pour nettoyer plus facilement les traces de nos existences. C'est pas juste du mauvais goût en décoration. C'est intentionnel.

Avant de rentrer dans mon petit studio vide, je veux la suite du spectacle. Il y a eu plusieurs arrivées devant la montée des marches, en bas. Le seul engin qui retient mon attention n'a toujours pas ouvert une portière vers notre dimension. Une voiture diplomatique, est-ce que c'est comme une valise diplo que même les flics n'ont pas le droit d'ouvrir ? Le véhicule reste stationné avec les phares, au tréfonds de la parcelle privative, pendant que les autres voitures tournent en rond devant des barrières sans pouvoir accéder aux secrets de l'arrière-boutique. Une femme à cheveu court est seule derrière le volant. C'est tout ce que j'en sais. Je n'ai pas eu le temps de la voir correctement avant qu'elle ne se gare à l'abri. Elle doit attendre quelqu'un dans sa Porsche, un SUV coûteux mais très commun, rien d'exceptionnel pour un spotteur. Moi c'est le contenu qui m'affole. Je pensais qu'un casino était le comble de l'opacité. Je n'avais jamais réfléchi au vide légal des consulats et des ambassades. Une chambre obscure qui se déplace dans notre espace public tout en se maintenant au-dessus des juridictions des pays qu'elle traverse, ça laisse quand même beaucoup de place à l'imagination. Surtout ici. Pourquoi la conductrice ne descend pas ? Par moment une tache bleutée apparaît derrière les vitres, mais les jumelles ne sont pas faîtes pour observer la nuit. La petite lueur d'écran se noie entre la clarté des phares et celle des illuminations sur la façade du casino. Peut-être qu'elle est chauffeuse, pour un riche client, ou pour quelqu'un qui travaille là. Qu'elle est une sorte de livreuse... ? Avec les privilèges spéciaux d'un véhicule inviolable comme ça, il pourrait y avoir n'importe quoi à l'intérieur. Des trucs illégaux. Je ne peux pas m'empêcher de penser à des choses compliquées. C'est vrai que j'ai un petit côté paro, la psy l'a quand même bien compris. Pourtant ça serait pas surprenant que des bails sombres aient lieu aussi chez nous, même si on est dans un trou à vaches. Les rubriques judiciaires dans les médias sont pleines d'histoires de détournements de fonds et de corruption, jusque dans les petites mairies. Si je me souviens bien, il y avait eu une histoire il y a quelques années, un fils de diplomate qui déplaçait de la drogue dans ses valises protégées par le secret diplomatique.

Le vent qui me glace le nez, ça me sort de mes fantasmes. Je remonte le cache-cou jusque sous les paupières, et je me souviens que je suis en train de brûler le temps en me racontant des histoires. Qu'il va falloir faire un choix pour y mettre fin. Je me souviens aussi qu'en calculant vite fait le ratio, j'ai plus de chances d'être déçu qu'émerveillé, sur ce tapis de réalité. J'espionne ce parking comme s'il allait y avoir un bouquet final, mais ce qui va vraiment se passer d'ici quinze ou vingt minutes, c'est que j'aurai à peine le temps d'apercevoir un dénouement sans intérêt. Encore un. Quelqu'un va sortir du casino et monter en vitesse dans la Porsche. La voiture disparaîtra avec son contenu, sans rien me raconter. Et ensuite, je serai de nouveau tout seul dans la nuit.

J'ai froid. Encore un peu de patience avant de lancer ma pièce pour décider. Même si je ne vois rien d'excitant ce soir, je veux rester jusqu'au bout de ma fiction diplomatique. Je me suis accroché à cette plaque d'immatriculation CD, je dois la voir disparaître sur la route pour pouvoir passer à autre chose. C'est rare d'être encore accroché par quelque chose. Alors j'attends, et je baisse les jumelles. Je visualise l'intérieur des lieux. Dedans il y a la moquette rouge partout. Le bar, sur la gauche, où même les péons comme moi peuvent se prendre pour quelqu'un. Je suis rentré une fois pour voir, au début. Au fond il y a la salle de jeu, barrée par des portiques. Il faut s'adresser à la caisse pour aller plus loin, un grand comptoir où une femme en chemise col blanc reste assise toute la journée à attendre. On ne visite pas le royaume des machines à sous sans acheter d'abord des jetons. Le bar est accessible librement, mais si on tourne en rond sans dépenser d'argent, un vigile s'approche. J'avais imaginé boire un verre là-bas juste pour entendre des conversations de bourges du coin qui se donnent des rendez-vous d'affaires. Sauf qu'une seule conso c'est mon budget des courses pour la semaine. Et puis quand le mec en costume est venu me demander si j'attendais quelqu'un, j'ai eu l'impression d'être un clochard avec mes vêtements de tous les jours.

Oh... Il y a du mouvement au fond du parking privé. J'attrape les optiques grossissantes qui pendent à mon cou. Un éclairage s'est déclenché à l'arrière du casino. Une porte de secours qui s'ouvre perpendiculaire. Elle reste maintenue dans cette position, le panneau gris face à moi, mais je vois personne. L'éclairage extérieur est tellement fort qu'on devine le grain du crépi sur le mur. J'attends celui ou celle qui va se précipiter dans ce théâtre. D'une seconde à l'autre... Allez. Alors, qu'est-ce que vous attendez ?

[CC BY]

Quand j'étais petit, Mamie me montrait comment on prépare un affût. Ne pas se faire voir, observer derrière un interstice. Silencieux, immobile. On consultait les illustrations ensemble dans le guide des oiseaux avant de partir, j'apprenais par cœur ceux que je voulais voir. Le Milan royal avec sa queue en V et ses couleurs rousses. Le chardonneret élégant, bout du bec teinté et les ailes noires tachetées de blanc. Mes volatiles ont des carrosseries mates et des options luxe maintenant. Toujours les fesses contre le banc en haut de la butte, dans le bouquet d'arbres touffus, je zoome sur les lumières des phares. Personne ne me voit.

Des phares qui font un demi-tour sur le parking lointain, avant de s'immobiliser. Pas encore un oiseau rare. Juste une berline allemande à grosses jantes que les jeunes d'ici conduisent le permis à peine obtenu. Le moteur tourne, je vois des vapeurs surnaturelles dans les halos xénon du parking. Personne ne descend. On est le 10 du mois. La paye tombe le 8. Je risque d'en voir des communs, avant de tomber sur les ultra-rares. Mais si je suis patient... Autour des casinos il paraît qu'on rencontre forcément un jour des gens exceptionnels. Dangereux. Des ultrariches, des mafieux. Des politiciens corrompus avec les oligarques des pays bannis. C'est comme une loi physique. Là où il y a des jeux d'argent, ça attire les grands forceurs et les bourbiers. En squattant mon banc j'aimerais en voir un seul, de vrai spécimen. L'élite, il paraît qu'elle existe même si on ne la voit jamais. Ceux qui vivent dans des circuits séparés, avec domestiques, qui ne font pas les courses parce qu'ils ont des cuisiniers et qui ne mélangent pas leurs enfants avec nous, aux grandes écoles privées. Comme un monde parallèle. Mais ils n'ont pas encore aboli la rue, les riches. Il faudra bien qu'on se croise à un moment sur le ruban qui conduit jusqu'aux casinos.

Les phares s'éteignent au loin. En quelques secondes, trois jeunes gars pas assez bien habillés enjambent la dizaine de marches couverte d'un tapis rouge, avant de disparaître derrière les portes vitrées. C'est allé très vite. Comme avec les bêtes, il faut être attentif pour ne pas rater des apparitions. Je ne sais pas combien de temps je vais tenir, seul dans la nuit. L'excitation d'espionner un autre monde m'électrisait, mais l'immobilité, la solitude, il va bientôt faire froid et flemme. Je ne sais plus ce que je cherchais vraiment en venant ici. Encore quelques véhicules à scruter, avant de me résigner. Encore quelques tours de roulette.

Mamie me manque un peu. Elle avait tellement de choses à me raconter. De l'inventivité, quand on s'ennuyait, des solutions à tous les problèmes de la vie. Mes problèmes sont trop différents aujourd'hui... Qu'est-ce qu'elle me répondrait ? Que c'est pas grave si je préfère me raconter le monde autrement ?

De la lumière là-bas. Impossible de s'ennuyer longtemps autour des machines à sous. Il y a un SUV noir qui s'avance lentement. Jusqu'au bout du parking, vers la barrière pour les employé⋅es. Ses phares s'immobilisent devant le portique. Le temps de déchiffrer l'immatriculation. Je crois que ça commence par CD... Corps Diplomatique ? La barrière se lève, le carénage glisse puis s'immobilise, en retrait, dans le périmètre interdit à toute personne étrangère au service. Les phares qui s'éteignent. Mais personne n'apparaît. Un canal invisible me raidit la nuque. Je ne sens plus le froid. Mamie dirait peut-être : Il y a une différence entre vouloir s'amuser et chercher les ennuis.

[CC BY]

This is a test

Ce jour, j’ai reçu 7 précieuses merveilles dans un imposant coffret. À une époque lointaine, on parlait de galettes.

J’ai déposé une première galette sur ma platine cd. En fait, la dernière « Perfect World », puis la première galette « LA Garage sessions ´83 », histoire de commencer par la fin, puis revenir au début de ce cadeau musical proposé par Bruce Springsteen avec son « Tracks II: The Lost Albums ». Du bel ouvrage.

Plus tard, dans la nuit, j’ai déposé une troisième galette, le deuxième album de fait de cette collection, « Street of Philadelphia Sessions ». C’est d’une beauté lancinante et déchirante jusqu’à la profondeur de l’âme.

Je reste scotché à ce morceau « We fell down »

WE FELL DOWN In the dream everything had come undone / I sat in the kitchen and listened to the refrigerator hum / Three A.M. had come and gone / You walked in I knew by that dress you had on / We fell down... we fell down.../ I shoulda known when I asked where you'd been and I heard you lie / We fell down... we fell down... / That was just your way of saying goodbye // We got a book with pretty pictures all in a row / There's only. one missin' baby, that I know / That's the one of you and I / The one where we're lookin' each other in the eye / We fell down... we fell down.../ You said things get lost no matter how hard you try / We fell down... we fell down... / That was just your way of saying goodbye // I woke in the mornin' cold and gaspin' for air / Everything seemed broken beyond repair / The party ribbons and balloons had fallen to the floor / Along with the beautiful costumes we wore // I get up in the mornin', get dressed for work /1 comb my hair and button my shirt / I walk home neath a sky hard and blue / These are the things that I've gotta do / Since we fell down... we fell down.../ And I asked if you loved me, you said, of course you did and sighed / We fell down... we fell down... / But I knew that was just your little way of sayin' goodbye

Nous sommes tombés Dans le rêve, tout s'était défait / Je me suis assis dans la cuisine et j'ai écouté le bourdonnement du réfrigérateur / Trois heures du matin était venu et parti / Tu es entrée, je le savais par cette robe que tu avais / Nous sommes tombés... nous sommes tombés... / J'aurais dû savoir quand j'ai demandé où tu étais et je t'ai entendu mentir / Nous sommes tombés... nous sommes tombés... / C'était juste ta façon de dire au revoir // Nous avons un livre avec de jolies photos dans une rangée / Il n'y a qu'un seul bébé manquant, que je connaisse / C'est celui de toi et moi/ Celui où nous nous regardons dans les yeux / Nous sommes tombés... nous sommes tombés... / Tu as dit que les choses se perdent, peu importe à quel point tu essayes / Nous sommes tombés.. nous sommes tombés.. / C'était juste ta façon de dire au revoir // Je me suis réveillé dans le froid du matin et j'ai haleté à la recherche de l'air / Tout semblait cassé au-delà de toute réparation / Les rubans et les ballons de fête étaient tombés par terre / Avec les beaux costumes que nous portions /Je me lève le matin, je m'habille pour le travail/Je me peigne les cheveux et boutonne ma chemise / Je rentre à la maison / Sous un ciel dur et bleu / Ce sont les choses que je dois faire / Depuis que nous sommes tombés... nous sommes tombés... / Et j'ai demandé si tu m'aimais, tu as dit, bien sûr, as-tu dis et soupiré / Nous sommes tombés... nous sommes tombés... / Mais je savais que c'était juste ta petite façon de dire au revoir.

Merci M. Springsteen.

Pour une critique musicale de ce coffret, je vous invite à lire «The Lost Albums—Tracks II»: les 7 rédemptions de Springsteen, le Boss perfectionniste | Le Devoir.

Tags : #AuCafé #musique

Le non-respect de la vie privée

Meta sait tout de vous :

• Votre nom, courriel, n° de téléphone, âge ;
• Vos clics, réactions, contenus créés, publications, photos, messages ;
• Vos interactions avec le contenu, les publicités regardées ou cliquées ;
• Vos liens avec vos amis, ceux qui vous suivent, et l’utilisation de leurs produits ;
• Vos appareils, vos applications installées, votre navigateur ;
• Votre adresse IP, et donc votre localisation ;
• Les sites que vous visitez, les applications utilisées, les jeux auxquels vous jouez ;
• Combien de temps vous passez sur chaque plateforme ;
• Les n°, noms, et adresses emails de vos contacts ;
• Sur quels points d’accès Wi-Fi, sur quelles antennes mobile et bluetooth vous vous êtes connectés ;
• La localisation de vos photos, les personnes affichées.

Ces données sont utilisées et revendues pour :

1. Mieux cibler les annonces publicitaires ;
2. Entraîner des intelligences artificielles ;
3. Le renseignement commercial ou politique.

Et souvenez-vous :

Lorsque vous dites « le droit à la vie privée ne me préoccupe pas, parce que je n'ai rien à cacher », cela ne fait aucune différence avec le fait de dire « Je me moque du droit à la liberté d'expression parce que je n'ai rien à dire », ou « de la liberté de la presse parce que je n'ai rien à écrire ».

Edward Snowden.

Une porte d’entrée pour la malveillance

Adoptées à grande échelle, mais très peu modérées, ces plateformes sont utilisées pour diverses arnaques, phishing, voire pour prendre le contrôle de l’appareil.

Publicités et algorithmes

Vous ne contrôlez pas ce que vous voyez, car des publicités sont omniprésentes dans votre flux. En conséquence vous voyez des publications que vous ne souhaitez pas, et vous ne voyez pas certaines publications de vos contacts et des pages que vous suivez, car des algorithmes l’ont décidé ainsi.

Quelles alternatives ?

• Pour Facebook, créez-vous un compte sur une instance Mastodon (par exemple, sur tooting.ch ou swiss.social).
• Pour Instagram, créez-vous un compte sur une instance Pixelfed (par exemple, sur pixelfed.ch).
• Pour WhatsApp, si vous êtes intéressés par les fonctionnalités avancées, telles que les groupes, les chaînes… alors installez Telegram. Sinon, installez Signal.

Ensuite, avertissez vos contacts de vos choix et convainquez-les de vous rejoindre. En quelques temps, vous vous rendrez compte du bonheur de votre indépendance, de la joie de pouvoir suivre ce que l’on veut, sans pollution publicitaire et sans risque.