Air Hockey Playing Robot

Air Hockey Playing Robot built from scratch with Daniel Koniar and Steve Thomas for CSCI 5551 Robotics. I was in charge of retrieving input from the webcam, determining puck and striker positions, and predicting puck movement and an intercept course. Since the project experienced multiple delays and setbacks the motors never got working properly, and several features proposed never were realized.
Paper

Boids of Life

Final Project for CSCI 5611 with Joseph Morelan and Shihao Zhong.

source
You control a flock of boids with the mouse position. They need to drink from the blue water, get 'food' from the greyish red circle of food, and 'sleep' on the green grass to stay alive. If any of these parameters drops to 0 the boid dies. Their stats are tracked by each boid color, the more of a resource they have, the more of the associated color they become. When all boids die the game is over.

3D Boids flocking

3D flocking algorithm using Boids simulation model. Each boid is represented as a blue sphere with a smaller green sphere used to visually track the direction vector. The 3 rules used are:
1. boids fly to perceived flock center
2. boids avoid other boids
3. boids match flock direction
Flock center and direction are calculated by looking at each boids' local neighbors, changing the size of this parameter changes the overall flock sizes.
Avoiding other boids uses a 1/x function to determine the multiplier applied to the vector between 2 boids. This means the closer the boids are, the more 'force' repells them. The nearby boids calculation for this rule uses a smaller size than the first and third rules.

In this video we see direction propagation inside a boids flock, as it starts in one end of the formation and propagates throughout. Notice how the boids maintain a respectable distance from each other.

Where it Breaks Down

This video shows 2 boids in direct opposition repelling each other perfecty, as there are no forces to apply variation that would allow them to align.

This video shows the 'strength' of the repelling force, these boids are not perfectly aligned, yet as they get closer the repelling force of rule 2 and the flock direction variable from rule 3 combine to make he boids swerve away from eachother instead of combining.
In addition, the boids jitter a great deal, especially when Rule 2 comes into play. This could be fixed by implementing a maximum turning speed for each boid which should help smooth the way they turn, and implement a better algorithm for dealing with boids intruding too far into each others' space.

Obstacles and Pathfinding

In these videos, black obstacles have been added, along with the a* algorithm from homework 3. To have the boids properly interact with these new objects, 2 new rules are required:
4. boids want to travel to some point on the path
5. boids want to avoid objects
Rule 4 is simply the direction vector pointing to the next point on the path returned by the A* algorithm, and Rule 5 is simply a copy of rule 2, only instead of summing the local boids, uses all objects. One global path is used for all boids, updated to path to a random point in the obstacle maze whenever the end is reached. This path is shown as a red line, a small red sphere marking the current node the boids are pathing to. Notice how even with these new rules, the boids still travel in flocks.

Where it Breaks Down

You may have noticed in the earlier videos, boids will get stuck on the black obstacles, bouncing back and forth on them, slowly moving around it. This is due to the other Rules upon the boid overpowering Rule 5 until Rule 5 overpowers them, creating a very fast flip-flop effect in the direction vector.

Very occasionally, the point picked randomly by the A* algorithm will situate the boids such that the function used to determine whether the goal is reached will fail to register. This function simply determines if for each boid if the distance from the boid to its perceived flock center is larger than the distance from the current path node to the perceived flock center. This will produce jittery behaviour as the boids try to situate themselves as close as possible to the node wild obeying all the other rules.

Boids Source
Boids with Obstacles Source

Ray Tracer

View on Imgur
Built a ray tracer for CSCI 5607, supporting depth of field, specularity, circles and triangles, multiple colors, transparency, reflections, refractions, and multiple colored light sources.

Comparing Dijkstra's Algorithm and A*

Source
Using Dijkstra's algorithm and Astar with a Probabilistic Road Map to navigate a 3D space. The large green sphere is the goal, the large red sphere is the AI, the large black sphere are obstacles, and the small blue spheres are the points found by the probabilistic road map. Use WASD to move the camera in mode 0, the AI in mode 1, and the goal in mode 2. Drag the mouse to rotate camera. Set modes by pressing the corresponding number. Press enter or return to have the AI search. Press r to reset the AI's position. Press spacebar to swap between using dijkstra's algorithm and astar. In the video, both algorithms find the same path, but Astar ound it in 23 miliseconds, while dijkstra's algorithm found it in 88 milliseconds.

Dijksra's Algorithm

Source
Using Dijkstra's algorithm and a Probabilistic Road Map to navigate a 3D space. The large green sphere is the goal, the large red sphere is the AI, the large black sphere is an obstacle, and the small green spheres are the points found by the probabilistic road map. Use WASD to move the camera in mode 0, the AI in mode 1, and the goal in mode 2. Drag the mouse to rotate camera. Set modes by pressing the corresponding number. Press enter or return to have the AI search. I accidentally made the obstacle too large, but this does not impact the algorithm much.

Firework, with audio!

Source
Fireworks simulation as a combination of a moving particle emitter and a radial particle emitter with color changing particles. Audio effects are keyed to play when the firework starts and when it changes from the moving smoke emitter to stationary radial emitter. Turn up volume, sound capture was very quiet.

Fire Simulation

Source
Fire simulation very similar to fountain simulation only with altered gravity and initial velocity, and changes color as the particle ages. Particles also fade out as they age.

Particle Waterfall

Source
Water fountain in 3D, with a user controlled camera. Move left/right/forward/back with a/d/w/s respectively. Click and drag the mouse move the viewing center. Uses a textured and colored sprite image at each point.

Bouncing Ball

Source
Ball bouncing in 3D in openGL, constrained in the x, y, z directions at a maximum ceiling and floor. If the ball would have passed that direction maximum, it's position and velocity are set to simulate bouncing. Eulerian integration is used to solve for the position and velocity. On each bounce, the ball's rotation is set based on the velocity not in the impact direction.

Making of: Kuria and Orokitty statues

So! first we start with reference material:

Next, the 3D model has to get made, and I've always wanted to try one of the more professional programs, so I downloaded a free trial of 'Autodesk Fusion 360' and got to work:

Man, this isn't a very flattering angle for  you, kuria...

Orokitty certainly pulls off the 3/4 look much better!

Have to say, those curves were a pain to get looking right, but it was worth it!

Here we see the 3D print, fresh from the Makerbot at my Library! 

As you can see, the kuria's body comes in 2 peices, and the orokitty's head is a completely separate part! This is because I plan on filling their hollow bottoms with sand as a ballast, otherwise they're way too top heavy:

After quite a bit of sanding and cleaning and removing support material, I did a quick dry-fit to make sure everything fits:

The brown stuff is some clay that was lying around that I used to fill in some low spots, Makerbot prints aren't always the best. The ear bits aren't in this one because the pegs I planned on using to attach them to the main body were too thick to fit, yet too thin the reliably sand down, eventually I decided to just snap off the pegs and superglue the ear filly bits directly in there.

Testing wobblyness with the newly weighted bottom:

That done, I spent a couple days getting all the kuria, which led to this discovery:

Who knew the back was so detailed? 

Time to get stuff painted! The first two layers is a light grey spraypainted on. Then using a compass, I sketched out the lines for the dark grey lines, and then those got hand-painted on.

The gold stripes were done by simply spraying a little of some gold spraypaint into a dixie cup and using a brush while still wet.

Note: this completely ruined the brush. Use with caution.

A second coat of the darker grey paint was applied to straighten out the lines, and the extraneous bits were spraypainted gold:

And here's the dry fit:

The orokitty got a similar treatment:

The only difference was the halo bits had to be superglued in ahead of time so the joins would blend in better.

And here's the finished product, hangin out on my desk:

Imgur Album

2D Grid based Guard AI

Click here to play
Source
Paper
I implemented a probabilistic Artificial Intelligence and used it to create an opponent for a simplistic but randomized Hide and Go Seek 2D grid based game in JavaScript as an example of probabilistic reasoning in an unknown environment. The goal was to demonstrate probabilistic reasoning in stealth-based games where the omniscience of normal AI is a detriment to exciting gameplay. This should be useful for realistic stealth games and games like Hide and go Seek, where the programmer may not want to program in where to check manually, or where the level changes over time or wants to have a unique map each time. Hopefully the AI will also be a more realistically human opponent, and be harder to trick or exploit during gameplay.