Performance of the robot in driving only mode is about 3x better. The robot can drive itself around the park in about 30 minutes instead of 90. The vast majority of the time is now spent while RVR is executing motion commands. More details below.

I made a several important changes to improve performance:

• Stop taking pictures. There's no reason to take all the photos when we're just trying around the park. Those 7 pictures took 15 or 20 seconds.
• New angular app is much nicer and is continually sending commands without a delay, instead of waiting a few seconds to allow a human to reject the command before sending it.
• Switching from InceptionV3 to MobileNetV2 saved several seconds. 
• Lowered the delay after sending commands to the RVR.
• The code now detects left/right cycles and works around them.

A few caveats:

• MobileNet takes longer to train than Inception. Since that's a one time cost, it's not a big issue.
• My current MobileNet isn't quite as accurate as the Inception network was. I will have to try letting it train longer and see if that can be improved.
• The robot will occasionally get in a cycle of left/right operations. Because the robot turns 5 degrees at a time, it's possible to cycle past the optimal position to go straight. My solution is to detect which of the two options (left or right) has the best straight acceptance, and move straight when that occurs. This quickly works around the problem at the cost of being somewhat out of the "optimal position".
• There seems to be some sort of buffering issue in the control portion that was exposed by lowering the delays between commands. The symptom is that commands sometimes take a long time to execute, a command executes for a short period, pauses, and then continues, or a few commands fire off in a row.

It's 185 steps to go around the park, but that's not counting the left and right turns. My guess is that it's closer to 300 commands, which means it's taking an average of 6 seconds per operation. It's clear when the operations are flowing smoothly that we can do a move and a predict in less than 3 seconds.

It seems that if we can improve this buffering/control issue it should be possible to double the performance. I think that's the next thing to look in to.