New ZigZagDiagonal State

[schristian]

Add a new ZigZagDiagonal state in states.py, which is similar to the original ZigZag, but moves diagonally instead.

[alan2234637]

I'll work on this.

[jsternberg]

To give some past context to ZigZag, it's original purpose was never to go at a diagonal to begin with. It's current behavior is expected.

The primary reason behind this was to change the angle of the camera while still approaching the object. It may not have been done in a perfect way and it may not be the best way, but don't remove the old code. I would work on extending it to have the angle be optional. This way it's easy to test if the current method is better or a zigzag taking the diagonals is a better solution (or something in between might be the best).

[schristian]

Right, I understand. I wrote a lot of AI routines using ZigZag as a search pattern for an object, and whenever I tested it in the simulator (or the couple times I got to test it in the pool), it took forever to do a sweep because it had to stop at each corner. I figured that a diagonal ZigZag pattern would accomplish the same goals as the original one, but with less places where it has to stop.

Also, this is sort of a smaller project so Alan can get back into the swing of things. After this, we'll be working on some more general states to use for the AI routines. I was kind of in a hurry to make the issue, so I wasn't able to put as much detail in the description as I wanted to.

[jwonders]

I agree with Sternberg that you should add a new piece of code to do diagonal zig zag rather than change the existing code. You might also want to look at the stopping criteria for the trajectory based motion and see if you can allow it to go to the next state when it is very close to the current target. I didn't get a lot of time to play around with actually using trajectories and watching them being executed as part of a larger state machine so there will certainly be improvements that can be made.

[schristian]

Yeah, I'll tell Alan to make a new state instead of overwriting the old one.

Also, I'll try to look into the stopping criteria for the trajectories; from what I could tell at the competition, the robot was spending a lot of time idling between trajectories. The simulator doesn't really show this, but in the water it's pretty apparent. Could it be some threshold value for stopping that could be updated, or is the robot actually processing things at that point?

[jwonders]

Here is a link to the stopping condition for trajectory-based depth motions. It might be informative to see which of the two criteria are preventing the motion from finishing. It is most likely that the controller has not reached its target. This could be due to a poor choice of trajectory, a poorly chosen threshold, or both. There are probably functions that can be tuned better than the cubic trajectory that I believe is being used for most motions. I am thinking that a generalized logistic function might give you desirable tuning parameters.

For reference, controller.atDepth() is determined here.

So, there are three approaches you could take to improve the performance.

• Play around with ram::control::ControllerBase::m_depthThreshold until you get satisfactory performance from the trajectories. (aside: these thresholds should be made into configuration values)
• Write another motion that has different stopping criteria.
• Write another trajectory that is more effective at getting the robot to its target position.