kubos / kubos-old

An open source platform for satellites

KubOS

KubOS is an open-source software stack for satellites.

The KubOS system is designed to take care of every aspect of a satellite’s flight software.

Rather than operating as a single, monolithic entity, KubOS is comprised of a series of independent, yet interoperating components.

• Mission applications control and execute the logic necessary to accomplish mission goals
• Services expose hardware and system functionality with a controlled and uniform interface
• Kubos Linux provides the base operating system and the drivers needed to communicate with connected hardware devices

Company website

Main Documentation Page

Getting Started

Here are some docs which we recommend you look at first when getting started with KubOS:

• KubOS Design - A high-level overview of what KubOS is and how it works
• Getting Started with Local Dev Environment - Docs for getting started with KubOS using a local dev environment of your choice
• Getting Started with the Kubos SDK - Docs for setting up an instance of the Kubos SDK as your development environemnt. Highly recommended for Windows users
• New User Tutorials - Tutorials which will walk you through using all of the major components of KubOS

Contributing to KubOS

Want to get your code to space? Become a contributor!

Check out our doc on contributing to KubOS and come talk to us on Slack to join our community.

Or, if you're just looking to give some feedback, submit an issue with your feature requests or bug reports!

Repo Components

These are the important folders in this repo:

• apis - Contains all of our hardware APIs as well as our application APIs
• clients - Contains client programs which can be used locally to communicate with the corresponding service on a remote target
• docs - Contains all of the raw doc files used to generate our documentation
• examples - Various example KubOS projects
• hal - A collection of hardware interface abstractions
• libs - Helper libraries used when building Kubos services
• services - Contains all of the Kubos core services and hardware services

Related Repos

• kubos-linux-build - Repo used for configuring and building KubOS images
• cargo-kubos - Repo for a Cargo subcommand which will assist with cross-compiling Rust projects for KubOS
• kubos-vagrant - Repo used to build the Kubos SDK

kubos-old's Issues

Doc Re-Org

Problem
There are too many links on the left-hand menu of our docs page (I shouldn't have to scroll to find the link that I want). This is irritating for me and potentially overwhelming for new users.
Proposed Solution
A less-flat doc organization

Check out the beta docs and let me know what you think:
http://docs.kubos.co/sphinx/

Note: This is by no means polished. There are still lots of overview blurbs and things that could be cleaned up.

Kubos 1.0 [Milestone 1]

• Telemetry
  • Telemetry/Pub/Sub: Refactoring & Testing integration KUBOS-277
  • Pub/Sub: Make subscribers dynamic KUBOS-272
  • Pub/Sub: Make topic subscription dynamic KUBOS-271
  • Linux Telemetry: Inter-process Communication KUBOS-350
  • Linux Telemetry: Logging Refactor RTOS (uKub) logging into main repo KUBOS-280
  • Linux Telemetry: Logging integration KUBOS-207
  • Linux Telemetry: Build a Kubos service KUBOS-281
  • Linux Telemetry: Build a Kubos user application KUBOS-282
  • Linux Telemetry - Create the Kubos Linux Telemetry Service KUBOS-283
• SDK/Tooling
  • Kubox Linux Tooling: Flash utility
  • Kubos Linux Tooling: Toolchain(s)
    • TODO: Need to know how/when the OS and lower-level files will be loaded onto the board? When someone orders an OBC and wants kubos-linux, what does that process look like? Question answered, the kernel will be loaded.
  • Kubos Linux Tooling: Target KUBOS-334
  • Kubos-cli updated interface to work with Linux
    • Kubos-cli: Create a user application KUBOS-330
    • Kubos-cli: Upload a user application KUBOS-335
    • Kubos-cli: Debug a user application KUBOS-329
  • Misc Packaging (Unknowns on SDK administration, TBD)
• Final Release Process
  • Documentation (Unknowns: TBD)
    • Kubos-cli: Improve and complete documentation KUBOS-198
  • Vagrant image published to Atlas
  • kubos-cli to PyPi
  • Integration/Manual QA/Testing (Unknowns: TBD)
  • Integrate Jenkins/GitHub/CI/CD

Need some lightweight commands for the ci module

It would be helpful if there were some command line flags and supporting methods for, e.g., "power the board up" with no flash/binary required. You can do this by jumping into a Python shell and creating a specific instance of a Target object, then myboard.setupboard(), then myboard.powerup(), but a lightweight path to that simple goal is worth doing. I'm self-assigning it.

1.0 Release Checklist

Kubos Repo

• Ensure all PR’s Have been Merged (That are going to ship in the new release).
• Push Kubos Changelog.
• Verify Kubos repo Circle Test Pass (Building all Example projects)
• Generate Doxygen Docs
• Review Docs before publishing to docs.kubos.co. Fix bugs as needed.
• Publish docs to docs.kubos.co
• Tag with the new version number and push the tag to Kubos Repo

Kubos-CLI

• If you want the CLI to have a version number update the module.json file in the kubostech/kubos-cli root directory with the desired version
• Merge all the desired feature PR's for this release to Master
• If the Circle builds passed 💥 You're automagically released

Kubos-Vagrant

Automation Script:

• cd Into the kubos-vagrant/builder/ directory in the kubos-vagrant repo
• To provision, test, upload and release a box boxes run `./main.py --all <box_name> <version_number>
• To provision and release both boxes use the box name “all”

[KUBOS-456] pre-1.0 Doc Audit

Things that should be updated before v1.0 is shipped:

Main.md

• possible to add a search feature? #97
• Possibly add a 'developer' category? This is things like making CLI or kernel changes (contributing and coding standards could be moved here)
• Graphics are nice...

kubos-standards.md (KUBOS-469)

• Add more stuff to this. Have we decided on standards?

contribution-process.md (KUBOS-464)

• Add link to coding standards doc
• Create a Pull Request
  • Mention that creating Pull Requests early is appreciated, just mark as '[WIP]'
  • Create a Pull Request - Typo "'name}'"
• Add section for automated testing

sdk-installing.md (KUBOS-458)

• What is the Kubos SDK? - List of components doesn't include Vagrant
• How does the SDK work?
  • Should 'vagrant' be capitalized?
  • "Vagrant is a nice interface that abstracts the virtualization provider into a simple to use interface" - 'Interface' is used twice; change one of them. 'simple-to-use' should be hyphenated.
• Prerequisites
  • Install VirtualBox - Convert both download links into bullet points and put the links first so that they're more noticeable.
  • Install Vagrant - 'Make sure vagrant installation is set up properly' - How do you know that it is?
• Set-Up - Change to "Setup"
  • Create your Kubos SDK Vagrant Box:
    • Two sentences in a row starting with 'Vagrantfile'. Change one of them or merge them into one sentence.
    • Change 'cd' to 'navigate'
    • Change 'this same directory you have initialized the box in.' to 'this directory.'
    • Add instructions if 'vagrant up' completes and the log says that there's a new version of the box available.
  • Mounting a host directory:
    • Document that Kubos SDK projects should not be created in a shared folder if the host OS is Windows (no support for symlinks)
    • 'located in the directory you ran vagrant init inside of in the above step' -> 'located in the directory from the previous step'
    • Make 'Note:'s bold
    • Since paths must be absolute, document the home directory (/home/vagrant)
  • Start the vagrant box - 'vagrant box' here is lower case, but upper case in 'Create your Kubos SDK Vagrant Box'. Make them the same.
    • 'To start the box after modifying your Vagrantfile run:' -> 'To start the box, run:'

first-project.md (KUBOS-465)

• Capitalize all the section titles except 'your', 'a', and 'and'
• Prerequisites
  • Remove 'create an instance of the kubos vagrant box [...]' since the 'Install the Kubos SDK' link is there and covers that.
  • Remove or greatly shrink the blurb about mounting directories. Again, it's covered by the install doc.
  • 'See the following guide' Make "guide" bold to make it slightly easier to notice that it's a link.
• Creating your project
  • Change 'project files & folder' to 'project files and folders'
  • 'a project cannot be named any of these words' -> 'which cannot be used as the name of the project'
  • 'kubos-rt-example' - Turn into a hyperlink and link to the kubos-rt-example project
  • Example list: capitalize i2c, spi, csp, and uart
  • Create sub-section 'Cloning a Project'

    • "If you would like to use one of our projects, you will need to clone and link the necessary files. For example:
      $ git clone https://github.com/kubostech/kubos-spi-example myproject
      $ cd myproject
      $ kubos link --all

      Note: It is unnecessary to run the kubos init command in this case"

• Add a section for editting code - mostly to document that the default source location is {project}/source/main.c
• Choosing a Target - Add link/reference to the SDK Cheatsheet and how it has the list of currently available targets
• Building and Flashing - 'Connect your hardware to your computer' - How? Maybe add a link to a doc that has the instructions for this?

sdk-cheatsheet.md (KUBOS-463)

• Remove bullet list containing all the sections since the Table of Contents covers them
• Captitalize all headers consistently
• Creating a Project
  • Make 'Note' bold
  • 'a project cannot be named any of these words' -> 'which cannot be used as the name of the project'
  • The generate files list is missing a few. Current list right after project creation looks like this:
    CONTRIBUTING.md LICENSE.txt module.json README.md source yotta_modules yotta_targets
  • Add line about creating KubOS Linux project (-l option)
• Linking Local Modules and Targets
  • 'Kubos comes with' -> 'The Kubos SDK comes with'?
  • Linking modules/Linking targets - Make these actual sub-headers
  • Linking modules - First two bullet points don't need to be bullet points
  • Linking targets - First three bullet points don't need to be bullets
  • Add examples of what a 'module' and 'target' directory are (ex. kubos/hal/kubos-hal and kubos/targets/target-kubos-gcc)
• Debugging your Project - Note that debugging KubOS Linux targets isn't currently supported

sdk-reference.md (KUBOS-435)

• Break intro sentence into two sentences
• kubos build - Capitalize 'kubos' in description bullet points
• kubos update - Options - Un-capitalize 'Is optional'

sdk-upgrading.md (KUBOS-468)

• Add instructions for upgrading SDK box?
• 'New updates will be announced on the Kubos website' - This isn't a thing that we're doing currently. What's the plan?
• Upgrading Kubos CLI - Missing 'vagrant up' step

msp430-launchpad-guide.md (KUBOS-459)

• Reference Documents
  • Add hyphens to 'MSP430 Documentation' bullet points
  • User's Guide and Launchpad User's Guide links are broken
• Pin Definitions - 'Quick Launch Guide' is a little vague (also 'Launchpad User's Guide')
• Flashing the board - Capitalization
  • First sentence: 'Once you've built your project, you'll flash it onto your board using the micro-USB port.'
  • change "'kubos flash'" to "kubos flash"

stm32f4-discovery-board-guide.md (KUBOS-460)

• Pin Definitions
  • 'Within the user manual' - clarify which user manual
  • Move 'within the source code' to the end
  • 'Kubos SDK folder' -> 'project'
  • Changing the pin definitions - mention that the project will need to be rebuilt to pull in the changes
• Flashing the board - Capitalization
  • First sentence: 'Once you've built your project, you'll flash it onto your board using the mini-USB port.'
  • change "'kubos flash'" to "kubos flash"
• Example Program
  • "The Walkthrough" - fix header formatting

kubos-linux-overview.md (KUBOS-462)

• Remove 'final distribution' lines
• Introduction - "KubOS clients'" -> "Kubos clients'"
• Flow diagram is slightly out of date. zImage -> kernel
• KubOS Linux Kernel
  • (zimage, linux, glibc, etc) Add space after #'s to fix formatting for git
  • BusyBox - Update list of commands

kubos-linux-on-iobc.md (KUBOS-462)

• Typo: {#kubos-linux-on-the-iobs}
• Software Components
  • ISIS Bootloader - add blurb about doc that has bootloader loading instructions
• Install the NOR Flash files - Add line about rebooting after loading the new files

user-app-on-iobc.md (KUBOS-462)

• Maybe rename this file. It's essentially a user walkthrough.
• Setting initialization config
  • Make it more clear that the daemon is created by default and there is effort required by the user to turn it off.
  • Add a better blurb about initAfterFlash, since it is a unique option from initAtBoot
• Updating the USB connection
  • Mention that you also need to be connected to the JTAG (won't be used, but is required to get a successful USB connection...)
• Flashing the board - capitalization
  • Mention the JTAG
  • Update the example output, we have an ETA display now
• Troubleshooting - Explain that these are messages that might be output by the kubos flash command.
• Manual File Transfer
  • 'you want to manual transfer' -> 'you want to manually transfer'
  • Add screen grab for zModem 'Goto' function
• Add section about file structure (ie. user files need to go under /home. root is under /root, though)

kubos-linux-upgrade.md (KUBOS-462)

• Convert flow diagram from ASCII to proper flow diagram
• Overview - Add/mention the datestamp component of the file name
• Upgrade Installation
  • Prerequisites - update the SD card doc section name
  • Installation
    • One of the command example lines isn't displaying correctly
    • Add progress bar example
    • Fix 'User Applications' link
• Upgrade Creation - consider putting in own developer doc
  • Run the packaging script - mentions zImage, should actually be kubos-kernel.itb (which also gets created)
  • Custom packages - missing branch option
• Upgrade Rollback - Put before Upgrade Creation, still it's still a user-level topic

command-and-control.md (KUBOS-461)

• Add overview blurb at start of doc. What is Command and Control?
• I prefer smooth flow diagrams to ASCII-created ones
• Where are the actual commands documented?
• I think this doc is outdated now, because we're not using shared libraries any more
• Library Implementation: 'See the core library[...]' Link needs to be updated

• Telemetry API link is broken

Docs to Add:

Software guides

• High level KubOS architecture
• Telemetry
  • Architecture
  • How to use/extend
• Command & Control
  • Architecture
  • How to use/extend
• HAL
  • Examples of using all HAL functions
  • Temporary "How to use iOBC peripherals" doc until the iOBC gets fully integrated into kubos-hal (KUBOS-467)
• KubOS Linux SysAdmin Guide
  • File system overview
  • How to add users
  • How to change root password
• config.json
  • Overview of all the configuration options

Other...

• Porting new board to Kubos-RT
• Porting new board to Kubos-Linux
• Troubleshooting/FAQ

Vagrant Doc Change Requests

These are the questions/comments I have as a brand new Vagrant user setting up my system for the first time.

• CLI - installing
  • Install vagrant
    • vagrant installation link is broken
  • Create your kubos Vagrant Box:
    • missing git clone instruction - also explanation of what's being cloned and why
    • vagrant init example
      • clean up comment
      • what is 'kubostech/kubos-sdk' and why am I using it in the init command?
  • Mounting shared folder
    • make own section
    • need in depth example of mounting a folder and then connecting to host IDE (more hand-holding, please)
    • The "#To mount a specific directory..." lines no longer exist in the default Vagrantfile
    • "For more information on mounting volumes..." - make this bigger or bolded or something eye-catching. Took me a while to notice the hyperlink.
    • The mounting-a-directory process is specifically for mounting a folder from the host machine to the vagrant VM? I wanted to go the other way (created a project on VM, added the synced_folder line for the new project folder) and it wiped out the files that were in my VM folder. Need either a warning or a way around this.
    • missing vagrant reload command after changing vagrantfile
  • Vagrant up
    • missing vagrant up command and explanation
  • Vagrant ssh
    • make own section
  • Organization: Have 'Prerequisites' header, but no other headers at that level following it. Makes it seem like everything is a pre-req
• First Project
  • Creating your project
    • How do I mount a folder and then create a kubos project using it? I created a folder on my host machine and mounted it to a new folder in my VM, but when I run 'kubos init newFolder' I see the error message "Initializing project: newFolder ...The project directory newFolder already exists. Not overwritting the current directory"

@kubostech/devs

Milestone 1 Current Doc Audit

Things that could be changed to make the docs better for milestone 1:

• kubos
  • changelog
    • Update it :P
  • main.md
    • Update all product names to be consistent
      • Kubos SDK
      • Kubos CLI
      • KubOS Linux
      • KubOS RT
    • Update file names to be consistent
      • hypens, not underscores
      • constistent casing
    • Move 'contributing' to by changelog (not a sub-document)
    • Add API link for telemetry
    • should telemetry-aggregator and ipc also be exposed?
    • "Installing CLI" - [ ] misleading. it's also installing vagrant. Should probably still be "Installing SDK"
    • "Upgrading CLI" -> Upgrading SDK or Upgrading SDK components
  • contribution-process
    • Update 'create a jira issue'
      for stories: follow standard 'as a [user]' format
      mention linking to epics
    • Change 'create personal copy'
      we're making branches against master now
    • create a pull request
      verify instructions still accurate
      mention tagging people for review
      mention WIP tag
    • add 'JIRA -> Reviewing' blurb for stories waiting for PR approval
  • cli-installing - [ ] Misnomer. Really, installing sdk
    • Fix 'kubos-sdk'
    • update vagrant box name
    • Typo: "current Directory"
    • "It is strongly recommended" - [ ] need handholding for this
    • Mounting synced folders - [ ] update instructions. No example line currently exists
    • Missing 'vagrant up' line
    • A link to the upgrading doc might be nice
  • cli-upgrading
    • Kubos -> KubOS
    • Fix naming (kubos-cli -> KubOS CLI)
    • Add 'to check which version of cli, use kubos version'
    • Typo: "avaialble"
    • sudo kubos update -> kubos update
    • add blurb about kubos use
    • Add section about downgrading each component (or stick in a different doc)
    • A link to the install doc might be nice
  • first-project
    • fix naming
    • update vagrant box name
    • Repeat of shared folder note: handholding. Alternatively, remove this section, since it's not really related to building your first test project.
      • also, is this still the recommended practice? How do you do kubos init on the host machine? b/c you can't do kubos init on a folder that already exists...
    • Add link for example linux project
  • cli-reference
    • Add links at the top to each section
    • An overview section with all of the kubos commands and the quick description at the top could be nice. basically just copy paste the output of kubos --help, or make a pretty table.
    • Possibly re-org. Most command references are ordered by command, not by function.
      • If not re-org, then the doc should be renamed. SDK Process Overview, or something...
    • go into way more detail on all the things.
    • Make sure all kubos commands and all their options are documented here.
    • "Yotta needs" -> "KubOS CLI needs"
    • "kubos build -- [ ] -v" - [ ] what's the '--' for?
      *** Kubos linking description/instructions could probable use some going over.
    • is there a script for linking everything now?
    • 'TODO' do the thing.
      *** A troubleshooting/FAQ doc could be good.
  • kubos-development.md
    • Fix naming
    • Expand intro blurb with overview of development process. "If you want to make changes to the Kubos code, perhaps for debugging purposes, you'll need to clone the kubos repo and then link the changed modules to your kubos sdk project" - or something to that effect.
    • Getting started - [ ] "Modifying an existing Kubos module" doesn't make sense for the text that follows
    • Since it's recommended to use external shared folders, it might be good to give the process for cloning kubos externally
      and then linking it in the Vagrantfile and running 'vagrant reload''
    • 'Yotta' - [ ] Make hyperlink to yotta docs
    • Linking in a local module - [ ] make example directory an actual directory.
      • "Let's say you want to add debug lines to {module}..." - [ ] Use actual module path.
    • Change /home/kubos/example to /home/kubos/<project_name> to match previous example kubos init
    • Add instructions for how to unlink modules?
  • MSP430-launchpad-guide
    • Fix naming
    • Update kubos doc links to match formatting of other docs. "docs/[doc]"
    • Flashing the board - update the USB passthrough description. Vagrant should be doing it now.
    • "sudo kubos flash" - is the sudo still required?
  • STM32F4-discovery-board-guide
    • Fix naming
    • Fix doc URLs for consistency
    • Fix "sudo kubos flash"?
  • Linux_Overview
    • change file name. underscores->hyphen. Add 'kubos'
    • Linux -> KubOS Linux
    • Update busybox commands list
  • Linux_on_iobc
    • change file name. underscores->hyphen. Add 'kubos'
    • Better highlight that this is a doc specifically for the bootloaders and kernel, not user applications. Should only be needed if the kernel is not pre-loaded onto the board, or if the kernel needs to be manually updated for some reason.
  • User_App_on_iOBC
    • change file name.
    • change "KubOS Documentation" -> "Kubos Documentation", since the SDK is lower case, we're just referring to the company's documentation.
    • Fix zModem file selector example formatting
    • Example - Add command to exit minicom at very end

kubos-co
*** Developer notes for working with/updating vagrant and the cli could be good
*** Standards doc - naming, coding, etc

Telemetry Database Handler Requirements

What does a telemetry DB handler need to do?

• Write telem API
• Define new telemetry items when they are received
• Manage the memory usage
  • Hard maximum limit
  • Rolling cleanup on all items (typically persist values for 2 weeks maximum)
• Create and send Health and Status beacon to the radio periodically
  • Control the frequency of this
  • Most recent values only
  • Control what items are included dynamically
• Receive IP messages
• Monitor and log system events
  • Anytime an event happens on the system, it should be logged. It listens to everything.
• Process log requests
  • Handle incoming GraphQL requests
  • Stream telemetry to the source based on the request
• Telemetry categorization
  • Critical, nominal, debug
  • By subsystem

Event Driven Framework

We are considering building an event driven layer on top of the Kubos flight software framework. An initial prototype implementation was created as part of #168 and demonstrates what an event driven interface could look like in our context. However further discussion is needed to settle on some broader architecture directions and implementation details.

Items that still need discussions and/options weighed are:

• Architecture
  • SOA/Brokered - One dedicated message broker stands in-between all software nodes
  • Brokerless - Every node has the ability to act as a broker, but none are dedicated
• Queues
  • What are the potential queue options?
  • Should we be concerned with queue persistence?
• Messaging Layer
  • What are the potential messaging layer options?
    • ZeroMQ http://zeromq.org/
    • Nanomsg http://nanomsg.org/
    • MQTT http://mqtt.org/
• Testing - What will this look like?

Need for precise datetime handling?

I have a relatively new (but thoroughly validated) precise date time management library in Rust called hifitime. The point of me writing this is because I need it for high fidelity astrodynamic simulations. It includes leap second support (without the need for the naif leap second files of NASA SPICE) and clock drift handling.

I was wondering whether that would be of use for kubos. If so, I can write up the C bindings to this library.

I would be thrilled to be able to contribute to this project, especially since I work in this industry. Let me know, thanks.

0.2.2 Release Checklist

Kubos Repo

• Ensure all PR’s Have been Merged (That are going to ship in the new release).
• Push Kubos Changelog.
• Verify Kubos repo Circle Test Pass (Building all Example projects)
• Generate & Publish Doxygen Docs
• Review Docs and Fix bugs as needed.
• Tag with the new version number and push the tag to Kubos Repo

Kubos-CLI

• Note: CD will soon be implemented so this is a temporary process.
• Ensure all PR’s have merged and integration tests have passed. (Building all example projects.)
• Tag the latest commit with the new version. Push to origin
• Run python setup.py bdist_wheel --universal
• After building run twine upload dist/*

Kubos-Vagrant

Automation Script:

• cd Into the kubos-vagrant/builder/ directory in the kubos-vagrant repo
• To provision, test, upload and release a box boxes run `./main.py --all <box_name> <version_number>
• To provision and release both boxes use the box name “all”

[KUBOS-486] Quickstart Tutorial Video

I created a quickstart video, located in our engineering folder.
This issue has been created to house the video review process. Once this review is complete, the video will be added to the docs...somewhere...

@kubostech/devs

KubOS example projects not linked correctly

Current documentation for example projects here is a broken link.

Each of the links go to "https://github.com/kubostech/kubos/tree/master/(EXAMPLE_DIR)"

They should be linked to "https://github.com/kubostech/kubos/tree/master/examples/(EXAMPLE_DIR)"

Kubos 1.0 [Milestone 2]

Milestone 2

• Kernel Update
• Userland/app Update
• Root FS
• Command & Control Framework
• Build Info Command Kicking out to next release
• Noop
• CSP (stretch) - CSP Commands for C&C
• GDB (stretch) - Turn on GDB for ISIS board

Kubos 1.0 [Milestone vRemoteUpdate]

Milestone 3 (not currently prioritized):

• remote update from U-Boot (outside file transfer. in case of completely corrupt linux) - nice
• create kpack-base.itb (for rollback) - KUBOS-401
• Abstract fw_setenv (C&C) - nice
  • interactive 'select version' menu?
• Rootfs overlay - nice
  • Note: This affects rollback...how do you rollback a single file?
• kpack for NOR flash files - KUBOS-395
• Remote Update Verification
  • kernel (.itb)
    • checking methods (curr crc+sha1) - KUBOS-403
    • [ ] add signature? (U-Boot 'verified boot options') - doubt it
  • User app
    • built in unit tests - nice
• System recovery
  • UBoot: Failed upgrade counter - KUBOS-323
  • UBoot: failed linux boots counter - KUBOS-404
    • UBoot: Ultra-fail boot into ISIS RT - KUBOS-405
    • UBoot: Ultra-fail boot into KubOS RT - nice

---

Milestone 2:

• SDK
  • Upload non-application files (ex. scripts) KUBOS-313
  • Upload kubos update package (kpack) KUBOS-325
  • Add config.json options for controlling user app init scripts
    • TODO: Review KUBOS-340 and settle on workflow
  • MAYBE: kubos debug for linux KUBOS-339
• SDK Flash progress bar (scrape minicom)
• Linux
  • Implement 'reboot-into-system-update-mode' option? (or just let uboot detect new files and act accordingly)
  • Kernel versioning KUBOS-324
  • Separate current rootfs partition into read-only rootfs and read-write persistent (user) data partitions (and set up symlinks(?) for ease-of-use)
• U-Boot
  • Detect presence of new upgrade package KUBOS-322
• [ ] Automation
  • [ ] Kernel update KUBOS-327
• Documentation
  • Kernel update KUBOS-326

---

• Questions
  • Are we including error handling and/or systems recovery in this? Nope
  • Are we including authentication/validation in this? Nope
  • How will the new kernel be loaded?
    • SDK transfer to where on board? New partition
    • How to indicate new file?
  • Do we want user apps from kubos flash to be automatically started after transfer?
  • How should the system be rebooted after receiving a new kernel file? For now, manually
    • SDK (or other external) command to trigger reboot?
    • Automatically? Immediately vs scheduled?
  • How to handle device tree updates? (*.dtb) In theory we should never need to add devices on the fly, but in practice... Same way as the other update package files. Just to NOR instead of SD partition
  • Also, uboot env updates? Should follow the same logic as .dtb, since they both live in NOR flash and are involved in similar areas of the boot process.
  • Package manager? (RPM, dpkg, etc) Not right now

SDK headaches

Main current items:

• Windows environment in the SDK leaves something to be desired. You have to constantly transfer files as part of the regular process.
• Debugging isn't possible for Linux except through console output.

Possible solutions:

• No idea for Windows. The route of working on a remote server seems to work okay for now...but I'm really not sure how to solve it in another way.
• Upgrade to work with Linux through a remote GDB server.

Larger questions:

• Should we be fostering development directly on the board rather than in the SDK?
• Should the vagrant be an emulation of the KubOS Linux environment that you develop in until you're ready for hardware?
• Would this make Hopper an AWS-like environment where you're getting to log in directly to the flight computer?

Incorrect Github link in quick start

When installing and working through the quick start this morning, I ran across an error in the documentation.

The link in first-project.md at line 69 is:

https://github.com/kubos-spi-example

It should be:

https://github.com/kubostech/kubos-spi-example

C Style Guide/Linter

C Style for Kubos

Let's finish the conversation about C style at Kubos here.

TODO:

• Decide on a style guide (Google, AT&T, etc.)
• Document in the repo
• Find a linter & integrate into CI.

/cc @kubostech/devs

Kubos website misspelling

I'm not exactly sure if this is the right place to put it, but on the Hopper page, the name for the Beaglebone Black is misspelled to Beagelbone Black, it is under the "Hopper Hardware" section.

Post-1.0 Wishlist

Things that we definitely aren't putting in v1.0, but we'd like to implement in the future:

• Make the docs pretty (more user friendly)
• Automate...things...