Inverse kinematics for controlling arm from joystick-serial

[starphys]

• Basic prototype - renders in MC, can choose points in xyz, calculates angles for arm servos
• Controlling arm - write calculated angles to server, avoid impossible states
• UI - point selection feels natural
• Feedback - update angles from rover
• 3D Model (stretch goal) - arm displays on top of rover in MC, accurately enough to avoid collisions with legs

[starphys]

@Viha123 I've got some of this working (barely) in the inverse-kinematics branch. The next things we need to figure out are how to properly construct our chain, how to put the correct constraints on it, and how to convert the output from result to our format for arm angles.

[starphys]

The control system (in Target.jsx) needs to be updated to only accept input within the correct component, and to scale the x/y coordinates proportionally to that component instead of to the whole window. Right now clicking on the center of the screen is the only way to send input at the center of the model, even when it is not actually centered on the screen. This is a nice React task that doesn't strictly require other libraries, so a good way to improve React fundamentals.
We also need to decide on a way to control z input, which might be click in the window (just like x and y) or might be connected to the scroll wheel or a UI element. There are disadvantages to each approach, so we should try a few and see what feels most natural.
Additionally, it would be great to have an in-world cursor for the targeting system, that is a different color from the target once its placed. This will let us see where we're sending the hand to before we actually start sending angles for it.
Finally, we need to disconnect the click-to-set-target from the click-to-rotate-camera controls. We might be able to bind one or the other to ctrl+click instead, or take any other approach that allows us to control them independently.

[Coreyboy1820]

@starphys Could you break these tasks into separate issues when you find the time? I want people to know all the different things going on. Thanks!

[starphys]

Current state of IK: We have a 3D representation of the arm (not to scale) rendering in a pane on mission control. Clicking in the pane sets a point in the xy plane, and the solver moves the end effector to that point. It obeys the angle constraints we set on each joint, which loosely correspond to the real constraints of our physical arm. We have functions that can parse the solutions for each joint to angles that are appropriate to send to the arm motors.

There are a few issues, the most noticeable one being that the solver struggles to rotate the rotunda when it would have to move exactly 180 degrees. This will be easy enough to work around when we have a better system for inputting Z values.
Next steps include finishing up the UI tasks listed on GitHub, scaling up our chain to exactly match the arm, and testing on the arm. I expect testing will reveal more work to do on the computation side, and there is probably a lot of work do to on the GUI that we haven't identified yet.