Tutorial 4: Complete workbench process
In this tutorial, the engineering workbench will be completed in its initial version.
By the end of this tutorial, you will have added the final piece of the workbench
and be able to communicate with it. In this tutorial, we will also give two options
for the satellite component of the workbench.
The first option is the recommended one if possible. It involves setting up a
BeagleBone Black board with KubOS Linux and
linking that with the workbench. The second would be ideal for someone awaiting
hardware. It involves creating a series of Flask applications to imitate the
services given in KubOS. This, however, is not very robust and would prevent proper
development of your commands for your satellite.
KubOS OBC setup
For a detailed explanation on how to set up KubOS for any device, see the
documentation here. This tutorial will
give an explanation on how KubOS was set up and installed to a Beagle Bone Black
and how it was configured to run this tutorial.
Prerequisites
- An OBC; for our example, we used a Beagle Bone Black Rev. C. These steps are not guaranteed for other boards,
- a microSD card for the BBB with at least 4GB of storage,
- and the relevant images of KubOS Linux (found here)
Install the eMMC image
To do this, we flashed the SD card as per the documentation. We used Etcher as that
is the KubOS software of choice, however, Rufus does provide a reliable alternative.
To flash the SD card, simply open up Etcher and follow the prompts. Firstly, you
will need to select the image file you want to flash. For this step, this will be
kubos-linux.img
.Once this is done, all four lights should turn on after a successful flashing. If
all lights turn off on the beagle, you will need to re-flash the eMMC.
Install the auxiliary image
Following this, remove the microSD card and plug it back into your computer as we
are now going to flash it with the auxiliary image (
aux-sd.img
). After this,
plug the microSD card back into the Beagle and apply power.The board will then go through its booting sequence and will likely take up to an
hour to boot up the program. Once this is complete, you can then SSH into the Beagle
and begin working with KubOS.
For more information on this and how to use KubOS, go to the documentation via the
link above.
KubOS placeholder construction and setup
In the situation where we might not be able to run a local instance of KubOS, or
we do not have an OBC available, we can develop our own applications to act as the
satellite's services until such time a better replacement can be found. It must
be noted that these applications are very basic and are only designed to receive
pings. The services used in the examples given in the Javelin folder and in these
tutorials are the app, monitor, schedule, and telemetry services. These are going
to be recreated here.
App service
The following script mimics the application service in its most basic format using Flask
Monitor service
In a similar way, the monitoring service can be modelled by
Scheduler service
The scheduler service is modelled by
Telemetry service
Finally, the telemetry service is modelled by
Port mapping
To configure the radio emulator to talk to these apps, you will need to update
the port mappings in the
javelin-main/javelin-scepter-python_scripts/source/tools/commands/utils.py
file. For the above examples, the port mappings looked like the following:Workbench section 3: sending commands
Before we can send the commands we created in the previous tutorial, we need to
activate our KubOS satellite and BBB radio emulator. For this example, we will use
the placeholder above. To activate the service applications, simply run each of
those scripts. From the Javelin directory, run the
radio.py
script located in
the BBB radio emulator folder. This will activate the radio for the BBB (in our
case, the local machine). Once these are all up and running, the commands can be
sent.To send the commands, the
execute_operator_cmds
function was extracted from the
send_cmd_script.py
file. This begins the sending process. The Python script
for this looked like this.During this period, the terminal will output something similar to:
At the end of the command process, the
end_contact_instructions
function (seen
below) is used to tell Scepter that the command instructions have been completed.
As you can see, the above output showed the ping commands being sent to each of
the services and a successful pong return was received.and the input is given by:
Congratulations, you have completed four of the five OSSO tutorials. We can now
successfully send a command through our workbench via Javelin and receive a
message back. Our final tutorial in this series will
look to upgrade this process to account for the orbit of our satellite.
Table of contents