Blocked by #4

cleanup the current codebase a bit. Some bits are not used anymore

Any thoughts on nested model classes? heres what I mean:
right now we have:

class Detection 
    {
        private Integer id;
        private Integer batonId;
        private Integer beaconId;
        private Timestamp timestamp;
        
        //...
    }

Meaning if we want to reference the baton of this particular detection
we need another DB query. This is cumbersome, but it makes update queries simple, and stores no unnecessary data in memory.

we could turn it into something like this:

class Detection
    {
        private Integer id;
        private Baton baton;
        private Beacon beacon;
        private Timestamp timestamp;
         //...
    }

which makes referencing nested objects easier, but makes updates more complex.
It also stores unecessary data, as these nested objects may never be used.

Im keeping it as option 1 for now, as it's simple and this is still an mvp. But any comments on this are appreciated

See the database wiki page for details.

Add a field to the detection model that shows when the detection was received into telraam.

Writing and extra module or scripts to load test the application.
To test the

• Beacon communication (TCP)
• API (HTTP)

Send what

• Send tons of messages
• Open tons of connections

The logic component is the core of the system. It takes registration events as an input and writes laps to the database as an output.

CI is currently failing, This should be resolved.

At the moment compiling the code is enough.
Afterwards some tests might be nice, bu the current ones are not that usefull

Getting our data in and out of the database.

Mirror the current system to use multiple lappers but then for positioners.

We want a way to track switchovers between lap sources. We decided to do this the following ways:

• Add a table containing the timestamp and destination of a switch
• Add an endpoint to get the lap count

Some examples of how to write tests for telraam, and links to JUnit docs and tutorials

Some basic layout should be present before we get started.

Right now, when manual corrections need to be added, they are added via the SimpleLapper. This has the unfortunate effect that the timestamps of the extra laps are not saved in the database, making it harder to replay events for developing new algorithms.

I think that every lapsource should have its own 'corrections' data, instead of this being a global thing done with SimpleLapper

A simple webview querying the api.
It should at least display as much information as the old CVC webview, but more is better.

Focus on features, not styling.

It would be nice to be able to mark a station as "known defect", so lappers and visualizations can display this

The hardware simulation scripts are still using the 'old' message format.
In the future, we are planning on using the old cvc format.

STATION_MAC,IGNORE,BATTON_MAC,RSSI\n

We should decide on what kind of message the beacons should send to the telraam instance when they detect a baton.

We've successfully configured an adafruit nRF52840 to transmit roughly every 100ms, which we think is the solution to the excessive amount of missed detections.

We now have to determine what sort of range we can expect from the modules when paired with the actual beacons and actual bluetooth receiver we will use on the event.

The lapper algorithm itself is pretty simple, so it can be implemented in Java. It's currently written in Python, but should be ported to Java. See chapter 'Counting laps (Simple lapper)' in https://github.com/12urenloop/algorithm-tuning-notebooks/blob/yeet/additional_new_algorithm_testbench.ipynb

In our monitoring setup, we verify that the time of all components (ronny's, telraam, manualcount, ...) is synced. In order to do that, we need an endpoint /time that returns a JSON dictionary that looks like this:

{"timestamp": 123}

The timestamp value should be an integer of the amount of milliseconds since the Unix Epoch (so the Unix timestamp * 1000)

A suggestion was raised by @redfast00 to consider a poll-based architecture. This would mean that beacons do not send messages to Telraam, but store their detections and provide a simple endpoint where Telraam can query for all the messages from a certain timestamp.

It is as of yet unclear what advantages and disadvantages this would bring, so discuss below.

One thing to mention is that it should not be too difficult to implement both with the current architecture.

This component will handle communication with the boxxy proxy.

A better positioner

A positioner is an algorithm which will calculate the data needed to represent each team on the position visualization which will be created by @Topvennie.
We would need a manager like we have for lapper so we can get data from it via the API but also select an active one which will send its data over the websocket opened by loxsi

Currently, this is the same, which makes it hard to change jacket numbers of a team

Title speaks for itself, should be implemented in the LapCountResource class

Grafana is very handy to use with a json api. The problem now is that our data is flat and there are no nested objects.
So laps have the team-id and no name. Grafana as far as I know cannot do recursive requests which makes visualisations very hard to read.

There are a few solutions here.

• Add some nested data to the existing endpoints. For example add the team object to the requested lap. Could then be used with https://grafana.com/grafana/plugins/marcusolsson-json-datasource/.
• Add a query endpoint that can handle specific requests. This needs to be very specific and is not very easy to implement. Could be used with https://grafana.com/grafana/plugins/simpod-json-datasource/
• Add graphql. The client can then choose it's own structure. Could then be used with https://grafana.com/grafana/plugins/fifemon-graphql-datasource/.

The graphql seems the most sensible and powerful. Can also be used by other clients without the pollution of the basic rest api.
I'm going to start there, but suggestions, counter arguments and other options are welcome.

The stations return a float, precise to more than a millisecond. Telraam (the fetcher component specifically) pulls this in and converts it to seconds before saving it in the database.

A working postgres setup will be required for working on the development build. Docs for the most common OSes should be provided.

This component is the gateway between the hardware and the rest of the application. It listens to hardware messages and logs everything to the database. It also sends the appropriate hardware events to the logic.

We need to know where each station is positioned along the track. Maybe the order will be enough (eg. station B comes after station A along the track) but having the approximate distance will probably be handy.

Script to simulate a reasonably realistic hardware setup. Should generate or play back hardware messages and send them to the telraam instance.

Add an endpoint where loxsi can open a websocket to. We should be able to send data to out from other classes (singleton pattern?)

For my ML project, I made this: https://github.com/FKD13/12urenloop-hmmlearn

This should now be implemented in Telraam.
Will probably consist of:

• Creating a Python Web server that does the counting
• Creating a Telraam "Lapper" that proxy's communication (Possibly as a generic external HTTP lapper for further projects?)

It used to have value as an example of a very simple lapper, but now RobustLapper is a better example (that also actually adds laps)

At the moment, there are two occasions when we'd like to use a null batonid in a batonswitchover:

• a null previousbatonid: this is useful at the start of the competition, so teams are only assigned the detections of the baton after the competition has started
• a null newbatonid: this is useful at the end of the competition (or when a team stops running)

We used to do the previousbatonid null case by just having a fixed baton that isn't used and using that id. This works, but is ugly in the database. At the current 6urenloop, we used null, which worked for the HMM lapper, but not for RobustLapper (fixed now)

We still use a fixed newbatonid of a baton that is not in use for the end of the competition; we should test that a null id works for newbatonid to deassign a baton

ATM, at the end of the event we add a "void" baton where we assign all teams to as end switchover. I don't know if this was intended.

At the moment, new stations that get added to the database while telraam is running don't get fetched untill telraam is restarted. It might be desirable to dynamically create these threads when a new station is detected.