Testing Out Other Types of Balls

This weekend I tested out a few alternate sensors to start using as well as assembling the parts I got in the mail.

Let’s start with the new parts. Thom was kind enough to let me use his boarduino.

Sadly, it needed too much power, and while I could get it transmitting with the xBee, it would only go in very slow bursts when running it off of my lithium batteries. His FTDI Friend, though, is very useful in programming my ardweenies, so thanks Thom!

Teeny Tiny Ardweeny

I put together three ardweenies, but I somehow managed to put one of the atmega chip in backwards, so I’m down to two on that front. I’m trying to throw together a last minute rush order for more, though, because the two I have are working wonderfully.

Programming The Ardweeny

The tiny amount of space they take up allowed me to make  really small versions of the devices I made for last Thursday (gyroscope balls), that could run off the rechargeable batteries as well as being a little more secure because everything was on a bard instead of having loose pieces floating around. Here’s how the gyro ball innards are looking now:

This includes a voltage regulator on board. Some quick data sheet checking showed that while the gyro should be able to handle the 3.7 volts being put out by the battery, the xBee could not. It will be useful to regulate anyway, though, just to keep the power supply constant. Unfortunately, I only had access to one of these, so I could not test multiple balls, but I orderred more last week which are scheduled to arrive tomorrow (4/26).

As long as I had the functional balls, I wanted to get my collision etsting more accurate. Previously, I just looked for big spikes from either axis of the gyro, but this was often set off by the ball starting to move or even just moving fast. I am now using the converted speed data and looking for any sudden drops. This works much better, although there is the occasional false possitive, as the ball coming to a rest will often set it off.

I am realizing, though, that there is often a slight delay in when something occurs to the time openFrameworks is aware of it. I also encountered an issue where the parts inside the ball got jostled and reported a constant value for a a little while (usually about a second or a little less), this not only caused a further delay, but would sometime create false positives as a ball could be loosing speed steadily, but if the high value is reported several times in a row before the readings are accurate, the system can read it as a sudden dip.

Every so often, the balls would start reporting not quite garbage, but not terribly useful info. For whatever reason, this could almost always be solved by disconnecting the power and restarting it. The final balls will have switches on them, so this will be doable, but obviously I’d rather not have to worry.

I think that this issues as well as the jostled mechanics can be solved by making sure that the final casing wraps that parts tightly so that things can’t bounce around too much.

Movement Types

Testing the other day was extremely helpful for seeing how people were likely to actually interact with the balls. I tried to break down the actions into discrete catagories and came up with this list of things people could do with the balls. Some of these I know how to read, and some I’m not sure about

Rolling – just rolling the balls along a surface – gyro works fine.
Sliding – sliding the balls along a surface without rolling them – not sure how to measure this one, but it was not  a terribly common activity.
Rolling Collision – rolling the balls into things – gyro should work fine.
Clinking – colliding two balls into each other in the air – not sure how to test this one
Spinning – spinning the ball around its axis – gyro can pick this up
Moving in the Air – holding the balls and moving them around in space – accelerometer might be able to get this
Spacing – sliding the balls toward or away from each other – IR was my first attempt to measure this, but it didn’t work. I’m not sure if there is a viable alternative.

While it is not imperative that the balls respond to all of these cues, it would be fun to have at least one ball for most of them. The actions that I saw being performed a lot was Moving in the Air, Rolling, Spinning and Clinking. All but Clinking should be fairy doable.

Accelerometer Ball


To adress to the Moving in the Air crowd, I tried out making a ball that uses the accelerometer instead of the gyro. This ball can’t sense collisions, but it react very nicely to spacial movement and still makes fun sounds when rolled. If it is not being moved, the sounds quickly fade out. Part of selling this as sounds being created by the balls definitely seems to be having them silent when not being touched. This was mentioned by several testers.

Although I enjoy the sounds it makes on its own, given that this has three fairly easily controllable axes, this should work well for controlling the pitches of the other balls. Given that the accelerometer takes up only 3 analog pins, it would be possible to combine this with a gyroscope (which takes up 2).

Range Finder Ball

A lot of people did try to adjust the space between the balls, and right now this does not do anything. Although I don’t believe it will be possible to make every ball aware of their spacial relations, it may be possible to make a single, clearly marked ball that does. I was thinking about putting a range finder in a ball marked with an eye:

This ball could affect one or more other balls with the value received from the range finder. Hopefully the eyeball marking would make its use (somewhat) clear. It was easy enough to set up, and I got a ball sending this data to OF pretty quickly, but until I get those other regulators, it was hard to test it with much.

The more I work with this, especially since I want the different balls to affect each other, the more I think I’m going to wind up with four or five unique balls that all do slightly different things. Even just using the gyro, I could have a ball that acts like the current gyro ball, or one that specifically wants to be spun around one of its axes.

Resin


I also tested out the hardening resin I bought on the styrofoam. It is drying now, and should be hard by the morning. At that point, the ball should be easily paintable, and not too thick to block and xBee signal.

I’ll be curious to see if LEDs will still be useful for internal lighting.

In terms of casing, I’m also thinking that I may need a way of opening the balls up in case anything goes awry with the wiring as they are being bumped around. I am going to do my best to make sure that everything is secure, but I may be setting myself up for disaster if I plan on sealing it up semi-permanently. Getting into them doesn’t have to be especially easy, just some way that won’t damage the balls. If the resin is hard enough, it may be possible to use a set of screws to keep each ball shut, which might solve this problem.