Often we want to know how to get somewhere from someplace else. The key is that the vector that represents the trip from “here” to “there” is equal to “there”-“here” or something like mathVecSubtract(trip, there, here, 3) assuming we name our vectors appropriately. Of course we could always jump in that taxi and use setPositionTarget, but where is the fun in that. Let’s get there on our own. For this example our “here” is our position (from MyState) and the “there” is the other SPHERE’s position from (OtherState). So to get there from here we want to calculate the difference between “there” and “here” and go that way. We will calculate the “diff” vector and then use setVelocityTarget to go that way. This sounds really good because if we’re far away we’ll try to go fast and as we get close we will slow our speed. Try to write the code yourself…
or use this code.
DEBUG(("\nHello Space! Time: %d",time));
Did the SPHERE do what you expected? Why?
This program tends to cause the SPHERE to oscillate but should eventually find the target. You may want to try extending the game by changing the Maximum Time in the Simulation Settings. This oscillation occurs because by the time we get close to our target and start trying to slow down we’re already going so fast that it takes us way too long to stop and we’ve overshot. Then we drive back and miss again and again, etc. Let’s calm this satellite down by adding the following lines of code just before the setPositionTarget line.
This should work better. See if you can adjust the .25 to something else to see if you can make it even better.
We’ll discuss these multiplication lines more in the next section.
The ZR API functions that we’ve discussed so far that have “Target” in their name use more sophisticated, and better tuned methods than the simple control system we used here. You can investigate PD/PID control to learn more about this.