Featured on UMich ECE Site!


For my upcoming ArtsEngine Microgrant project, I’ve been featured on the Electrical and Computer Engineering website. I’ll be attaching a sensor array to the ‘Cube’ (Alamo) statue on campus. Using some physics and the parallel axis theorem I’ll be doing my best to compute realtime velocities. Hopefully the pi-zero can keep up.

Here’s the link to the full article

Here’s a small preview:

CE junior Keenan Rebera wants to make the Michigan Union’s famous Cube sculpture even more interesting – with the power of technology. The spinning metal art installation nestled on central campus draws a lot of curious eyes, but Rebera thinks he can take the experience to the next level.

Rebera has designed a small sensor array and display device that attaches magnetically to the Cube. When active, it can detect the velocity of the Cube when a person spins it and generate any number of fun factoids to show off. How fast did you just spin this thing? How many times has it been spun today? If The Cube were a generator, how much power would it be producing right now?


TrumpyBot- Building a Twitter Bot

Well, I had a solid half-hour before practice and decided to build a twitterbot.

(You can follow him at @trumpybot)

I had him set up on a crontab but then decided to make my own little menu system so I could cycle through the poorer generated tweets.

(Following this tutorial closely: http://jitp.commons.gc.cuny.edu/make-a-twitter-bot-in-python-iterative-code-examples/)

Essentially, the code takes 20 or so trump-isms, goes through some adjective and noun repositories on GitHub, and then creates a madlib with some random generation, spitting out interesting results.

From there, tweepy handles the rest. Doing this in Python made things really easy!

Screen Shot 2016-10-15 at 5.35.40 PM.png

my tiny Python menu system, and the result:

Screen Shot 2016-10-15 at 5.36.09 PM.png

Raspberry Pi RetroArcade

This will be a series of posts documenting my progress on a retro arcade. Here is a link to the Hackaday.io page: (Link)

Here is the page itself:

Hi, all!

I’ve been working on this project for several weeks now and I’m just getting around to posting it here on Hackaday.io

I started by shopping a case out of wood, sanding some of the rougher edges into rounded sides, and carving in an indent to mount the screen. Ended up using those little picture frame clasps to secure the screen.

From there I spray painted the body and cut out a stencil for some sticker paper and sprayed down a piece of plexiglass that I sanded with fine sand paper for diffusion.

I was able to tie all the components together and have a generally operational setup:

Then I shoved it all into the case, added a kickstand and clasps to secure the screen:

So I started to test the thing, and I realized that there was a colored square in the upper right corner of the screen when running the device. I read that this was a sign of low power. I went and designed another case in Sketchup to see if I could manage some better spacing and heat dissipation:

And that was actually pretty fun because I have minimal experience in CAD programs. Didn’t struggle too much with this though because I have hefty experience in Blender3D.

So I redid the power circuit to see if my switching mechanism was weird and struggled alot with the new design. I kept having odd issues, and eventually consulted a forum. We settled on this solution:

However, now the circuit behaves in really strange ways. For instance:

When I plug in the circuit to power, everything works fine, 5V coming out of the end of the relay. However, once I connected a load (Either the LCD driver board or the RPI), the voltage output drops. Then, once the load is disconnected *the voltage output remains low (1.8V or so)*. I’ve never seen this behavior before in a circuit. What could be the issue?

I Made a Car That Doesn’t Work

It always comes back to the Legos.

I’ve been wanting to prototype some kind of four-wheeled rover since I got my hands on my first microcontroller three years ago. Robotics has always been the goal. I learned a lot and eventually got to a point where I could attempt it.

But where to start? Cardboard is usually a nice option, and tape and paint sticks looked good too, but I can’t ignore the Lego pieces I failed to sell at the garage sale when most of them left me. I have a bunch of Lego Technic pieces sitting around, and so I decided to build the chassis from them.

Steering Mechanism

The two images below helped a lot with the construction of a wheel-driven steering mechanism. I didn’t have a flat piece with gear teeth, but I noticed that the same effect could be achieved by using a hard connection on the diameter of the wheel to the shaft (Much like those things on train wheels).


The result of this sits below. Note that in the poorly-focused image the wheel is pointing on the z-axis, and I eventually modify it to face y.

Screen Shot 2016-06-02 at 4.04.53 PM

The Drive Train

This part was only difficult because real-world parts don’t always mix well with Legos. Much hot glue was employed, and I ended up gluing a connector piece to the motor shaft, extending the axle from there. I used a small gear on the motor to turn a large gear connected to the back wheel axel, so that the gear ratio would produce the maximum amount of torque.


Putting it all Together

Eventually, I was able to cobble everything together and use an adhesive breadboard mounted onto the back of the vehicle, putting pressure on the back wheels where the chassis was highest off the ground.

I originally intended to use a raspberry pi to drive the thing, but it seemed kind of overkill. I grabbed the ISP Backpack I created in an earlier post and had my ATTiny 85 send pwm signals from pin 0 into the servo, whilst sending pertinent data to the lovely dual h-bridge breakout from Adafruit. There are only two pins on the ATTiny capable of pwm output so this worked nicely.

Powering the vehicle was a different story. The DC motor driving the rear wheels operated off of 9V and the rest (ATTiny, servo) had a 1.5-5.0 operating voltage. I was able to very carefully solder together an LM807 voltage regulator circuit onto a small cut piece of veroboard. I used some male header pins to act as a breadboard power supply and routed the leads from the battery both to the regulator circuit and to the exposed pins of the h-bridge breakout.



In the end, the ATTiny was able to successfully steer and drive the vehicle. The gear ratio worked really well, and when the car wasn’t weighing itself down, the tires spun so quickly they generated wind.

However, when in contact with the ground, the motor lacked the power to move the vehicle at more than a laughably slow pace. I started this project trying to see if I could fabricate a vehicle from scratch, and I would say I have succeeded.

I could purchase a higher-torque motor, but then I’d need a battery upgrade, and then I might as well go all in and mod an RC Car.

That’s a project for another day. Cheers!

Riding the (Sine) Wave

In Hoop-Not-Block, the player doesn’t directly control the motion of the player object in the game. Instead, the player object moves along a consistent sine-wave and the player is given the ability to adjust the amplitude and period of this wave, effectively creating an interesting control scheme that will take a little time to master:

2016-03-02 12_10_28

I love messing with alternate control algorithms, but they aren’t as easy to implement as  you-push-up-I-go-up schemes. The challenge here is getting the sine wave to adjust itself in relation to the player only. To modify the amplitude or period at any one time is to change the structure of the motion and therefore the player position. This leads to predictable but strange mechanics that don’t make sense in the form of a game.

This algorithm, admittedly, took me two weeks to figure out, and in the end it was solved by five lines of algebra and a dash of common sense.

Step 1: Limit Variables (Build a Test Scene)

Trying to test different algorithms inside of the player control code was messy, and soon debug variables and values were running amuck in the previously clean and workable code. If you want to play around, build a test scene! Put it in its own folder and keep it all together. Have a riot.

Step 2: Consolidating Motion

If there’s something you’re going to be changing a lot, please just put it in a function. I found myself switch around variables in three different places in my test code and it got frustrating and confusing quickly. Soon the numbers you predict don’t appear because you forget to change it in multiple places. Put it. In. A. Function.

Step 3: The Simplest Solution is the Best Solution

I tried to use smart ordering to make everything work out nicely, but then I realized that I needed to see where the player is versus where the player might be. They can’t be the same thing, otherwise nothing would change. I ended up hacking out some functions that dealt with their own local variables and predicted future motions. It’s a bit ugly, but I’m just happy it works. Elegance can be achieved in future iterations. Speaking of which…

Step 4: Itarat Iterat Iterate!

Do it. Then do it again. Then get rid of the trash and do it again. Do this eight times over and you might get it. A step forward is a step forward, no matter how small. Rethink what you did and clean up as you go. It seems it takes me a few tries for me to even understand what I just typed out.

Step 5: Write Stuff Down

I might just be a spacial person, but I need to draw diagrams and write things down before I do anything of worth. No amount of intuition can best a well-drawn flow chart. Organize your thoughts, then write the code. Then organize that code. Then organize your thoughts on that code. Getting annoying yet? Good. Do it again.

Amplitude was solved by moving the graph over the amount the player character would be moved by the delta between the old amplitude and new amplitude. It was a classic case of move it, then move it backwards by that same amount.

Period was solved by about twenty attempts and then eventually a few lines of algebra. It became apparent after I realized I only had one variable to deal with.

Just happy I was finally able to nail it. Happy coding!


ATTiny ISP Backpack

Used some time this weekend to get a shield ready on some protoboard for the Arduino. It connects the correct pins for In-System Programming of an Atmel attiny avr. There are circuit diagrams all over the place for building these. I wanted a permanent and quick solution for programming and reprogramming.

Regrets, revisions, resolves:

In hindsight, a heartbeat and positive connection LED would be great for some feedback during programming. An exposed reset button extension would be great too, as time-sync errors happen all the time with the Arduino-as-ISP. Luckily, solder isn’t  permanent.


Most of what I worked off of came from the great information over at High-Low Tech:

Programming attiny
The circuit itself


  The shield itself

 The programmed chip in action