Jacek Fedoryński's blog

Electricity meter fun

noreply@blogger.com (Jacek Fedoryński) — Tue, 21 Feb 2012 01:16:00 +0000

At the place I live, the electricity meter looks like this:

The fancy display shows total kilowatt hours and maximum power consumption, but it doesn't show current consumption. Instead it has this blinking red light - the faster it blinks, the higher the power consumption. But to get the actual figure, I'd have to count how many times it blinked, measure the time and then do some arithmetic. And that would be pedestrian. Instead I wrote an application for my phone that does the measurements (with the phone's camera) and displays the current power consumption:

Here's the source code if anyone's interested.

NXT Drawbot

noreply@blogger.com (Jacek Fedoryński) — Sat, 31 Dec 2011 15:27:00 +0000

When I saw this drawbot, I immediately thought it was something I should be able to recreate with Lego Mindstorms. And so I did. The idea is simple, there's a pen suspended on thread from motors in the corners. When the motors wind or unwind the thread, the pen moves and draws a line. The rest is a simple application of the Pythagorean theorem to move the pen where we want it.

When watching other drawbots on YouTube etc. I was surprised to see they were able to achieve a level of precision that allows them to recreate pictures by effectively drawing each of their pixels with clever patterns. My bot clearly lacks such precision. I think the main reason for that is the friction between the pen and the drawing surface. Each time the pen is about to start moving, there's a noticeable moment before it breaks away from the static friction. That makes the bot incapable of very small precise movement. There's another source of imprecision - since the radius of the spools that the threads are wound onto is small, the difference in radius when there is no thread wound and when there is a lot of thread wound on the spool is non-negligible.

Here are some more pictures of the bot.

Google Earth with a PS3 controller

noreply@blogger.com (Jacek Fedoryński) — Wed, 19 Oct 2011 22:15:00 +0000

Google Earth is a lot of fun with a 3D input device. But not everyone can justify shelling out a hundred bucks or so on a SpaceNavigator just to play with Google Earth. I've explored other possibilities, but the best alternative I've come up with is the PS3 controller. It has more than enough joysticks and buttons for five degrees of freedom. Have a look:

The PS3 controller is pretty well supported under Linux (at least if you connect it with a USB cable, it's more complicated if you want to use Bluetooth). The only problem really is mapping its various buttons and joysticks to proper functions in Google Earth. Fortunately, there is a piece of software called pystromo that can freely remap input events, thus allowing us to turn a PS3 controller into a SpaceNavigator-lookalike.

Here's what you need to do.

Download and unpack pystromo.
Open the lib/constants.py file in the pystromo directory with a text editor. Find the line containing "ABS_MISC" and add the following two lines after that (before the curly brace):
```
48: "ABS_L2",
49: "ABS_R2",
```
(We have to do this, because pystromo doesn't have constants for the PS3 controller's L2 and R2 buttons.)

Create a new file in the pystromo directory and call it, say, config/ps3-ge.map. Put the following in it:


[Device:dualshock]
vendor=0x054c
product=0x0268

[Map:dualshock]
ABS_X@0~255:ABS_X@0~255
ABS_Y@0~255:ABS_Y@0~255
ABS_Z@0~255:ABS_RZ@0~255
ABS_RZ@0~255:ABS_RX@255~0
ABS_L2@0~255,ABS_R2<1:ABS_Z@127~0
ABS_R2@0~255,ABS_L2<1:ABS_Z@127~255

Connect your PS3 controller using a USB cable and press the PS button.
As root, run the following command: ./pystromo-remap.py -R -v -m config/ps3-ge.map
This will create a new input device, called eventN in /dev/input/. The one you're looking for is the one with the highest number. As root, run this to give your regular user access to the device: chmod 666 /dev/input/eventN

Open /opt/google/earth/free/drivers.ini with a text editor and put the following after the "SETTINGS" line (after the curly brace), remembering to replace eventN with the proper device number:


SpaceNavigator/sensitivityX = 0.4
SpaceNavigator/sensitivityY = 0.4
SpaceNavigator/sensitivityZ = 0.1
SpaceNavigator/sensitivityPitch = 0.05
SpaceNavigator/sensitivityYaw = 0.05
SpaceNavigator/sensitivityRoll = 100
SpaceNavigator/device = /dev/input/eventN
SpaceNavigator/zeroX = 127
SpaceNavigator/zeroY = 127
SpaceNavigator/zeroZ = 127
SpaceNavigator/zeroPitch = 127
SpaceNavigator/zeroYaw = 127
SpaceNavigator/zeroRoll = 127

Run Google Earth.

You should now be able to navigate using the left and right sticks and L2/R2 buttons.

Control Google Earth with an Android tablet

noreply@blogger.com (Jacek Fedoryński) — Sun, 16 Oct 2011 23:34:00 +0000

I have previously described how to turn an Android device into a mouse under Linux, using the uinput module. There's no reason we should limit ourselves to a simple mouse. Some applications benefit from a multi-axis controller, which we can simulate in a similar way. One such application is Google Earth. Here's a demonstration video:

And here's how it's done. Just as before, there's an application running on the tablet that listens for touch events and broadcasts them on the network and a Python script running on the computer that listens for those events and translates them to simulated controller events that Google Earth understands. Here's the tablet application's source code and here's just the APK if you don't want to compile it yourself. The Python script that's running on the computer is here.

There are some additional hoops you have to jump through to get it running.

The Python part requires python-uinput, which in turn requires libsuinput.
Remember to unblock UDP port 20125 on your computer's firewall, as that's the port that the tablet application uses to broadcast touchscreen events (the tablet and the computer obviously have to be on the same network).
Run android3dmouse.py as root.
Run the TouchscreenBroadcaster3D application on your Android device and touch the screen (the simulated mouse device only appears on the computer after the first events are emitted).
Look in /dev/input/ and figure out what the newly created device is called (it's going to be the eventN file with the highest number).
As root, execute the following command to let Google Earth running as a regular user access the device: chmod 666 /dev/input/eventN

Open /opt/google/earth/free/drivers.ini with a text editor and paste in the following after the "SETTINGS" line (after the curly brace), remembering to replace eventN with the proper device name:

SpaceNavigator/sensitivityX = 80
SpaceNavigator/sensitivityY = 80
SpaceNavigator/sensitivityZ = 30
SpaceNavigator/sensitivityPitch = 0.5
SpaceNavigator/sensitivityYaw = 0.5
SpaceNavigator/sensitivityRoll = 0.5
SpaceNavigator/device = /dev/input/eventN
SpaceNavigator/zeroX = 0.0
SpaceNavigator/zeroY = 0.0
SpaceNavigator/zeroZ = 0.0
SpaceNavigator/zeroPitch = 0.0
SpaceNavigator/zeroYaw = 0.0
SpaceNavigator/zeroRoll = 0.0
SpaceNavigator/gutterValue = 0

Since X happily grabbed the new device and it now moves the mouse cursor, execute the following command to make X let it go: xinput set-int-prop "python-uinput-mouse" "Device Enabled" 8 0
Finally, run Google Earth.

You should now be able to pan, zoom and rotate via multi-touch gestures on your tablet's (or phone's) screen. (Yes, one more degree of freedom would be nice, but I haven't figured out a good way to do it yet.)

If you can't get this mess to work, I'm not the first one to do something like this, there's a Google Summer of Code project done by Reese Butler that works in a similar manner, but uses a slightly different control scheme. The Android part is on the Market and the computer part can be found here. Maybe you'll have more luck with that one.

Android phone as a touchpad for a PC

noreply@blogger.com (Jacek Fedoryński) — Fri, 19 Aug 2011 21:52:00 +0000

The Linux kernel has a module named uinput that allows userspace programs to simulate input devices like mice, keyboards and joysticks. I used this neat mechanism to turn my Android phone into a touchpad for my computer.

Here's how it works. On the phone there's an application that broadcasts touchscreen events over the network. You can get the application's source here. On the PC there's a script running that listens for the events and translates them into mouse events that get injected into the system via uinput, at which point the X server sees them and moves the mouse pointer accordingly. That part is written in Python and requires the python-uinput module (which in turn requires libsuinput). You can get its source here.

As always, there's room for improvement. I used my phone's trackball as left mouse button, but for phones or tablets that have no trackball it would probably make sense to use some regions of the screen as buttons. It would also be interesting to add multitouch gestures for scrolling and zooming. Another thing that comes to mind is to use the phone as a 3D controller for Google Earth. Four degrees of freedom should be doable with the touchscreen alone via two-finger gestures and maybe we could use the phone's other sensors like the accelerometer and gyroscope (which my Nexus One lacks, but newer phones have them) to get all six.

On keyboards

noreply@blogger.com (Jacek Fedoryński) — Sun, 03 Jul 2011 20:31:00 +0000

Many people don't care about keyboards. I do. But unlike most keyboard enthusiasts, who focus on the switches (mechanical vs. rubber dome etc.) and are prepared to give long lectures on buckling springs and how the IBM Model M is the greatest keyboard of all time (which is probably true), I don't care that much about switches. I can't stand keyboards with wrong key layouts. I don't mean Dvorak vs. QWERTY, I mean the physical layout of the keys. And by "wrong" I mean pretty much any layout that's different from the standard full-size one. (That's one of the reasons I don't see myself using a laptop for anything serious anytime soon.)

Fortunately, most full-size keyboards have sane key layouts. There are two issues with modern keyboards that drive me crazy. One is the "menu" key introduced by Microsoft some time around Windows 95. Notice that I don't even mind the Windows logo keys that much. An additional modifier key is sometimes useful. Mac keyboards have three modifier keys on the bottom row, classic Unix keyboards often had them as well. I don't even care that it's the Windows logo, not some OS-agnostic symbol. But the "menu" key? What is it for? I don't think I've ever seen it used for anything. It's useless and it messes up the symmetry of the layout (three modifier keys on each side of the space bar). It also means the space bar is too short. So that's the first of my keyboard-related pet peeves. As you're about to see, I care about the second one much more deeply.

Numeric keypads. I hate them. I guess they're useful if you're an accountant and must input a lot of numbers into your spreadsheets. I'm not an accountant. I imagine to most people the numeric keypad is as useless as it is to me. The last time I remember using it is when we were playing Mortal Kombat fifteen years ago. So what, I hear you say. Just don't use it. But you see, it takes up space that I need for something else, namely the mouse. I need my keyboard positioned so that the monitor's symmetry axis goes between the G and H keys. That way my arms are positioned in a natural symmetric way when typing. That means that if my keyboard has a numeric keypad, the mouse goes too far to the right. I'm pretty sure it's not just annoying, but also not good for my posture.

What can we do about this sad state of affairs? Aren't there any good keyboards? Well, there are. Bad news is, they're not exactly cheap. I have two candidates for "the perfect keyboard". One is the space saving variant of the previously mentioned Model M:

In a lot of ways, it is the Holy Grail. An elegant weapon for a more civilized age. No numeric keypad, no stupid Windows keys. Built like a tank. Likely to outlive its user. There are downsides though. And I'm not even talking about the loud click, which is sure to drive your coworkers and roommates crazy. Problem is, the keyboard is long out of production and it is the less popular variant of the Model M. So when one of them shows up on eBay, it easily goes for more than 200 USD.

Is there no keyboard with all the right features that is still in production? As it happens, there is, the Realforce 86U:

As you can see, it has the Windows logo keys, but as I said, they don't bother me. What's important is that there's no "menu" key next to the right Control. And no numeric keypad of course. What's the catch? The keyboard might be in production, but it doesn't mean it's cheap. It currently goes for 265 USD on EliteKeyboards. Ouch.

I'm not aware of any cheaper keyboards that would match all my criteria (no menu key, no numeric keypad, standard full-size layout otherwise). If you're not ready to shell out two hundred bucks or more on a keyboard, you have to start making compromises. The one I'm probably willing to make is to accept the menu key. I still think it's extremely idiotic, but I guess I can live with it. If we allow the menu key, that opens up several possibilities in the 100-150 USD range. EliteKeyboards currently carries some nice keyboards from Leopold and Amazon has several Filco Majestouch keyboards to choose from. Both brands seem reasonable, but they're still a bit pricey. Like I said, most keyboard geeks obsess about the mechanical switches ("Cherry" switches in the case of Leopolds and Filcos) and they don't come cheap.

An important thing to know when looking for keyboards with no numeric keypad is that they're called "tenkeyless". Don't waste your time looking for "space saver" keyboards as they're almost always some ugly layouts that keep the numeric keypad, but drop the arrow keys/page up/page down area (a notable exception is the Model M mentioned above). I really don't understand the thinking behind such layouts. What I understand even less are the laptop keyboards with numeric keypads. And they are getting popular. I guess on 15-inch and bigger laptops there is enough space for extra keys, but why would you waste it on a numeric keypad and not, say, reasonable sized arrow keys and page up/page down etc. Another problem with such laptops is the already mentioned asymmetry. It's impossible to position your arms comfortably when typing, when the home row of the keyboard is shifted to the left (and obviously you can't reposition the laptop's keyboard in relation to the screen).

One day Logitech will make a nice, cheap, "tenkeyless" keyboard. But it probably won't be tomorrow, so what can you do in the mean time? Well, you can take inspiration from this guy, who shares my dislike for numeric keypads, take a keyboard that has a numeric keypad and... chop it off. It's what I did to a Logitech UltraX:

It turned out to be more difficult than I thought (the keyboard looks cheap, but there's a metal plate inside that I had to saw off) and it may not look pretty, but in the end I have a keyboard with a reasonable layout that didn't cost an arm and a leg. If you want to try it yourself, some instructions can be found on wikiHow. Obviously the details will depend on the exact keyboard model that you choose to lobotomize.

If you're considering becoming a keyboard otaku, I strongly recommend that you check out geekhack.org, they have an active forum and a wiki with more information on keyboard switches than a sane person needs.

Dominoes

noreply@blogger.com (Jacek Fedoryński) — Thu, 05 May 2011 22:14:00 +0000

A few years ago I was briefly interested in physics engines. Nothing ever came out of it, but I did make a few experiments. Here's one of them:

It uses the Bullet engine and I'm actually quite surprised that I bothered to make a relatively polished interface for placing the tiles. I was somewhat less surprised with the fact that it didn't compile after sitting on my hard drive for a few years. It turns out that there were some incompatible changes in Bullet since then, so I had to make a few modifications to make it run with recent versions.

If you want to play with it yourself, here's the code (be warned it's ugly inside, though).

Hippo Paint

noreply@blogger.com (Jacek Fedoryński) — Fri, 22 Apr 2011 15:00:00 +0000

My three year old niece likes to sit in front of Google Image Search and look at pictures of dinosaurs (and frankly, who doesn't?). Every once in a while there's a coloring book style picture and she wants to paint it. The best I could come up with on short notice was to print out the picture and give her crayons. But obviously there had to be a better way.

Enter Hippo Paint.

It should work in all modern browsers (it even works in IE9). While making this I could clearly see that JavaScript engines in browsers really are getting faster (for example there's a big difference between Firefox 3.6.x and 4.0), but you still have to make all the trivial optimizations like function inlining or common subexpression elimination by hand.

I also encountered an interesting bug that only manifested itself in Opera. I had a piece of code that looked something like this:

var img = new Image();
img.onload = function() { /* ... */ };
img.src = '...';

And sometimes the onload handler function wasn't getting called (even though I could see that the image was successfully fetched from the network). After a frustrating debugging session I noticed that it only happened when fetching the image took longer than usual (say, more than a second). It turns out that it gave Opera's garbage collector enough time to kick in and collect my img variable. I don't know if other browsers don't have as aggressive garbage collectors or if they think that the existence of an event handler is enough to mark the variable as still needed. Anyway, the solution was simply to move the variable to an outer scope.

I hope you and your kids have as much fun using Hippo Paint as I had making it.

Pivot screen fun

noreply@blogger.com (Jacek Fedoryński) — Wed, 30 Mar 2011 21:54:00 +0000

I used to think pivot monitors were only good for playing Pac-Man in portrait position. But why restrict ourselves to just the landscape and portrait positions?

Since the monitor only knows two states, I had to resort to a little trick. I attached my phone to the back of the monitor and wrote an application that broadcasts orientation data from the phone's accelerometer on the network. On the computer, another application receives the data and rotates the teapot accordingly. (Here's the source code to the phone application and the teapot application if you're interested.)

What I really wanted to do was to make the desktop rotate with all the windows. I think it should be possible with Compiz, but I'm pretty sure it would prove difficult enough for me to lose interest halfway through. So, a teapot for now.

Morse Code Reader

noreply@blogger.com (Jacek Fedoryński) — Thu, 17 Feb 2011 02:57:00 +0000

I wanted to make a Morse code reading application for some time now. Here's my first attempt, it listens to the signal through the phone's mic and translates it to text:

I'm sure there are all kinds of advanced signal processing techniques that I should be using, but for now I went with the simplest, most naive approach. And it sort of works, except when it doesn't. What I do is I keep an exponential moving average of the signal's volume and I decide that the signal is currently "high" when the average is above a threshold and "low" when it's below it. The threshold is set based on recent peak volume. Then I try to decide what the length of a dot and a dash is, interpret the input accordingly, and finally translate the dots and dashes to letters. The application adapts to changing volume and speed within reasonable limits (it should work up to about 40 WPM).

I was hesitant about putting the application on Android Market, as I only tested it on my phone and it quite often fails at translating Morse code. Then again, it's not like I have anything to lose by getting 1-star reviews and insulting comments, so why not.

Here's a Market link.

Page turner Mark II

noreply@blogger.com (Jacek Fedoryński) — Fri, 28 Jan 2011 02:48:00 +0000

I have improved my initial page turner design. Thanks to a third motor that repositions the rubber wheel between the left and right of the book, we can now turn pages in both directions!

The device is still manually operated and the problem of sometimes grabbing more than one page remains. But it is now less of a problem, because if we go a few pages too far, we can always go back.

Automatic page turner

noreply@blogger.com (Jacek Fedoryński) — Thu, 27 Jan 2011 01:43:00 +0000

Reading books is hard enough as it is. They're often long, boring and some don't even have any pictures in them. I decided to at least eliminate the physical effort of turning pages and constructed this little device:

At the moment it's not entirely automatic as I'm still controlling the individual motors manually (via Bluetooth from my phone, which is off-screen, because I'm also using it to shoot the video). The setup requires some tweaking for the exact size of the book and probably only works for a certain range of pages in the middle of the book. It also still sometimes grabs more than one page. But hey, it's a start. There's obviously room for improvement, for example it would be nice to be able to turn the pages in both directions.

NXT powered globe

noreply@blogger.com (Jacek Fedoryński) — Tue, 18 Jan 2011 03:36:00 +0000

OK, so this one isn't terribly sophisticated, but anyway. I attached an NXT motor to a globe:

Here it is in motion (apologies for the low quality, I had to jump through some hoops to shoot video and control the Mindstorms brick from my phone at the same time):

NXT Remote Control

noreply@blogger.com (Jacek Fedoryński) — Fri, 12 Nov 2010 22:08:00 +0000

Two of my favorite toys right now are my Lego Mindstorms set and my Android phone. And thanks to the Bluetooth protocol I've found a way to combine them. Behold!

Since the video is quite blurry, here's a better view of the application's interface:

The third control scheme (not pictured), which I like to call the tank mode, allows you to control each motor separately and works best if your phone has true multitouch support (not just pinch-to-zoom).

Now I'm not saying my application is very unique, there are at least two others on the Android Market that do the same, including an official one from Lego. But hey, it's mine!

If you'd like to try it, below is a QR code that you can scan from your phone (or if you're reading this on your phone, just tap the code). And here's the application's AppBrain page. (It's free of course.)

Finally if you'd like to see the source code, it's over here at Google Code.

Paper clip spinning top

noreply@blogger.com (Jacek Fedoryński) — Sat, 23 Oct 2010 02:53:00 +0000

Today I'm going to show you how to make a spinning top from a paper clip. If you have a three year old niece or nephew, this is a trick you must learn.

You're going to need a paper clip and a pair of pliers. Also some cylindrical object is helpful, but not strictly necessary (I used a screwdriver handle). The paper clip can be any size, I used the bigger kind for demonstration, but the smaller ones work, too.

Supposedly the angle between the spokes must be 53 degrees for the center of gravity to be on the axis, but in my experience any roughly pac-man-like shape works. With a bit of tweaking you should get a top that spins for at least 30 seconds on a reasonably smooth surface.

Panoramic Quake 3

noreply@blogger.com (Jacek Fedoryński) — Sat, 09 Oct 2010 22:55:00 +0000

Running Google Earth on five screens is pretty cool, but we all know that the real test for any computer system is whether it can run Quake. Today I'm going to show you how to run Quake III Arena in a panoramic multiple screen configuration. Here's what my setup looks like:

And here's a video of me playing with some bots:

How do you make it work like that?

It turns out that it's actually easier than it seems, as Quake 3 already includes the view synchronization functionality, because it's needed for spectators. The only thing that we need in addition to that is a way to rotate the view a little to the left or to the right. This simple patch does exactly that, introducing a new console variable named cg_yawOffset.

You're going to need:

five monitors and five computers (or some other number)
a working copy of ioquake3 on each of them
my mod

(Technically, you don't need a separate machine for each screen, you could drive two or more screens from the same computer if you figure out how to make one instance of Quake 3 run in fullscreen on one monitor and another one on the other. Also, there's nothing ioquake3-specific about my mod, it's just that I used ioquake3 to compile it, so it uses the new QVM format, which doesn't work with vanilla Quake 3. If you want to make it work with vanilla Quake 3, you'll have to take my patch and compile it yourself.)

Unzip my mod and put the galaxy directory in your ioquake3 directory (it has to be on the same level as the baseq3 directory). Do it on every computer. The mod consists of QVM files and not native code, so it's platform independent and can't hurt your computer, so don't worry.

For simplicity I'm going to assume that you're going to play using the computer connected to the screen in the center, even though it doesn't have to be that way. The server is also going to run on it. On that computer, run ioquake3 with the following command line parameters:

+set fs_game galaxy +set sv_pure 0 +devmap q3dm7

(You can use some other map if you like.)

On the rest of the machines, just run ioquake3 as you normally would. Then connect to the server, either by typing \connect server_ip in the console (you'll have to know the server's IP address) or from the menu. Then become a spectator, by typing \team s in the console or from the menu (press Esc, choose start, then spectate). Then click the left mouse button (or whatever you have bound to +attack) until you're following the player from the master computer (center screen). All your screens should now be displaying the same view.

Time for the real magic. On each computer, type \cg_fov 45 in the console to set the field of view (use a number that matches the geometry of your setup, 45 degrees is what I used). Then on the first computer to the left of the master, type \cg_yawOffset 45. That will rotate the view 45 degrees to the left (if you used something other than 45 degrees for the FOV, use the same number here). On the second computer to the left, type \cg_yawOffset 90 and on the computers to the right, type \cg_yawOffset -45 and \cg_yawOffset -90. You should now have a nice panoramic Quake 3 configuration. Move around and see if everything works as it should.

You'll also want to disable the gun and the HUD on all screens except the master. To do that, type \cg_drawGun 0 and \cg_draw2D 0 in the console.

Oh, and by the way, if you don't have the full version of Quake 3, all of this works fine with the pak0.pk3 from the demo.

My ghetto Liquid Galaxy setup

noreply@blogger.com (Jacek Fedoryński) — Fri, 01 Oct 2010 17:53:00 +0000

Yesterday Google has published instructions on how to recreate their Liquid Galaxy immersive environment for Google Earth. Naturally I had to try it immediately. Unfortunately I don't have access to eight 55-inch monitors, so my setup is not quite as impressive as Google's, but still very neat:

Here it is in action:

Line Following Robot

noreply@blogger.com (Jacek Fedoryński) — Fri, 20 Aug 2010 17:09:00 +0000

Everyone with a Lego Mindstorms set must at some point build a line following robot. Here's mine.

The trick to following a line when all you have is one light sensor is that you don't follow the line, you follow the line's right (or left) edge. You try to stay exactly on the border between the dark area and the light area. The light sensor reports shades of gray when it passes from black to white. You choose a value that you think corresponds to the edge and then when the sensor reports a value brighter than the threshold value, you turn left, and when it reports a value darker than the threshold value, you turn right (assuming you chose to follow the right edge of a black line).

For smooth movement we don't just turn left when the value from the sensor is greater than the chosen threshold. Since the data we get is not binary, we can make the robot turn sharper when we think it's off the line entirely and only adjust its course slightly when we think it has left the edge of the line, but by just a little.

Here's the NXC program that the robot is running. It's heavily inspired by the NXT-G program of this robot. I initially used OnFwdSync(OUT_BC, ...) to turn the robot, but it sometimes resulted in very jerky movement. When trying to figure out whether it's a problem with my hardware or software I looked at that robot's program and saw that they control each motor independently. When I replaced calls to OnFwdSync(OUT_BC, ...) with OutFwd(OUT_B, ...) and OutFwd(OUT_C, ...) (with power values based on whether we think we should be turning right or left), the jerkiness problem was solved.

I also used their idea of calibrating the sensor at the beginning (the robot rotates a bit to the left and then to the right, noting the maximum and minimum light levels and chooses the threshold value as the average of the two).

You will note that I used a faster version of the program for the NXT Test Pad and a slower version for following the line that I made on the floor with electrical tape. I had to do this because the robot kept losing the line (probably because the tape was too narrow, it was also blue, not black, and some of the turns I made may have been too sharp).

Music Tape Player

noreply@blogger.com (Jacek Fedoryński) — Tue, 17 Aug 2010 16:54:00 +0000

My second NXT creation is a music player that uses the color sensor to read notes from tape.

The notes are encoded using colors. I considered using shades of gray and then using the color sensor in light level mode to read them, but that would require calibration (as the readouts would be dependent on current light conditions in the room) and possibly wouldn't allow for more than 5 or 6 well-distinguishable levels anyway.

Here's the NXC program that the device is running. As you can see it constantly reads the color sensor and adjusts the sound accordingly. Another way of doing this would be to only read the color at certain intervals, which would eliminate the problem that sometimes occurs when the color sensor gets confused during the transition between one color and another. But the current approach has the nice feature that we can have notes of arbitrary lengths (by simply putting a wider or less wide stripe of color on the tape). It also doesn't require any synchronization.

Possible improvements might include:

an encoding scheme that would allow for more than five notes
a mechanism for stopping the tape at the end
a rewinding mechanism
a better tune for demonstration

Sonar

noreply@blogger.com (Jacek Fedoryński) — Thu, 12 Aug 2010 17:29:00 +0000

This is my first Mindstorms robot. It rotates around the vertical axis while gathering data from the ultrasonic sensor. Every time it makes a full circle it plots the gathered data on the display. The results are mixed.

Can you guess what the red ball is for?

OK, so the red ball is there so that the robot knows it made a full circle. You can see that the color sensor rotates with the rest of the robot while the ball remains still.

Here's the source code for the program that the robot is running.

Hello

noreply@blogger.com (Jacek Fedoryński) — Thu, 12 Aug 2010 16:59:00 +0000

Yeah, hi. This is my blog.