Introducing Pictorus Beta!

Engineers have been writing software to control hardware for decades, and it's always been a giant pain. They say "Hardware is Hard", but often it's the integration with software that makes developing new devices so challenging.

It's because devices are finicky. They don't behave in real life like they do in simulation. They can be sensitive to temperature and electrical interference. Sometimes they reboot for absolutely no (obvious) reason. And sometimes they communicate over bizarre protocols, because some overworked embedded engineer, somewhere, needed to hit a deadline.

Very few engineers enjoy this part of the hardware development process. We'd rather be focused on the interesting aspects of our tech, the parts where we're bringing real value. Making sure the sensors and actuators do what we tell them to is just part of the job.

But it's also one of the most critical parts of the job, unfortunately. Even Mars orbiters have famously been lost to simple, well... oversights in software.

Not only is hardware finicky, but software (particularly C and C++), is just downright dangerous. It will do any idiot thing you tell it to. Computers don't make mistakes; human engineers mistakenly give bad instructions.

And since airplanes can stall, airbags can deploy accidentally, and pacemakers must always keep pace, the concept of "mission-critical software" development arose, trying for decades to get to the bottom of this question: How can we know if our software is ready for the real world?

Along the way, a myriad of tools sprung to life to help answer this question. Code linters, for example, help large teams of engineers automatically verify that all new code adheres to a set of rules that promote good software.

Another idea was this: What if we pre-validated certain blocks of code as "safe and efficient for use", and literally forbid everything else? Then, by simply chaining together these code blocks to define software algorithms, our code would be, by definition, highly safe and performant.

Nobody would have to re-invent these low-level building blocks over and over again - or debug them. And as we composed larger, reusable components from these building blocks, they too would inherit the fundamental safety and performance qualities of their constituent parts.

From this idea, block diagram-based code generators were born. Since the code was pre-generated, and the rules for chaining blocks together were so well defined, it naturally made sense to represent and edit them visually. Visual editors had the added benefit of allowing highly technical teammates to meaningfully contribute to a software project without requiring a ton of dedicated software engineers, and without jeopardizing code quality.

Perhaps the most famous example of this paradigm is Simulink by Mathworks, the industry titan responsible for more auto-generated code in more aerospace and automotive applications than you probably realize. If you've flown in an airplane in the last three decades, you've put your life in the hands of auto-generated Simulink C-code.

There's a lot that the existing tools do well, but as anyone who's used them professionally (or was forced to in an undergraduate lab) will tell you, there's a lot of room for improvement.

That's where we come in.

We've designed Pictorus from the ground up with the modern engineer in mind. Over-the-air software compilation and deployment to paired devices is fast and painless. Telemetry is automatically built in, and streams back to the browser in real time. Online collaboration from any laptop means no more machine-specific installations or license keys. And for our fellow software nerds, we're excited to replace the old C-code generators with our new, efficient and reliable Rust code generator developed over the last two years.

We also want to make this technology more accessible than some of the legacy tools, and approachable for anyone passionate about electronics – professionally, personally, or at university. Our block library will eventually be open sourced, allowing users to fork and modify to their needs. And we'll always support a free tier, enabling students, hobbyists, and small startups to get building without commitment. Our paying customers will be those with enterprise-level needs around collaboration, data, and device management.

We've launched our free Beta product this year to get Pictorus out into these people's hands. Anyone can join, so if you love programming devices – on Jetsons, Raspberry Pis, Beaglebones, etc, you should give us a try! We’re continuing to build support for new devices and hardware, eventually targetting embedded development as well.

There's not a lot of limitations during Beta. We're allowing users to pair up to 5 devices to our cloud for free, and telemetry streams are capped around ~1 MB/s to keep costs reasonable.

Any teams looking to do more with Pictorus should reach out, we'd love to partner with you. Our HQ is located in sunny Oakland California, and we love a good hackathon. Especially if we can go outside and fly, sail, or drive a robot around with Pictorus!

Happy hacking!

The team at Pictorus