Pycharm/Intellij Extension for Pybricks

[shaggysa]

This is a tool I made primarily for a team I help coach, but I figured others might find it useful.

Features

• Intuitive menu to scan for and select bluetooth hubs
• Selector to change the script being downloaded onto the hub
• Automatic handling of relative imports
• Graceful handling of compilation errors
• Buttons to download the selected program, download and run the selected program, run the program stored on the hub, and cancel the currently running program.
• Progress bar the view the status of a program download
• Terminal to view the hub's stdout

Demo

demo.mp4

Download

https://github.com/shaggysa/pybricks-runner/releases

Related projects

Pybricks-runner utilizes brickpipe, which provides an asynchronous JSON api for interacting with pybricksdev. I would highly recommend checking it out if you want to create your own pybricks GUI.

[farfromexact]

This is a useful workflow for teams coaching with Pybricks. The main thing I would document alongside the demo is the compatibility boundary: Pybricks hub firmware, pybricksdev or brickpipe versions, supported IDE versions, and which hub models expose the same Bluetooth behavior.

The runner should also make the lifecycle explicit:

• a scan can be cancelled without leaving a stale connection
• only one download or run owns a hub at a time
• a failed compile does not replace the last working program
• the progress bar distinguishes transfer, execution, and waiting for stdout
• the user can see whether the program on the hub is the selected local file or an older stored program

For distribution, a signed release or clear installation instructions would make it easier for coaches to deploy without cloning source. A small compatibility table and a recorded failure log for connection, compile, download, run, and cancel would complement the excellent demo and make support questions much easier to answer.

[shaggysa]

Thanks for the feedback!

On your compatibility advice, documenting IDE and hub firmware compatibility does seem very useful; I will look into it. The end user doesn't need to care about the brickpipe or pybricksdev versions because they are pinned.

I'm not quite sure how useful documenting the lifecycle to the extent that you suggest would be as most of it is expected behavior or can be verified by looking at the UI for a few seconds.
For example, why would somebody think that cancelling a scan would leave a stale connection when nothing was ever connected in the first place? How would a failed compile replace the stored program if there isn't anything to send?

I like the idea of telling the user exactly what is stored on the hub, but I don't think pybricksdev (or the pybricks firmware) makes that visible to me since the program isn't really in file form by the time it makes it to the hub. I could theoretically track the file over the runner's lifetime, but I don't really see a useful application for that.

I definitely want to look into a signed release that I can put on the plugin marketplace, but anyone can download the plugin directly from a github artifact without needing to build from source.

I'm not sure how useful a failure log would be because all failures should be directly visible to the user. The only way any command should be able to fail is if the hub becomes disconnected while it is being sent. Even then, the GUI automatically changes to the "disconnected" state when this happens (except in the case of downloading a program, which I plan to fix imminently).