mithi / hexapod-robot-simulator

A hexapod robot simulator built from first principles
MIT License
774 stars 109 forks source link

Optimize methods in ground_constant_solver, formatting. #72

Closed philippeitis closed 4 years ago

philippeitis commented 4 years ago

This includes using math methods vs numpy methods, and also optimizes some specific functionality:

three_ids_of_ground_contacts: For each trio, we run get_corresponding_ground_contacts twice (since the same trio will appear in trios / other_trios). In addition, we get the corresponding ground constant for each leg 20 seperate times (each leg appears in 10 combos, and each combo is repeated twice). This can be optimized by fetching the ground constants once, and fetching values from a list of stored values.

set_of_two_trios_from_six: This function would generate the forward / reverse copies of the same list (trios == other_trios[::-1] is true (if the elements in other_trios are set to tuples)) - generating this list can be skipped entirely by just reversing the list, which speeds this function up by 20x, speeds up three_ids_of_ground_contacts by ~2x, and get_legs_on_ground by ~1.5x:

10000 iterations of these functions with random legs:

Old three_ids_of_ground_contacts: 0.6891s
New three_ids_of_ground_contacts: 0.3820s
Old get_legs_on_ground: 0.7777s
New get_legs_on_ground: 0.4897s

This also moves comments into docstrings for some functions, but it seems that the PR Quality Review does not like me putting the first line of the docstring on the first or second line (if I do one, it suggests the other) - if you can ignore the lints for either D212 or D213 (eg. this stackover link), that should fix the failing check.

I also noticed that in three_ids_of_ground_contacts, we manually define tol in the loop - this seems like it's better suited as a function argument (since we may want to tweak this).