The current dynamic sky component needs to be replaced.

When the component is cleaned up a bug out of our control borks the application.

Implement and allow user to customize their keybinds.

Straight up just copy vscode's keybind.

Eg:

[
  {
    "key": "shift+1",
    "command": "changeLayout",
    "args": { "layoutName" : "mapTracker" },
    "when": "!modalOpen"
  },
  {
    "key": "shift+k",
    "command": "nukeDatabase",
    "when": " env === 'development' "
  },
{
    "key": "`",
    "command": "openCommandPallete",
     "when": "!modalOpen"
  },
]

We can just save it on local storage now and add event listener for each combination.

• BONUS: A vscode like keybind editor component or page

Currently the NavBall only displays the current rotation and its not that much precise/visible

Add Gizmos that show

• Prograde and retrograde (Velocity vector)
• Normal and Anti-normal (Ground Normal Vector)
• Arbitrary Target

Additionally have labels to the screen (preferably spread out on all corners)
Containing information such as: heading (N/S/E/W), GPS Coords/ miscellaneous positional info

It's pretty neat!

https://www.skeleton.dev/

Things like their AppShell, Local Storage Store, Modals can reduce a lot of the website boilerplates.

Describe the Bug

Currently everything is being imported at load time.
Increasing the amount of transfers and amount of Javascript loaded by a lot.

It has a pretty small impact for now but it will definitely add up as we add more libraries and components.

Check this example for how to do it with the import function: https://svelte.dev/repl/6db375be880441299f7721b54434068f?version=3.38.1

How will I know if I solved it?

A: If you open the DevTools on the network tab you'll see that there is a bunch of javascript modules that get loaded at the same time.

They are not expected to be load on the client until they are actually used in the page.

From this diagram the middle ware server should be independent its API consumer.

Currently RocketStatus is being calculated client side in a component.
This is bad because if we have two or more components or even two people connected we would send repeated data.

A few possible altenatives are:

• Have it be calculated in a View Collection for RocketStatus
• Separate service for calculating those sort of metrics
• Writable that tries to calculate that using the latest data or previous data with filters (eg: sort by altitude for max altitude)

Create a component to be used with our docking layout...

That displays:

• The Lat/Lon position of the rocket
• A Satellite map that automatically follows the rocket

These should be similar to the one already in the Recovery page

You may create some mock data on the store.ts file (there is already an example you can follow)

Also make sure to report when was the latest message reported

We need to convert the CAP'N PROTO description files eg: test.capnp
to Javascript or Typescript (preferably)

You can find a list of implementations here

We are literally doing rocket science!

We need to have at least a few tests e2e to verify that RGS is accessible, that buttons, panels and most things work for quality assurance when real deal comes.

• Add the playwright library

• No need to add any specific tests but we would probably need a setup script to also run the ZeroMQ proxy and a mock provider

  • Have it at least check if the website load and its title is set to RGS

We want some way to know if the service is alive. What does a healthy service look like? Radio is plugged into USB, dropped messages rate, etc. This endpoint should return 200 if all is good and (pick the appropriate one from the list https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)

• Update typescript bindings from the artifacts from the Hydra repo
• Update the random data generator to generator those types

Some work is already on foo and f/type_migration

Looking for something that provides:

• A 3D view or at least one that can give better indications of altitude
  • eg: https://cesium.com/platform/cesiumjs/
  • Still offline(able)

Out health tab currently allow us to check if a service is up or not:

But it doesn't quite gives us an in-depth sight on why that is.

eg:
A brief: Unreachable, Not Serving, issue with component, etc message.

It would be interesting if we could see a reason for it and optionally click on each item to see its logs in real time

At the last launch site, I noticed that the rocket was incorrectly rotate by -90 degrees around the UP axis.
Might be an issue with the coordinate system, I think "north" should actually be "west".

This issue is also currently blocked by us not having any boards to verify it with.

We would want to have preset layout for each member of the team.

In addition, buttons to restore or add windows to the layout would be neat
(because if you delete a window by accident you're out of luck)

The best way to do it isn't quite straightforward but we could discuss

Blocked by #77

We need a T- and T+ counter.
Switching from T- to T+ at lift off.

We are literally doing rocket science!

We need to have at least a few unit to verify the behaviors of some components.

Since we are using SvelteKit adding something like Vitest would be pretty optimal.

• Add Vitest
• Add one tests to any simple component

For more help read: Unit Testing Svelte Components

In the root folder there is a folder called client with an auto generated .svelte-kit file.

Is there any reason for this to exist @MarwanMashaly1?
or maybe it was created by accident 🤔

This little guy currently doesn't do anything.

We might want to ping the server once in a while (every 3-5 seconds) to check our ping and other things

It's kind of whack at the moment.

Please keep Smart and Dumb components separate.

A component is considered smart if any:

• It has a considerable amount of subcomponents
• It has a considerable amount of JavaScript
• It connects to the database
• Is not "standalone" (other than using modules) (eg: Uses a store)
• It wraps a dumb component

Here is the new intended folder style

• src/lib/components
  • smart
    • RocketTracker
    • RocketNavBall
    • MissedMessagesGraph
    • RocketNavBall
  • dumb
    • Map (with configuration given by props)
    • NavBall
    • Timer
    • CheckboxSelect

If in doubt just have it as a smart component.
If a smart component has a few subcomponents that are also smart, group them in a folder.

The RFD 900+ should interject MAVLINK packets about the status of the radio. The proxy needs to handle this so we can measure the strength of the link. This can be added after the mavlink branch is merged.

So far, this is a possible solution but there might be better ways:
https://allartk.github.io/leaflet.offline/
https://github.com/allartk/leaflet.offline/tree/master

hydra_provider is currently using a stub implementation for the GRPC server.

We would like to have an exposing API that allow us to:

• Check the current running configuration of hydra_provider (health and status)
• Change configurations (set data mode: random, serial port, idle; select a desired serial port, set baud rate, etc)

And optionally a simple UI front-end for it.

It seems that a quite big refactor would have to be made for it to work as the currently hydra_provider architecture doesn't allow it.

Using Threlte makes it easier to create scenes without having to worry about adding/removing or cleaning up elements

We could switch to using Esri

Before going v1 we would likely want to have a CI workflow that builds (and optionally creates a releases):

• rgs-web
• The hydra_provider

Click here to learn more about Github Actions

rocket-code-2020
and hydra also have a few examples

Before maximizing

After maximizing

The correct behavior should be that there is only a single map visible

• error rate seems to be always 99%
• messages are always getting messed when they are not

Write a new service/app that allow us to interface with LabJack.

Reach @NoahSprenger for more info

The LabJack service should:

• Rebroadcast messages from ZMQ network
• Receive command allowing it to be "remote controlled"

We'd like to be able to see the vertical velocity of the rocket.

The implementation and design is up to you.

I'd like to be able to:

• Have a visual representation of the current vertical velocity
• Have numbers displaying the current vertical velocity, if you're a math person you could even add extra things
• [BONUS] Have some axis labels on the visualization

Remember, the design is up to you, there is no right or wrong way to do it.

We don't quite want to rely on hydra_provider to send mock messages.

• We require a basic input box to send a raw messages
• BONUS: Have hydra_provider be able to read a to-be-defined Command message
• BONUS++: Have hydra_provider be able to send the messages via radio

Currently they're autogenerated.
The downside of that is that there is no tooltip display or obvious way of knowing what a certain label is.

It would be nice if they were more organized and obvious.

It is currently bound to hydra_provider, make it standalone

The install file on labjack_provider/vendor/labjack/install.sh currently requires root permissions for Labjack to work.
Context: Labjack hardcodes its logs and configurations to /usr/share/LabJack/ and unfortunately LabJack is not open source

I'd like to find a way to be able to run labjack_provider without root permissions.

The current LogView does not quite suit our needs for inspecting the messages.

• Have a table that displays the latest ZeroMQ messages from the raw collection on the database
• Most if not all raw values should be JSON values.
  • Add an extra inspector for when we click on JSON message (rocket message etc)
• BONUS: Allow for searching full text search see: filters
• BONUS: Custom inspector viewer per message type

Add a summary for all critical information to have beside the panels page to be able to monitor the status of different components.

• button on the top right

See https://github.com/uorocketry/rocket-code-2020/blob/master/src/IO/gpio/DCMotor.cpp https://github.com/uorocketry/arduino-io-proxy/blob/master/src/dcMotorMessage.cpp

We would like to have a simple charting utility for things such as real-time graphs

Anything minimal would probably work for now

You can try Billboard.js, Chart.js you can also try D3.js but its a bit more advanced

Allow Flight director to:

• set a launch point
• set a launch time
• set target altitude (+ see delta from target altitude)

Then:

• Display the rocket distance from target altitude
• Display total traveled distance from launch point (lat+lon distance)
• Countdown time from launch time

Create or modify a component that allow us to see the:

• Current + Max G Force
• CUrrent + Max Velocity