Oct 032013
 

[EDIT] Please check out the newest version of the FX Code (v0.51) with Android Bluetooth Control App and Chrome Control Extension.

[EDIT] Fixed a really dumb problem in the Arduino code, added a color picker to the python GUI, and uploaded a new video demo. The problem was I was using if (serial.available()) and should have been using while. That gummed up the works and made the LEDs flicker if you moved the sliders too fast. That’s fixed now. Should have waited and tested better but I was all excited to get this posted- live and learn, or more likely just repeat the same mistakes and correct myself as I go along.

Here’s another revision to the FastSPI2 effects demo code. Some code cleanups, a few new effects, and a python GUI (gtk). GUI can select effect by name and control brightness, delay, color-step, hue, and saturation of various effects.

Screenshot from 2013-10-03 19:52:46

Here’s the Arduino Code

Here’s the Python Code

 

If you find this really useful, please consider donating a little to the cause. Thanks!

[paypal-donation reference=”FastSPI2 LED FX Code”]

I’m also grateful for bitcoin donations to: 1K5Yy77ejes2FZrHBG5fns3QAicnwZcduq

Sep 212013
 

[EDIT] Please check out the newest version of the FX Code (v0.51) with Android Bluetooth Control App and Chrome Control Extension.

[EDIT] Revised once again, and made a python GUI. See this new post.

This is a revision of the original FastSPI LED Effects Examples I wrote awhile back.

LED_POST

I’ve gotten some very positive responses for these examples so I figured I should update them to be a little less clunky (the operative term here being ‘less’, they’re still quite clunky) This revision will work with RC3 of the FastSPI2 Library.

http://youtu.be/5c6vYoZInjw

These are little LED displays I made, one is a circular back-light and the other a wave shape with a little diffusion in front. Both are Arduino powered of course. I just ran the ‘demo mode’ on both and tried to start at the same time so they’re not in sync or anything. Just thought I’d show them on a couple of different configurations for the heck of it.

If you have any issues getting this to work please check through the comments on the original post page first. A lot of people have posted very helpful comments about their experience using the code that might help you on your way. And of course feel free to post your issue if you can’t find a solution- I’ll do what I can to help.

Most significantly I’ve removed the need for the SerialCommand library and the really hacky HSV->RGB conversion function in favor of the native FastSPI2 conversion which is much faster and cleaner and supports ‘rainbow’ and ‘spectrum’ modes (though for these examples I just stuck to ‘rainbow’.)

I also added one example of a ‘native’ FastSPI effect; the fill_rainbow function (new_rainbow_loop – mode 88). This is similar to the ‘rainbow_loop’ function except that is fades the colors into one another much better. I’ll add more ‘native’ effects functions like fades to the code later because they are much faster and have nicer aesthetic qualities than mine.

Change modes the same way as in the previous code, enter ‘m’ and then an integer for the mode number (listed in code). Also make sure you send a NEWLINE character. Mode 888 is ‘demo mode’ which cycles through all the modes, but this tends to block the next serial command.

Also you can change the maximum brightness with ‘b’ and then an integer from 0-255. By default it’s set to 64, about 1/4 brightness.

Here is the code.

[EDIT] I recently fixed a few issues where I messed up the HSV conversion and I utilized a few more of the FastSPI2 functions. Also finally started giving the code a version number. This one’s v0.3, I’ll do better with that in the future.

Most notably I added the ability to adjust parameters of many of the effects via serial commands. The following commands are now accepted:

(d)elay 0-INF | d50 | Adjusts the delay value, effects run faster or slower.

(s)tep 0-INF | s5 | Adjusts the steps between colors, mostly for rainbow effects.

(h)hue 0-255 | h180 | Adjusts the hue of effect, mostly for one and two color effects.

sa(t)uration 0-255 | s50 | Adjusts the saturation of effect, mostly for one and two color effects.

Here is the code. (v0.3)

If you have any requests feel free to ask, I’ll see what I can do! I’m more-or-less open for business if you have anything in particular you need tackled. And if you find these very useful, please consider donating a little via. paypal, I’d really appreciate it 🙂

[paypal-donation reference=”FastSPI2 LED FX Code”]

I’m also grateful for bitcoin donations to: 1K5Yy77ejes2FZrHBG5fns3QAicnwZcduq

Sep 152013
 

funkboxing-the t-shirt, funkboxing-the coloring book, funkboxing-the lunch box, funkboxing- the breakfast cereal, funkboxing- the flame thrower (the kids love this one).

Now instead of just reading, listening, and looking at things on funkboxing, you can also have some funkboxing stuff of your very own. Here’s a bunch of stuff available at the funkboxing Zazzle Store. CafePress Store coming soon.



Sep 142013
 

Aim the camera at the floor, set for a long-exposure, turn off the lights and shine some lasers through textured glass…

Jul 252013
 

This is an evolution of a concept I had for an ‘info-hydrant’ device that would preserve and proliferate information and knowledge in the event of catastrophic loss of technology, communication, and historical information about humanity and nature.

INVENTION - Speaking Stone

GOAL:

An inexpensive, accessible and easily replicated device that would serve as a repository of information. This device must outlast several human lifetimes, withstand elements and most casual attempts at theft and destruction. The device must be exceedingly simple to use, to the extent that a person with absolutely no knowledge of the device may be reasonably expected to discover it’s function.

PURPOSE/MOTIVATION:

There is a strong chance that some population of human beings will survive catastrophe. There is less chance that deep human knowledge about science, nature, and history will survive the same event. A speaking stone will provide the basis for rapid rebuilding of civilization in the event that communication and information are lost.

The motivation for this can be stated most succinctly in the words of Dian Fossey “When you realize the value of all life, you dwell less on what is past and concentrate more on the preservation of the future.”

CHALLENGES:

Language. This wholly relies on the idea that the language used in the device will be understood by the user. There is no guarantee for this. Essentially I’ve chosen to overlook this challenge and suggest the use of English and hoping that remains a dominant language form into the future. Alternative suggestions on this are welcomed.

Degradation/Theft/Vandalism. There is a possibility these devices will be destroyed by nature, theft, or vandalism. There is no fail-safe against this except by making these devices as physically difficult to destroy as possible, and by proliferating them as far and wide as possible. Another safety would be to encase the electronics in such a way that they cannot be accessed without destroying them. Additionally the value of the contents should be kept as low as possible to discourage attempts.

IMPLEMENTATION:

POWER: Thermo-Electric (Peltier) tiles placed just below the surface of the stone, with one side attached to heat sinks or pipes that run deeper into the core of the stone. The thermal gradient will allow a small array of these tiles to generate enough power (3-5W) to run the electronics.

ELECTRONICS: A Raspberry Pi or similar low power, single board computer could serve as a reliable and inexpensive controller and memory storage. A piezo transducer and possibly a small amplifier will be attached to the audio. In addition, the Raspberry Pi can be used as a simple FM transmitter with no more than a wire as an antennae.

SOFTWARE: Any OS could used, Debian would be fine. A text-to-speech synthesizer program should be installed. Storing information in text format and synthesizing audio will allow vastly more information to be stored than if audio formats were used. RISC OS is another option for the OS and may have more desirable characteristics.

INFORMATION STORED: This requires some thought and I don’t think any one person should decide what information is critical enough to preserve. I’ll leave this open for discussion. I would suggest storing mainly information on science and nature.

So that’s my spiel… This concept is clearly in the ‘alpha’ development stage and I’m open and eager for discussion and suggestion on all points. I hope I’ve presented this in a way that it makes sense, if not, open to suggestions on how to do that better too.

May 042013
 

2013-04-28_14-33-36_511k

Just posting this to help anyone else who might have gotten the same weird-ass breakout on their Nokia5110 and are trying to connect it to their Raspberry Pi.

Got it here:

http://dx.com/p/arduino-1-6-lcd-display-screen-for-nokia-5110-red-silver-140226

I found the most helpful info in this post

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=9814&p=264142

And here are the pin assignments that finally worked.

NOKIA                       RASPI-GPIO (colors are for reference with the picture)

1-VCC|VCC              PIN01 – Power-WHITE
2-GND|GND              PIN06 – Ground-BLACK
3-SCE|CE                  PIN24 – Chip Enable-GRAY
4-RST|RST                PIN11 – Reset-PURPLE
5-D/C|DC                   PIN15 – Data/Command-BLUE
6-DNK(MOSI)|DIN  PIN19 – Serial Input-GREEN
7-SCLK|CLK             PIN23 – Clock Input-YELLOW
8-LED|LIGHT            PIN12 – LED Backlight-ORANGE

May 032013
 
This is/was Dominar Rygel XVI
Rygelz
Dominar Rygel XVI has had a tumultuous development cycle. I purchased the basic platform and servos with the idea that I would create a semi-autonomous robot capable of SLAM and Face Recognition running Raspberry Pi and Arduino. Well that may still happen, but I ran into some limitations on the Raspberry that I can’t get past yet. Just to be clear- no complaints about the Pi, I just didn’t spec out my hardware well enough (or at all really) before I started piling tasks onto it.
There’s a good chance I’ll be harvesting some of Rygel’s current parts for another project soon so I wanted to get his pretty mug up online because why not.
PARTS:
(1) Arduino Duemelinova
(1) Raspberry Pi (Model B – 512Mb RAM – Raspian Distro)
(4) Parallax Continous Rotation Servos
(2) HCSR04 Ultrasonic Rangefinders (one pan/tilts with camera, one pointed at 45degrees down to detect changes in ground level.
(1) Gyro (not implemented yet, originally he had a 6DOF but I pulled that to use on Tweedle and ordered and 9DOF sensor for Rygel
(2) 9g Hobby Servos (pan/tilt camera)
(1) Webcam
(USB 4 port Hub, USB Battery pack, and a little speaker)
I got pretty far in understanding R.O.S. Groovy and even wrote a couple of message types and nodes and they worked. In the future I think R.O.S. will be a very powerful tool and I’m glad I got some exposure to it already. Just turned out the Pi didn’t have the juice to run R.O.S. with all the bells and whistles I wanted. Next time I’ll start with a more powerful processor.
Apr 102013
 

I would like to introduce:

Stanley Tweedle – Captain of the Lexx.
Formerly Security Guard Class 4 for His Divine Shadow, and Assistant Deputy Backup Courier for the Austral B Heretics.

2013-04-05_16-43-58_5892013-03-16_16-51-29_671

I have a new project that will have to borrow time from my robot stuff for a bit, so I wanted to go ahead and post what
I’ve done so far, mostly for my own reference when I go to pick this up again.

PARTS:
(1) Arduino Nano
(2) 9g Continuous Rotation Hobby Servo
(1) Ultrasonic Rangefinder
(1) 6DOF Acc/Gyro
(1) USB 5V Battery
(3) WS2811 LEDs
(1) Bluetooth chip

Tweedle is complete hardware wise, but I have a little more coding to do before I’m satisfied with his brains. I ran out
of space in the Nano for anything other than input/output so all the control is done from a remote PC via python over
bluetooth/serial. I also made a wiimote script to control him manually. His brains is just basic obstacle avoidance right
now, still trying to see how much nav/odom info I can derive from a 6DOF sensor. Dead reckoning would result in massive
error accumulation, so for right now it just tells him orientation.
Anyway I’m pretty happy with how he’s turned out so far and he’s been a lot of fun. I’m usually not concerned with
aesthetics of these kind of things but I think he’s kinda cute.

This probably won’t help anyone because if you’re deep enough in your a project to understand my code- you’re deep enough
to write it yourself probably faster than it would take to adapt mine to your project… but here is is anyway.

Tweedle Arduino Sketch
Python Ncurses Control Program
Python WiiMote Teleop Program (NOT WORKING)
DOWNLOAD

And here’s some more pics of the wiring…

z2013-09-14_11-34-50_778 z2013-09-14_11-35-19_156 z2013-09-14_11-35-28_663 z2013-09-14_11-36-24_726 z2013-09-14_11-36-40_360