Update READMEs

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,15 +66,15 @@ 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:
 
 * Keep changes to the module you are working on, if your task involves multiple modules make the changes in the first module's branch and then switch to the second module's branch.
 * 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

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/#/)