In March, LaunchDFW spoke with Marshall Culpepper, CEO and co-founder of Kubos Corp, the first open-source satellite software company after it has raised $375k to develop open-source software for the space and satellite industry. This month, Kubos has announced the first public release of KubOS, the open-source software platform discussed just two months ago.
The KubOS software platform includes FreeRTOS, a real-time operating system that is base targeted at constrained subsystems. A CubSat Space Protocol that is an inter-subsystem and ground station link software protocol built for satellites. Kubos HAL, a low-level hardware abstraction layer that provides APIs for GPIO, and UART with more to come in the future. There is Kubos Core, the OS agnostic flight middle-ware that includes buffer management, NMEA parsing, and AX.25/APRS protocol support. And finally, an SDK that includes command line tools to create, build, and flash your projects directly to your satellite board.
Kubos has made Getting started easy and currently the hardware is supported on three different boards, STM32F4 Discovery, TI MSP430F5529 Launchp, and then the experimental NanoAvianics SatBus 3C. Kubos offers easy to follow directions to install KubOS-SDK while also offering those wishing to utilize the open-source software information on what is necessary in order to successfully connect to and utilize it.
Through Kubos, Culpepper is hoping to make space more accessible by bringing in more developers to the aerospace industry. Offering developers a platform that they are familiar with makes the switch to aerospace from tech far and more successful for everyone involved. Kubos is leading the field when it comes to software for aerospace by creating a platform that is usable across the entire field, something that currently does not exist.
The team behind Kubos is successfully solving one of the biggest problems with flight software. All too often software is seen as something that is easy, and is put off until just weeks before a launch, not giving enough time to their developers to create something that is better. This, added with the integration problems created with protocols and communication layers that are different from vendor to vendor, makes the need for Kubos even greater.