It's been a lot of work getting here, but I finally have version 4 coded and running enough to launch some shuttles. Through the build & programing I've identified many areas of improvement, but I am really liking where it's going.

Next Steps..

Calibration

This is the real bear I have to face. Since I've decided on a UI where the user tells the shuttle where to go on the court all of magic happens in the background. This means that we need mathematical models to determine the wheel speeds and these must be perfect for a good shot accuracy & user experience. How does a user calibrate this or adjust it if it's wrong? 

There are many places this can fall apart:

1. Flight Trajectory - The shuttle path estimation is performed using a flight algorithm from Hugo Janton (see log 'User Interface - Version 2' for details). This will only be accurate for a specific shuttle type (feather/plastic) and geometry (brand variances). I'll need to validate this and determine an appropriate way to adjust & calibrate for different shuttles. If this model is incorrect the calculated launch speed will be incorrect so all subsequent steps will be incorrect.
2. Wheel Speed - Once a launch speed is calculated it must then go through another algorithm to determine the required rotation speed of each wheel. When the wheel speeds are perfectly matched the shuttle should fly straight and the required wheel RPM easily calculated based on the tangential speed components. However,  the wheel speeds will not always be matched. This could be desired because the +-19 degree of physical rotation on the launcher is not sufficient to reach the desired court position, or because we want to prevent or limit physical rotation to add deception to the shots. In these cases we'll vary the wheel speeds to angle the shots. I believe this speed mismatch will result in a sort of rolling motion where the shuttles center-line speed is roughly based on the lower wheel speed + 1/2 the wheel speed difference. Is this correct? Do the wheel speeds synchronize when the shuttle jams between them? Is it consistent across all wheel speeds and speed differences? If this model is correct we'll command the wheels to go at the wrong wheels speeds.
3. Wheel Speed Execution - After the desired wheel speeds are calculated in the step above, we then must convert that wheel speed to a pulse width modulation (PDM) signal that can be sent to the electronic speed controls (ESC's). The translation of the desired speed to the appropriate PDM signal is important. If we have determined the wheel must rotate at 1000 RPM, but in reality it's only rotating at 800 RPM then of course the shuttle will not land where expected.

Each of these areas will need to be broken down and tested and accounted for in some sort of calibration procedure when dialing it in. That procedure will need to be documented and coded into the final system.

Code Completion

The code is very much a work in progress. When I ended the last test session you could only stop feeding by pulling the power due to code issues. I need to work out the bugs, add the code related to different presets (loading, saving, and editing), add in the calibration  routines & parameters,finalize the mathematical models, add in data sanitizing, error checking, clean and comment the code, and more...

Testing

Testing is just beginning so a lot of reprints and running is needed to eliminate miss-feeds, improve accuracy, and determine if the physical parts can last. Calibration and testing is the hardest to sort out right now as I don't have any indoor space large enough to test in. Long term I'll probably need to rent out some court space to test properly, but I'll need to get the basics working first.

A few of the known issues:

• Attachment of upper plate assembly to main body is not sufficient.
• Wiring and wire paths need to be adjusted.
• Miss feeding - Likely related to shape of chute and/or pusher.
• Accuracy Poor - Likely related to shape of chute and/or pusher.
• Sonar sensor must be relocated to the rotating chute as the rotation of the launching direction exceeds sensing capabilities. 
• Through-Beam IR sensor needs a more extensive light trap to allow it to be used outdoors at all times of day. This is why it's taped off in the video.
• Long run testing.
• Stiffening components.
• & more...

 Documentation

The documentation side of making a project I can share with the world is not to be overstated. There's a lot to do to make it ready for other to follow along and build.

Electronics

To make this more accessible I need to properly document the wiring and look at making a custom circuit board.

That's all for now...