Big thanks to David Holshouser for geeking out with us about COSMOS, and sharing Ball’s history with the project!
As the Internet of Things brings in more folks from the coding world to the embedded world, the language and interface options for programming your embedded devices continues to grow. Ruby isn’t typically a language that comes to mind first for embedded device interfaces, but that doesn’t mean it is any less capable.
Enter COSMOS. This is an interface system designed to allow for testing, debugging, and real-time control of embedded systems, as well as data collection and visualization, and uses Ruby as the main framework. The fine folks at Ball Aerospace developed this program several years ago and have been using it for their own projects. Some of the projects that have been worked on using COSMOS include the following:
Other projects outside of Ball have also used the COSMOS system for development, including NASA’s IceCube CubeSat. The TrapSat project also has used this in the development and testing of their trash-collecting CubeSat, and Blue Canyon Technologies uses this as a test system for their Spacecraft Buses.
The list goes on, but you get the point. This tool is being used in a lot of BIG applications. It turns out though, it’s also a great interface for embedded electronics like everyone’s favorite Arduino. I don’t know about you, but my excitement level for tools definitely increases if I know that rocket scientists are also using them (Space Pen, anyone?).
There isn’t much documentation available currently for interfacing this with DIY widgets and electronics, but that is also hopefully beginning to change. Ball open-sourced the entire platform last year, and the source code is available on GitHub, giving you the opportunity to fork it for your own purposes, or collaborate with the team fixing issues. A small group of folks down the road at the local Boulder Ball office are also starting to play with this with electronics from their local “hackerspace library.” With the library of tools and equipment that can be checked out and used for personal projects, there are some really fabulous projects coming to life.
Jim Velasquez is working on his own personal CubeSat, and has been using COSMOS for programming and testing his design. His CubeSat is running with a Raspberry Pi.
Image courtesy of: Jim Velasquez
Sam Povilus is also using COSMOS for testing and configuring his ball-balancing robot. He can also view the data output graphically in real-time from the accelerometer and gyroscope for additional debugging.
Image courtesy of: Sam Povilus
If you’d like to play around with the code Sam is using, it’s available on GitHub.
Another project is the Lego LED/Photodiode system built by Kevin Farley (with Lego assembly help courtesy of his kid).
Image courtesy of Kevin Farley
This project encodes messages as a series of LED blinks that are registered by the photodiode. COSMOS makes it very easy to track the messages being sent, and debug the system if something goes wrong.
COSMOS sending commands and receiving photodiode data from an Arduino. Image courtesy of Kevin Farley
The Platform Itself
So enough of the flashy projects that have been built on this platform. What about the actual meat and potatoes of it?
First of many features is that this system is cross-platform compatible. There are batch installers for Windows, Linux, and Mac, and it really does install very quickly and easily (at least in my tests on Linux and Windows). I went into each install with baited breath because the words “open-source software” and “easy install without bugs” don’t generally go together in my experience, but in this case, they did.
Additionally, the code syntax in general was very easy to pick up. Not being familiar with Ruby myself, I was expecting to be spending a lot of time digging into the manuals to figure out the formatting and syntax, but overall, it came relatively easily. While I didn’t have a chance to dig in and explore this feature more, one upside to COSMOS being written in Ruby means that if you need custom drivers for a particular piece of hardware that isn’t already supported, you can write those up and simply use them as plugins (though there is already support for serial, TCP/IP, and UDP out of the box).
When you first launch the program, you’re provided with a lot of options that can look a bit overwhelming, especially if you are coming at this fresh from Arduino land.
COSMOS Application Launcher Window
Luckily, there’s a pretty great overview of the whole program here, with basic explanations of what each application does, making it easy to dive in and start playing around with the program. There’s also a YouTube video demo of each application, for those of you who prefer watching to reading.
David Holshouser has also written a wonderful beginner guide for the classic “Blink” application. You can work through his example here, which also leads into some cool window configuration options for COSMOS.
Following his guide, I was able to get basic control of an LED on my Redboard relatively quickly, blinking it along at variable rates that I could control through the Command Sender and Telemetry viewer window. One problem that I did run into that made for a frustrating day of digging deep into the code backend was the fact that attempting to set this up on an old Redboard (Version 1.0) with an FT232 IC on it led to a lot of errors being thrown by COSMOS each time I attempted to run the the program. In the end, the Reboard wasn’t registering on the COM port (despite programming just fine in Arduino), but I kept receiving syntax errors on things like “NONE” being an invalid parity type. Thank goodness for open-source code allowing me to RTFM to confirm I hadn’t been doing that wrong all these years.
After a simple swap to a newer board, the compiler errors disappeared and I was able to get into the fun part of hacking the cmd.txt, tlm.txt, and cmd_tlm_server.txt files, which are the command, telemetry, and command telemetry server configurations, respectively. I wanted to see how easy it would be to start taking analog data in and logging it (as the logging capabilities of COSMOS are also pretty phenomenal).
If you’d like to see my updated code for this, my files are available here.
In keeping with the Blink/Hello World vein, I wanted to translate the default Arduino example sketch ReadAnalogVoltage.ino. I started by configuring COSMOS.
To graph all the analog readings coming in, I set the following in tlm.txt:
APPEND_ITEM analogReading 8 UINT "Current analog reading"
which tells COSMOS to set up a basic telemetry slot for the analog reading the Arduino will be sending back. To test sending the commands to the Arduino, I also wanted to be able to change the pin declaration in COSMOS, and have Arduino return data readings from the pin of my whim at that moment.
APPEND_PARAMETER readAnalogPin 8 UINT 0 19 15 "Analog pin to read"
sets COSMOS up to allow me to send a new command of an analog pin definition. (I used the standard pin names for the ATMega328 instead of the Arduino definitions, so A0-A6 are identified by 14-19 in COSMOS.) As with the analog reading telemetry setting, adding the following to tlm.txt:
APPEND_ITEM readAnalogPin 8 UINT "Current analog pin"
which then allows me to track which pin the Arduino is currently reading.
My Arduino sketch ReadAnalog.ino also had to be updated to ensure the Arduino can receive all the commands coming from COSMOS, and send back the proper information for logging.
//Create structure for the COSMOS commands/telemetry
byte msgSize; //Packet length for COSMOS (COSMOS item 'length')
byte id; //Command Identifier for COSMOS (COSMOS item id)
byte pinID; //ATMega328 pin to read (COSMOS item 'readAnalogPin')
byte reading; //Analog reading (COSMOS item 'analogReading')
byte cmdsReceived; //Number of commands received from COSMOS (COSMOS item 'cmdsSent')
byte cmdsAccepted; //Number of commands actually used from COSMOS (COSMOS item 'cmdsAccepted')
Appending each item to the data structure was an easy translation from the COSMOS configuration files.
Running the Command and Telemetry application, I can see my data is set up and the Arduino is communicating with COSMOS.
Packet Telemetry viewer showing there are packets moving between the Redboard and COSMOS.
Pulling up the graphs, you can view not only the analog data coming in, but also the number of commands sent to the Redboard, and the number the Redboard has accepted. If all is peachy, those should match.
You can see the analog readings vary as I fiddle with the pins being read.
In the previous screenshot, COSMOS isn’t showing any commands being sent or accepted, which makes sense. I haven’t told the Redboard to start reading a different pin than the one declared in the setup loop in the .ino sketch.
Once a few pin swaps have been sent, you can see the data changing real time to reflect the new pins being read, as well as the number of commands being sent and received starting to tick up.
Analog readings fluctuate widely as the pin being read changes.
Pretty easy and straight forward! While I didn’t have nearly enough time for this blog post to dig into the program as far as I wanted, it’s an interesting tool to have available for graphing options. I personally thing it would be a great option to use with things like the CAN-Bus Shield or the OBD-II UART Board, where data logging and real-time graphs could be of great use.
One other thing to note if you decide to play around with COSMOS – it does log a lot of data as you go. These files can quickly reach and exceed the file size limits for things like GitHub, so consider setting up a .gitignore file early if you don’t care about saving the log data and intend to share your work online.
If you’ve had a chance to spin up your own project using COSMOS, let us know below. Or if you have feedback on COSMOS itself, head over to GitHub and ping the Ball Aerospace team!
comments | comment feed