Copter Wiki Motor Diagram Overhaul?

ArduCopter
,
1

A recent discussion made me wonder if updating the wiki’s motor connection page might be worthwhile.

Rather than displaying a wall of images, we could simply provide a couple of dropdowns for selecting the frame class and type of choice and then procedurally generate the associated diagram with a bit of Javascript/CSS/HTML magic. Such a diagram could include not only the motor numbers and prop directions, but also the expected letter assignment for Mission Planner’s motor test.

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.

image
image595×718 42.4 KB

Anyone think this is a worthwhile venture to help alleviate confusion?

4 Likes
2

Good idea! It would avoid so many questions and flips on take-off

3

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.

4

This looks nice - would be even better if we could get something like this in Mission Planner as well.

Click on each rotor for motor test and validate that the correct motor spins based on which one you clicked on the diagram. Should hopefully mitigate most the “flip on takeoff” posts we see here.

1 Like
5

Example of a custom QGC build that has this.

6

Incorporating this into MP has been suggested before, as well.

7

Great - now we just need someone with the skills :laughing:

8

Happy to help if I can, I have a AP branch that generates a json description of the motor configurations, that can be used as a base to generate the images.

My suggestion for the wiki would be to inline some raw HTML and javascript. Like this other PR of mine that I have neglected…

9

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.

motors.html.txt (10.1 KB)

10

Looks nice!

I am not familiar with HTML - but it looks like you are dynamically creating those figures based off of frame class/type (not pulling from a bank of pre-existing figures)?

11

Correct. I spent more time than I care to admit overlaying SVG elements onto one of the existing images to make it look nearly identical. I figured there was value in keeping the “theme” familiar.

With this approach, you can create a JSON object that contains all of the motor layouts, probably using Pete’s aforementioned branch.

12

This would be really helpful, back when I got started there was no easy way to figure out what motor ABCDEF was on my hex and I had to experimentally determine it.

Even now you have to do a lot of reading to figure it out. To be honest I’m not sure why they should be referred to that way in mission planner at all.

13

Would it be worth using the same file format as the motor mixer uses?

Quad-X
image

14

The JSON is actually derived from ardupilot/AP_MotorsMatrix.cpp:

    case MOTOR_FRAME_TYPE_X: {
        _frame_type_string = "X";
        static const AP_MotorsMatrix::MotorDef motors[] {
            {   45, AP_MOTORS_MATRIX_YAW_FACTOR_CCW,  1 },
            { -135, AP_MOTORS_MATRIX_YAW_FACTOR_CCW,  3 },
            {  -45, AP_MOTORS_MATRIX_YAW_FACTOR_CW,   4 },
            {  135, AP_MOTORS_MATRIX_YAW_FACTOR_CW,   2 },
        };
        add_motors(motors, ARRAY_SIZE(motors));
        break;
    }
15

Ah - very nice. Good to see we aren’t just creating additional files that need to be manually updated specifically for this use case.

16

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).

17

Just noticed that 1, 2, 3, 4 in the JSON are actually ABCD for motor testing - and the order within the list is the actual number itself. :laughing:

18

That’s just a manual edit I made because it’s easy enough to translate either during JSON creation or during the element text insertion. Doesn’t much matter either way.

But yes, the array index (plus one) is the motor output number, and the explicitly defined number is the letter order as shown in MP and on the diagrams.

19

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.

1 Like
20

Great Work!

This is that json (renamed to txt for upload):
motor_layout.txt (42.5 KB)

Currently it gives the “class” and “type” those match up with what the config prams. Then you get a array of motors each with number, testing order, rotation direction and roll/pitch factor.

I could easily add a string name too.

Its auto generated from the cpp code, only works for the “matrix” type layouts, but we could manually add the few others, tricopter ect.