This week I have started my first sprint. This project is relatively complex. A fear with this kind of project that a lot of time will be spend on research and design without implementing or testing the architecture. To remedy this, I have decided to work iteratively on each aspect of the project. Every sprint I will research, design, implement and test a part of the project. Early on I want to have some working version and each week the architecture and will be improved.
Architecture Design
For this week I wanted to make an initial architecture design that facilitates development of the first sprints. The design should make a separation between the terminal operating system and simulation. I researched some existing simulation designs. Unfortunately, I could not find any microservice based simulations. The existing simulations designs I found were not apt material to include in the architecture design.
My main goals were to have a clear separation between the TOS and Simulation, Realistic simulation dependencies and easily refactorable. I think I have achieved my goals with this design. The design will be explained in the documents. The basics are that each block is a serice that communicate through gRPC.
First Epic: Straddle Carrier Movement
After creating this design, I stared with the first Epic: “Basic straddle carrier movement”. I divided this Epic into three stories with corresponding tasks.
Then I worked on these tasks. By the end of the week, I had a first working version of the ScHardware and TransformProvider services. Using a tool such as BloomRPC you can send coordinates to the ScHardware service to drive to. It will then communicate with the TransformProvider service and slowly move towards the target direction. The ScHardware service does not store the position. Nice thing about this is that when the ScHardware closes or crashes the location of the Sc will remain intact. The Sc controller that will be build on top of this will not be able to decide the position just target of the Sc. So, no teleportation errors can occur, and the simulation API resembles real dependencies TOS have when working with hardware.
Currently there is no connection to the visualization. I am rendering to the console for testing purposes.
Next week I want to connect to the visualization. By creating a VisualizationBridge that can receive JSON messages and pipes them directly through to the Unity visualization. This will be a temporary visualization. Later, I will work on creating a more suitable API and probably have a message queue between the simulation and visualization.