The Flight Companion Computer, FCPC, which at this stage is basically a Raspberry pi CM4 with a HAT, was intended as system for both handling user interfacing & experience, and handling systems data, for an Arrow single seat ultralight.
It’s current functions are:
Read and record Battery, Motor, Flight Controller and Joystick data.
Create data log files.
Host displays with a pilot user interface.
Send telemetry data over a wireless network.
Currently, especially hardware wise, the system is a bit of a hodgepodge with functionality spread across multiple circuit boards and several undue operational limitation such as range. As such to be both more robust and cost effective production wise several improvements could be made:
A PT4 and Onwards FCPC
However, the long slog of actually making the damn thing to do its job and play nice with the Electronic Speed Controllers (ESCs), Battery Managment Systems (BMSs), as well as interacting with the Embention Team on integrating their Flight Controller system, …and in general… , as well as the difficulties even they faced with ESC interactions, flagged up the difficulty of multi system, multi protocal interfacing.
Each one basically has it own logic to grok which requires its own unique expertise. Time, effort annoyance, and This was only dealing with 4 or 5 systems !
Imagine having to deal with potentially dozens of unique elements all speaking a different language.
This led to thoughs of “What if there was a way to bridge this process ?” “What else could such a system be used for ?” “How much value could it add ?”
There are multiple paths to this but cue:
RoboDaqc: General Purpose Data Acquisition & Control (an FCPC Fork) WIP