New and hopefully improved application to count laps of the 12urenloop event
All of the documentation is gathered in the wiki.
Get started contributing here
New and hopefully improved application to count laps of the 12urenloop event
License: MIT License
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
Send what
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:
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.
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:
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.