I'm building a real-time telemetry platform for makers. The project lowers the barrier of entry for data collection on hardware projects: You can very quickly wire up a hardware system to a server/UI and collect, analyze, and act on data from multiple data sources. This lets the maker focus on building better, more intelligent systems.
Out of the box with minimal configuration, my telemetry platform has:
- Support for many common telemetry protocols, for example: (NMEA 0183, Mavlink, CAN-bus, VE.Direct, Key-Length-value strings)
- Realtime data streaming, play/pause/replay, time scrubbing
- Dashboard editor and component library (charts, gauges, text displays, instrument panels, etc)
- Data syncing in realtime between servers and the cloud; dashboards can be shared and viewed anywhere
My background in this is from my work at the University of Rochester leading a manned electric boat racing team. A need we saw across teams at our competitions was the ability to integrate realtime data from many embedded devices into a single data stream, plot data live on dashboards during races, store data for later analysis, and easily share that data among team members. Building out the infrastructure to do this gave our team a great advantage as we were able to back up high-level decisions with quantitative data we received from our system.
For example, where other teams would guess based on sparse data the ideal propeller pitch for a desired event, we had exact data on the RPM/torque from our drivetrain and current draw on the motor, and were able to quantitatively compare our propeller selection in different events to optimize for speed, efficiency, etc.
The professional ecosystem in this area is huge:
- ROS is the dominant telemetry platform across hardware systems
- The Mavlink protocol is used for drone communication
- CAN-bus and other hardware standards are used in the vehicle industry
- Matlab is commonly used for data collection & analysis among researchers
Across all these systems there is a common problem for beginners: There is a huge amount of domain knowledge and setup required before you can effectively build complex systems. Across almost every amateur project that does hardware data collection, people are repeating the same steps: Set up a custom protocol for streaming from an MCU over serial, write a program to receive/store that data, use an external tool to load, process and chart the data, etc.
On some level, that experience is really valuable, and I'm building the platform not to force you into a certain method: Using one piece of the system does not require buying into every feature. For example, you could just use the server for data collection, and read data points directly from the server into your own UI. conversely, you could use the server/UI to point at a ROS instance and just use the UI as a UI layer for dashboards.
Overall, I'm really excited because I think that building a ready-to-use server and a powerful UI into a single package represents a real step forwards. There's a real need for this type of system that I've seen time and time again in the field from makers, researchers, and anyone else building hardware systems.
Out of the box with minimal configuration, my telemetry platform has:
- Support for many common telemetry protocols, for example: (NMEA 0183, Mavlink, CAN-bus, VE.Direct, Key-Length-value strings)
- Realtime data streaming, play/pause/replay, time scrubbing
- Dashboard editor and component library (charts, gauges, text displays, instrument panels, etc)
- Data syncing in realtime between servers and the cloud; dashboards can be shared and viewed anywhere
My background in this is from my work at the University of Rochester leading a manned electric boat racing team. A need we saw across teams at our competitions was the ability to integrate realtime data from many embedded devices into a single data stream, plot data live on dashboards during races, store data for later analysis, and easily share that data among team members. Building out the infrastructure to do this gave our team a great advantage as we were able to back up high-level decisions with quantitative data we received from our system.
For example, where other teams would guess based on sparse data the ideal propeller pitch for a desired event, we had exact data on the RPM/torque from our drivetrain and current draw on the motor, and were able to quantitatively compare our propeller selection in different events to optimize for speed, efficiency, etc.
The professional ecosystem in this area is huge:
- ROS is the dominant telemetry platform across hardware systems
- The Mavlink protocol is used for drone communication
- CAN-bus and other hardware standards are used in the vehicle industry
- Matlab is commonly used for data collection & analysis among researchers
Across all these systems there is a common problem for beginners: There is a huge amount of domain knowledge and setup required before you can effectively build complex systems. Across almost every amateur project that does hardware data collection, people are repeating the same steps: Set up a custom protocol for streaming from an MCU over serial, write a program to receive/store that data, use an external tool to load, process and chart the data, etc.
On some level, that experience is really valuable, and I'm building the platform not to force you into a certain method: Using one piece of the system does not require buying into every feature. For example, you could just use the server for data collection, and read data points directly from the server into your own UI. conversely, you could use the server/UI to point at a ROS instance and just use the UI as a UI layer for dashboards.
Overall, I'm really excited because I think that building a ready-to-use server and a powerful UI into a single package represents a real step forwards. There's a real need for this type of system that I've seen time and time again in the field from makers, researchers, and anyone else building hardware systems.