EV3 - Exposing more graphics commands

[majohadev]

Over the past couple weeks I've been writing a simple 3D renderer for the EV3, using Pybricks. Drawing a wireframe model works fine (just have to call draw_line between connected points), but even with some optimization techniques, the program slows down significantly when showing more than a few objects on screen. I'd like to expand this beyond wireframes (e.g. e.g. solid faces and interactivity), but that will require the draw calls to be as fast as possible. (At the same time, it's much easier for me to prototype features in Python - so I don't want to write the whole thing in C/C++.)

To speed up drawing, I want to expose additional functions from the GRX3 library (such as drawing filled and unfilled polygons) on my own fork of pybricks-micropython - but I'm having trouble getting started.

So far I have:

1. Booted into ev3dev from a microSD card (flashed with the image from LEGO Education)
2. Forked pybricks/pybricks-micropython and cloned that to my Windows PC
3. Duplicated one of the shape functions in the Image class for ev3dev(pb_type_ev3dev_image.c), renamed it to ev3dev_Image_draw_tri, modified it to take x/y coords of 3 points and draw a triangle with them, and added a corresponding line to the dictionary at the bottom of the file
4. Added tests for draw_tri to the ev3dev tests folder
5. Followed the Contributing guide steps for building firmware on Windows (had to add double-quotes in some scripts to allow for spaces in file paths), and verified that pb_type_ev3dev_image.c was processed by make
6. After a successful build, copied pybricks-micropython to the EV3 with scp bricks/ev3dev/pybricks-micropython robot@ev3dev:~

After that, I tried to call draw_tri both in my renderer Python program (ran from VS Code, via LEGO Education's EV3 MicroPython plugin) and in the command line after running ssh -t robot@ev3dev "brickrun -r -- pybricks-micropython" - but the function wasn't recognized in either case.

In digging through the repo, the Image class linked above is the only file I could find that specified which drawing commands were available - so I thought that might be the only thing I had to change. Is there something else I overlooked? (This is my first time modifying/building firmware, so it's likely that I'm missing some details!)

[dlech]

5\. had to add double-quotes in some scripts to allow for spaces in file paths

We will gladly take a PR for this.

ssh -t robot@ev3dev "brickrun -r -- pybricks-micropython" - but the function wasn't recognized in either case.

You will need to use ./pybricks-micropython (or the absolute path), otherwise it uses the PATH environment variable to find pybricks-micropython and this does not include the current directory. (You could also install your copy at /usr/local/bin/ instead so that you don't have to do that.)

[laurensvalk]

After that, I tried to call draw_tri both in my renderer Python program (ran from VS Code, via LEGO Education's EV3 MicroPython plugin)

Alternatively, you can copy the newly built pybricks-micropython to your (local) project, so it just gets downloaded along with your project when you run it.

Then all you'd need to do is change the shebang path on the first line in your script accordingly, to e.g.
#!/home/robot/my_test_project/pybricks-micropython

I don't remember if it was necessary to make it executable first.

[laurensvalk]

Although personally I did it a bit differently during development. I usually ran this once on the EV3 brick:

rm -f pybricks-micropython && touch pybricks-micropython; chmod +x pybricks-micropython && sudo rm -f /usr/bin/pybricks-micropython && sudo ln -s /home/robot/pybricks-micropython /usr/bin/pybricks-micropython

Then I would just scp (or gvfs) new builds to /home/robot and everything would automatically keep using this latest version. This seems quite similar to your workflow.

Projects run via VS Code would automatically use this new version as well, which can be convenient.

[majohadev]

Thank you both for the quick responses - my triangle function is recognized now and runs great!

I was able to get it working by moving pybricks-micropython to /usr/local/bin/ as @dlech suggested - though I did have to make it an executable too (chmod +x /usr/local/bin/pybricks-micropython), or I'd get a permission error. (I should also note that with this method, the shebang path on each script can still be #!/usr/bin/env pybricks-micropython.)

The method @laurensvalk suggested (replacing the original firmware at /usr/bin/pybricks-micropython with a soft link to /home/robot/pybricks-micropython, if I understood correctly) also sounds interesting, so I may try that if I find myself swapping out the firmware frequently.

Again, I really appreciate the help! Having more of GRX3 exposed will be a huge step up for my project.

[dlech]

scp has a -p option to preserve the file permissions when copying so you don't have to chmod later. (I haven't tried it from Cygwin but I assume that it works).