Once the network has been trained, it’s time to take it for a test run. The necessary activity is PilotActivity. After connecting to the Jumping Sumo (JS), it then loads the network and the analyst (necessary for input normalization and output denormalization) from the files placed in the raw directory (these are created by Encog after training). I’ve used a singleton pattern here for the network because the load is time expensive and doing it multiple times gets annoying really fast.
The inner workings of this activity is quite simple. When the user hits start, successive frames are fed to the network which then uses that as well as the previous speed values to calculate the next values. I setup two views so I could see the actual image as well as what the thresholded image looks like. The activity is setup such that if a new frame comes in before any previous frame is used for prediction, the old frame is overwritten.I’ve also used a timer to schedule calls to the autopilot’s move function every 40ms (this is by pure experimentation and probably is not the best way to go).
Whenever the AutoPilot takes/consumes a frame, it sets nextFrame field to null. This is important because the move method may be called before another frame is available. In this case I’ve taken a naive approach and simply dampened the output speeds by 1/2 its previous value. Now you may be thinking is this the best way to go? Honestly I don’t think so. This is my first foray into messing with or controlling hardware. I just needed to see the JS make a complete lap and I would be validated. I’ve recently heard about control loops and how they’re appropriate for these kinds of tasks and may incorporate one in future. For now, the code produces a satisfactory result and I was/am happy. Once again, here’s what it looks like:
Please leave a comment if you have a question.