With a little effort, I think the frame options could be auto-generated much in the same way that the parameter lists are built during wiki generation for a bit of future-proofing (potentially by JSON-ifying relevant portions of motors-matrix.cpp).
The below screenshot looks nearly identical to the existing page’s QUAD/X image, but I had a go at using HTML5’s SVG tags to procedurally generate the shapes and text, which could somewhat easily be scripted.
I’m not sure if Sphinx/reStructuredText supports SVG tags, so canvas objects might also be a possibility.
Open to ideas for proper/well executed integration into the wiki. I’m versed enough in JS and HTML to make something work, but I’m a complete novice with Sphinx/reStructuredText and what happens behind the scenes during wiki generation.
Here’s a little proof of concept that I’m not sure would actually dovetail into the wiki very well, but it does dynamically produce a few quad frame types correctly based on a bit of manual JSON-ifying of the motors matrix source. Rename to .html and open in a local browser.
Plenty of room for improvement, particularly in the repeated copy/paste portions in the JS, but it gets the idea across, anyway. We’d want to scale the diagram properly (and likely dynamically to cleanly fit hex/octo frames). It’s pretty easy to skew SVG elements and adjust opacity to get a 3D feel for things like OctoX.
Exactly. I think a Python script in the wiki backend could scrape AP_MotorsMatrix.cpp during the build and dynamically update the page with new frame types (which is I think what Pete’s suggesting he already has, in some fashion).
There is a good reason for that. Any configuration runs the same motor order with respect to the letter designations. This was done purposefully. Yes, many have complained but those that do may not get the logic behind it.