diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5dd3adea8..f578b1cf5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,7 +22,7 @@ If the issue is not created yet, go to the issues page and create a new *task* i * If the issue is specific to one module (e.g. backend, ethernet view, etc.) start the title with `[module_name]`, changing *module_name* to the appropiate one. * Add the appropiate labels: is the issue related to the *frontend*, the *backend*, is it a *documentation* task? Try to identify these before creating the issue. * Assign yourself (or the member who will work on it) so they get notified with updates and everyone knows what everyone is doing. -* Add the issue to the `Software H9` project to keep track of its progress. +* Add the issue to the `Software HX` project to keep track of its progress. * Assign the issue to a milestone if possible. * Describe the task briefly. Write some lines on the task itself, what should be done, any details, notes on it, etc. * Add related issues / PRs. This is not required, but is useful, specially when tasks get blocked by other tasks. @@ -36,7 +36,7 @@ Of course don't become too obsessed with this, it's always best to try out somet It is also recommended to ask other members their points of view, what they are doing, dependencies they might have, etc. To get more ideas and ensure your changes won't screw with other person changes. -Also make sure to take notes, maybe in `software-docs` or as a comment on the issue, with anything relevant you found from this research. It might even be necessary to open new issues if you find anything outside the scope of the task. +Also make sure to take notes and create a wiki entry with anything relevant you found from this research. It might even be necessary to open new issues if you find anything outside the scope of the task. But once again, don't take more than a day doing this. @@ -66,7 +66,7 @@ Examples of good branch names are: `backend/tcp-keepalive-error`, `ethernet-view Some bad examples are: `abc`, `backend/minor-fixes` or `unrelated-module/some-feature`. -### writing code +### Writing code With the latest changes ready, the new branch created, and everything set up, you are ready to write code at last. These are some guidelines on how to make good changes: @@ -74,7 +74,7 @@ With the latest changes ready, the new branch created, and everything set up, yo * Keep commits atomic. These are commits that change just one specific thing, allowing the app to be compiled before and after. * Don't extend a branch life time, try to merge changes as soon as possible. If there are a lot of changes create multiple PRs and do it progresively. * Keep PRs small. Of course there are exceptions to this and sometimes a PR will have more lines than others. -* Document what you do, dedicate some time to write down the why and how of your changes. Documentation not that related to the code should be written to `software-docs`. +* Document what you do, dedicate some time to write down the why and how of your changes. Documentation not that related to the code should be written to the wiki. * Try to test the code. Prepare at least a primitive test to ensure it works, of course, it is better if tests are automatic, but in some cases, it is just easier to check by hand. ## 4. Open pull request diff --git a/README.md b/README.md index 9e4ab3218..e72f263fe 100644 --- a/README.md +++ b/README.md @@ -1 +1,32 @@ -# Software +# Software - Control Station + +[![CI](https://github.com/HyperloopUPV-H8/software/actions/workflows/build-backend.yaml/badge.svg)](https://github.com/HyperloopUPV-H8/software/actions/workflows/build-backend.yaml) +[![CI](https://github.com/HyperloopUPV-H8/software/actions/workflows/build-ethernet-view.yaml/badge.svg)](https://github.com/HyperloopUPV-H8/software/actions/workflows/build-ethernet-view.yaml) +[![CI](https://github.com/HyperloopUPV-H8/software/actions/workflows/build-control-station.yaml/badge.svg)](https://github.com/HyperloopUPV-H8/software/actions/workflows/build-control-station.yaml) + +Hyperloop UPV's Control STtaion is a unified software solution for monitoring and commanding the pod in real time. It combines a back-end (Go) that ingests and interprets sensor data–defined via the JSON-based "ADJ" specifications–and a front-end (Typescript/React) that displays metrics, logs, and diagnostics to operators. With features like packet parsing, logging, and live dashboards, it acts as the central hub to safely interface the pod, making it easier for team members to oversee performance, detect faults, and send precise orders to the vehicle. + +### Installation + +Download the last release, unzip it and leave the executable compatible with your OS in the folder. + +### Developing + +The main project file is inside `backend/cmd`. Make sure to have the proper `config.toml` configuration and that you are in the `develop` branch. To build the project just run `go build` inside the folder. With everything set up execute the `cmd` executable, then move to `ethernet-view` and run `npm run dev`, then to the `control-station` and do the same. + +### Contributing + +See [CONTRIBUTING.md](./CONTRIBUTING.md) for ways to contribute to the Control Station. + +### Authors + +- [Juan Martinez Alonso](https://github.com/jmaralo) +- [Marc Sanchis Llinares](https://github.com/msanlli) +- [Sergio Moreno Suay](https://github.com/smorsua) +- [Felipe Zaballa Martinez](https://github.com/lipezaballa) +- [Andrés de la Torre Mora](https://github.com/andresdlt03) +- [Alejandro Losa](https://github.com/Losina24) + +### About + +HyperloopUPV is a student team based at Universitat Politècnica de València (Spain), which works every year to develop the transport of the future, the hyperloop. Check out [our website](https://hyperloopupv.com/#/) diff --git a/backend/README.md b/backend/README.md deleted file mode 100644 index 9aa50e353..000000000 --- a/backend/README.md +++ /dev/null @@ -1,26 +0,0 @@ -# Ethernet View - Backend - -This is the official backend for the HyperloopUPV verification software *Ethernet View*. - -## Building - -The main project file is inside `cmd`, each of the folders contains one version of the backend, the latest is the one with the highest number (so `cmd/MVP-2` is more recent than `cmd/MVP-1`). -To build the project just run `go build` inside one of these folders. In order to run there are three more files that need to be present in the same folder as the executable: - -* The frontend build located in a folder named `static` (as the backend also serves the webpage) -* A `.env` with all the configuration options (the one in the repo lists all the possible options) -* The `secret.json` to access the Google API to download the excel (this is only available to us) - -alternatively you can download a version that is ready for production from the releases. - -## Authors - -* [Juan Martinez Alonso](https://github.com/jmaralo) -* [Sergio Moreno Suay](https://github.com/smorsua) -* [Felipe Zaballa Martinez](https://github.com/lipezaballa) -* [Alejandro Losa](https://github.com/Losina24) - -## About - -HyperloopUPV is a student team based at Universitat Politècnica de València (Spain) working every year to develop the transport of the future, the hyperloop. -[Our website](https://hyperloopupv.com/#/) diff --git a/backend/docs/docs_structure.md b/backend/docs/docs_structure.md deleted file mode 100644 index 23759a19a..000000000 --- a/backend/docs/docs_structure.md +++ /dev/null @@ -1,42 +0,0 @@ -Cada punto es una carpeta y cada subpunto es un archivo. Cada archivo debe explicar su concepto de la manera más directa. -La intro de cada sección será similar a los intros de los apartadas de The Rust book: uno o dos párrafos que resumen el concepto que engloba lo que se va a explicar y porque es necesario para el backend. -Cada documento puede contener extractos de código a modo de ejemplo. - -1. Introducción - 1. Intro + Funciones fundamentales de la estación de control. - 2. Guía de instalación + simular el back -2. BBDD - 1. Intro - 2. Estructura de ADE - 3. Descarga del excel con la API de Google - 4. Construcción de pod_data en varios pasos - 5. Detección de errores -3. Pod comm. - 1. Intro - 2. Setup Switch + Raspi y sniffado - 3. TCP: keepalives -4. Decoding - 1. Intro - 2. Modelos pod_data - 3. Discriminación de datos: vehicle.Listen() - 4. Funcionamiento del desparseo (mapas de decoders) -5. Enconding - 1. Ordenes -6. Protections -7. Data logging - 1. Intro - 2. Interfaz Loggable - 3. Posibilidad de usar ctx para coordinar los diferentes loggers. - 4. Loggeo redundante en el vehículo. -8. Front comm. - 1. Structs JSON - 2. Throttling - 3. Media movil - 4. Ws_handle: suscripción a temas. -9. Extras - 1. Tracing - 2. Patron de observables - 3. Configuración con TOML - 4. BLCU - 5. Multiples servers -10. Ideas para el año siguiente diff --git a/ethernet-view/README.md b/ethernet-view/README.md deleted file mode 100644 index 3c30f51dd..000000000 --- a/ethernet-view/README.md +++ /dev/null @@ -1,19 +0,0 @@ -# Ethernet View - Frontend - -This is the official frontend for the HyperloopUPV verification software *Ethernet View*. - -## Building - -To build the site, run `npm run build` in a terminal set at the root of the project. Then rename the generated folder to static and follow the instructions in the "Building" section of the backend repository. - -## Authors - -* [Juan Martinez Alonso](https://github.com/jmaralo) -* [Sergio Moreno Suay](https://github.com/smorsua) -* [Felipe Zaballa Martinez](https://github.com/lipezaballa) -* [Alejandro Losa](https://github.com/Losina24) - -## About - -HyperloopUPV is a student team based at Universitat Politècnica de València (Spain) working every year to develop the transport of the future, the hyperloop. -[Our website](https://hyperloopupv.com/#/)