Lego Slingpult

Our final project has a relatively functional interface allowing for things including loading and saving data, running sensors, and, importantly, running the ball-throwing algorithms. Furthermore, it integrates tools across statistics, computer science, and robotics to create a unique system designed to hit a jenga block from a distance with as few tools as possible (the only sensors for the algorithm itself are the encoders and the range sensor.) Thus, while not as flashy as the some of the premade robotics kit projects, the series of unique solutions we developed to solve problems combined with a product which has meet our personal expectations has validated the time we invested in building it.

Here is a full list of materials included in the end product:

1. The Legos come from Lego MINDSTORMS, which are kits specifically tailored to lego robots. One of the great benefits of constructing it out of legos is the legos are easy to utilize and change their construction in ways we couldn't do with metal robots or with a kit.
2. We also used a Raspberry Pi in order to run the code. We have used them before in combination with lego robots, so we felt it was a fine adjustment.
3. Lastly, we used a variety of scrap materials in order to play smaller roles in the process. For example, we used Jenga blocks as targets because they are of consistent shape, can stand upright, and are readily available.

The original catapult design is powered by three motors working simultaneously against an axel. In order to increase velocity over torque, however, we made the motors power a large gear. This large gear turns a smaller gear which is attached to the handle of the catapult, which is then attached to a holder for the ball. Here is an example of it running.

Challenge: Weak Motors

A challenge we faced in this first phase was that the lego motors are very weak. In many designs of the catapult, the ball was moreso falling out of the catapult than being launched by it. Thus, we brainstormed potential ways to launch the balls while utilizing whatever potential we could get out of the motors as well as possible. Some ideas we considered was even more extreme gear ratios, flywheels, and driving the wheels forward during the swing.

The most significant upgrade to our system throughout the entire process, and perhaps compared to other catapults, is the rubber band. The rubber bands we found, while very elastic, also have a lot of force (this was the first prototype at full power.) Thus, we changed our design to be more akin to a slingshot, where most of the force is coming from the band. Furthermore, our design also works such that while in many cases the motors are working in conjunction with the rubber bands, they also work to hold the design in place when necessary to take calculations (see next section) or also to weaken the force of the elastic band when necessary, such as if it is targeting a shorter distance.

Challenge: A weird system

A new challenge we found with this system was how we could get feedback to make future decisions by the robot better. Before, we were going to try to fit a model, but by including the elastic band we made it less immediately predictable. Thus, we began thinking about alternative ways to get as close to an optimal outcome as possible.

Getting Feedback

Our primary form of feedback comes from our range sensor. However, the range sensor not just tells us how the power corresponds to the distance, but it is how the robot is able to tell when a launch overshot, undershot, or made a hit. Since the catapult shoots relatively straight, a ball which didn't go far enough will almost always be detected by the range sensor, thus if we see the distance decrease by a significant amount within a couple seconds of a shot, that means we undershot. Meanwhile, if the system detections no change in its distance long-term, then it overshot. Finally, if the long term distance changed, then the block was hit, meaning the power level was on point.

The one unusual edge case is when the motor power is so high that at a particular angle its release is still able to overpower the band, which we would treat as an undershot because, like an undershot, we would respond by increasing the power of the motors in conjunction with the force of elastic band. However, we cannot tell this with the range sensor, so instead we use encoders.

Uninformed Algorithm

The uninformed algorithm only uses the information from the current session to determine what is the next power to try. There is an interval of powers which it could feasibly do (technically power ranges from -1 to 1, though we restrict it a bit further because much of this range will lead to non-releasing powers or is so strong it will break the catapult.) We execute a throw of the median power value of the interval and get feedback on where the ball landed using the range sensor/encoders in combination with the logic above, and this allows the robot to narrow the interval of plausible power values (if it was an undershot, we can assume an even weaker shot won't lead to a hit.) In expectation, the interval will eventually be within the tolerance of powers which can knock down a jenga block from that distance. I took the following video of a full runthrough, but in all honesty its pretty boring.

Splines-based approach

Normally, my instinct to solving problems of prediction is to fit a model (in particular, I like fitting regressions.) Unfortunately, I didnt see a clear way in which I would expect power the trend with distance, since it combines velocities, angles, and elastic band properties I don't understand beyond an intuitive level. Thus, I opted for fitting a spline to the data (collected from the uninformed algorithm), which is cubic but allows for interpolation. This approach worked better for closer distances, where the range sensors was recording more of the distance actually from the jenga block and there was less background interference. Nevertheless, spline-based throws were usually accurate with enough samples around a distance. Here is an example of such.

Challenge: Battery Charge

The battery charge has a dramatic impact on motor performance, with uncharged batteries being much slower than fully charged ones. Thus, the performance could vary depending on how long I was working. Admittedly, at this stage this wasn't as big of a problem for eventually getting a result, compared to the bandless catapult which couldn't function on a low charge battery.

While we ultimately have achieved our MVP of creating a robot which can catapult a ball at a target and eventually hit it, there is still much work to be done in the future.

Continuation 1: Rotation

The largest portion of unused code is our rotation function, which we were going to use to center our robot on the lego block. Due to some unusual behavior of the range sensor in motion, we were unable to implement it in the time frame, but it could serve as a useful feature in the future.

Continuation 2: Fitting A Real-World Model (with more parameters)

While splines are good, they work best on smooth, consistent data. A physics-based model for how we would expect the system to function could lead to better results requiring less of the uninformed algorithm. Furthermore, I might also consider using alternative parameters to account for the impact charge can have on the performance.

Continuation 3: Beyond legos

While legos are nice for creating something easy to change, they are flawed. As mentioned before, the associated motors are incredibly weak, and some parts are stronger than others. Thus, a potential great leap for the project would be to create it out of a stronger material, in particular metal. Furthermore, with access to more robust materials we may be able to improve other aspects of the model