berrycraft-promo

BerryCraft

BerryCraft, the Blackberry Minecraft chat client, allows you to chat in-game with your Minecraft buddies on the go, or administer your Minecraft server using standard commands.  Source also available for developers! More »

synthnetpromo

SynthNet

A (very) ongoing science project – the ultimate goal: a neural and genetic emulator, capable of growing fully functional, and biologically accurate, neural networks from virtual DNA. Phase 1, growing a neural network from virtual DNA, capable of associative learning and long-term potentiation, is now complete! More »

bbgamepromo

Creating a Blackberry Game

Java programmers, get your Blackberry out and start making games! This set of tutorials goes over creating a Blackberry game from start to finish by following the development of the Galactic Blast Demo, available at Synthetic Dreams. More »

shredz64promo

Shredz64

A new game for the Commodore 64 based on Guitar Hero. By making use of the PSX64 interface, players are able to connect a Playstation Guitar controller to their C64 and play a favorite modern genre of game on their beloved classic computer. More »

Authenticated Minecraft Logins Working for BerryCraft

A quick update – a lot of people had shown interest in BerryCraft – the Blackberry Minecraft admin/chat client I’d been working on.  It was a bit of a hack before and didn’t work with servers that required Minecraft.net authentication, so I wanted to fix it up before starting to release it out.   Tonight I successfully got the authenticated logins working.  I want to clean it up a bit more, and then stat releasing it in iterations.  The first will be mainly just a chat client, since that’s pretty much implemented.  Then we’ll see about inventory management and some other goodies if things work out well.

Quick Shoutout – ArtificialBrains.com

James Pearn at artificialbrains.com was nice enough to include SynthNet in his list of resources related to artificial intelligence.  Check out his site if you get a moment, it serves as a well laid-out directory of many neural network and other artificial intelligence projects going on around the world, as well as job listings.  Very cool site – thanks James!

 

Hardware Monitoring: Syncing Drupal with Zenoss

Overview

One of the more daunting tasks of managing a larger network is keeping track of all your devices – both physically, and from a network monitoring perspective.  When I arrived on the job 3 years ago, the first major task I laid down for myself was implementing both an asset management system, as well as a network monitoring system, to ensure we always knew what we had, and if it was functioning properly.

I decided almost immediately that Drupal was the right candidate for the job of asset management.  There are a number of commercial IT/helpdesk systems out there which work great, but they are usually fairly expensive with recurring licensing costs, and my history with them has always been shaky.  Plus, I find myself not always using all the functionality I paid for.  I knew with my Drupal experience, I could get something comparable up in almost no time – this is not a discredit to IT packages, but moreso the power of the Drupal framework.

Network Monitoring – Cue Zenoss

Now that I had the hardware DB taken care of, I needed a NMS for monitoring.  Originally I was planning on Nagios, but a contractor who works for us (now friend) had introduced me to Zenoss, another open source alternative.  Zenoss is awesome – is absolutely has its quirks, and is not the most intuitive system to learn, but once things are up and running it’s great – and tremendously powerful.  So the choice was made.

Now – I had both pieces, but I absolutely hate entering data twice, and the interoperability guy in me loves integrating systems.  So I decided to write a script that would sync our Drupal database with Zenoss.  Drupal would serve as our master system, and any hardware we entered into it would automatically port over to Zenoss.  Any changes or deletions we made (IP address, location, name, etc) would sync over as well.

The below script performs this synchronization.  Some warnings up front – I’m not a Python guy by any means, I specifically learned it for this script, so I apologize for any slopping coding or obvious Python-y mistakes.  I’ve tried to thoroughly comment it to document how to use it and how it works.  Hopefully it can help some others out as well!

# Description: Sync devices to be monitored from Drupal to Zenoss
#
# Setup Work: Create a (or use an existing) content type that houses your hardware items to be monitored.
# They should have CCK fields for the IP address of the device, the name, and the type of
# device it is. The device type will determine the Zenoss class the script adds it to, and hence
# the kind of monitoring it will receive (e.g. Linux server, switch, ping only, etc)
#
# Additionally, in Zenoss, create a custom property field that will house the nid of the Drupal
# node. This serves as the foreign key and will be used to link the item in Drupal to its entry in Zenoss
#
# Usage: This script should be run from zendmd, and may be run once or periodically. We run it every 20 minutes from
# a cron job.
# It will create new entries in Zenoss for items not yet imported, delete ones that no longer exist in
# Drupal (it will only delete ones that were originally imported from Drupal), and will update ones that have
# been updated (type, IP, location, etc).
#
# Note: Excuse all the extra commits - we experienced some issues with data not being saved, and I threw some extra in
# there - they're almost definitely not necessaryimport MySQLdb

# Take a taxonomy term from Drupal identifying the type of monitoring to be done,
# and convert it to the appropriate Zenoss class path. Update these to whatever terms
# and Zenoss class paths that make sense for your environment. We setup ones for
# Linux and Windows servers, switches, waps, UPSes, PDUes, etc, as can be seen.
def getClassPath(passType):

if passType.lower() == "windows":
return "/Server/Windows"
elif passType.lower() == "linux":
return "/Server/Linux"
elif passType.lower() == "switch":
return "/Network/Switch"
elif passType.lower() == "mwap":
return "/Network/WAP/Managed"
elif passType.lower() == "uwap":
return "/Network/WAP/Unmanaged"
elif passType.lower() == "ups":
return "/Power/UPS"
elif passType.lower() == "pdu":
return "/Power/PDU"
elif passType.lower() == "camera":
return "/Camera"
elif passType.lower() == "cphone":
return "/Network/Telephone/Crash"
elif passType.lower() == "sphone":
return "/Network/Telephone/Standard"
elif passType.lower() == "printer":
return "/Printer"
elif passType.lower() == "converter":
return "/Network/Converter"
elif passType.lower() == "ping":
return "/Ping"
return "/Ping"

# Connect to Drupal's MySQL DB (Replace these values with the appropriate ones for your system)
imsConn = MySQLdb.connect(DRUPAL_MYSQL_SERVER, MYSQL_USER, MYSQL_PASSWORD, MYSQL_DB)
imsCursor = imsConn.cursor()

# Execute the query to grab all your items to be monitored. In our case, we have a node type called "hardware" that had CCK fields identifying the IP address,
# the type of hardware (a taxonomy term that dictated the Zenoss class of the item - see getClassPath above), a physical location, etc.
# You'll want to change the specific table/field names, but the inner join will probably stay, as you'll want to grab both the node and CCK fields that belong to it.
imsCursor.execute("""
SELECT node.nid, content_type_hardware.field_hardware_dns_value, content_type_hardware.field_hardware_location_value, content_type_hardware.field_hardware_ip_value, content_type_hardware.field_hardware_monitor_type_value, content_type_hardware.field_hardware_switchname_value, content_type_hardware.field_hardware_switchport_value
FROM node
INNER JOIN content_type_hardware ON node.nid = content_type_hardware.nid
""")

# Loop through all returned records - Check for additions, changes, and removals
while (1):
#tempRow is our current hardware item record
tempRow = imsCursor.fetchone()
if tempRow == None:
# No more entries, break out of loop
break
else:
# Search Zenoss records for the nid of the hardware item. A custom field will need to be created in Zenoss to serve
# as this foreign key. In our case, we used MHTIMSID - but you can use anything you'd like - just be sure to create the field in Zenoss.
found = False
for d in dmd.Devices.getSubDevices():
if d.cMHTIMSID != "":
if int(d.cMHTIMSID) == tempRow[0]:
found = True
break

if found == False:
# Hardware item not found, add it if it's monitored
if tempRow[4] != None:
dmd.DeviceLoader.loadDevice(("%s.yourdomain.com" % tempRow[1]).lower(), getClassPath(tempRow[4]),
"", "", # tag="", serialNumber="",
"", "", "", # zSnmpCommunity="", zSnmpPort=161, zSnmpVer=None,
"", 1000, "%s (%s - %s)" % (tempRow[2], tempRow[5], tempRow[6]), # rackSlot=0, productionState=1000, comments="",
"", "", # hwManufacturer="", hwProductName="" (neither or both),
"", "", # osManufacturer="", osProductName="" (neither or both).
"", "", "", #locationPath="",groupPaths=[],systemPaths=[],
"localhost", # performanceMonitor="localhost',
"none")
tempDevice = find(("%s.yourdomain.com" % tempRow[1]).lower())
tempDevice.setManageIp(tempRow[3])
commit()
# Save nid to Zenoss record (to serve as foreign key) for syncing
tempDevice._setProperty("cMHTIMSID","MHTIMS ID","string")
tempDevice.cMHTIMSID = tempRow[0];
commit()
else:
# Hardware item found - delete, update, or do nothing
if tempRow[4] == None:
# Delete if not set to monitor
dmd.Devices.removeDevices(d.id)
else:
# Update DNS and IP to current values
if d.getDeviceName() != ("%s.yourdomain.com" % tempRow[1]).lower():
d.renameDevice(("%s.yourdomain.com" % tempRow[1]).lower())
if d.getManageIp() != tempRow[3]:
d.setManageIp(tempRow[3])
commit()

# Change class if not set to "Manual" (We setup a taxonomy term called "Manual" that would turn off automatic Zenoss class selection during syncing
# and allow us to manually specificy the class of the device.
if tempRow[4] != "Manual":
d.changeDeviceClass(getClassPath(tempRow[4]))
commit()

# Update comments (location change)
d.comments = "%s (%s - %s)" % (tempRow[2], tempRow[5], tempRow[6])
commit()

# Save any missed changes
commit()

# Close connection to database
imsCursor.close()
imsConn.close()

Watch SynthNet in Action!

In case you haven’t seen yet, the videos demonstrating SynthNet in action have been posted to YouTube!  In the first clip, I demonstrate growing a brain from virtual DNA, hooking into my Lego robotic buddy Bit, and then conditioning Bit to associate hearing a tone with getting his touch sensor pressed.  The demonstration is a recreation of classic fear conditioning experiments.

In the second clip, I give an explanation of how SynthNet functions, how the demonstration above was setup, and the future of the project.

Thanks for checking them out!

 

Site Makeover

After finishing up phase 1 of SynthNet, I came to the conclusion that I really missed updating the blog.  When I get involved in a project, I tend to get wrapped up in it (more accurately – completely and ridiculously obsessed where it takes over my life) and other things drop off the radar.  However, I’ve decided I want to make a real effort to not get AS wrapped up in projects, and remember to give the blog some love.

New and Improved!

As I went to write my first article after recording the SynthNet video, I also noticed the blog was looking a little tired.  They’d also made a number of improvements in WordPress since when I first installed everything, so I decided to take the leap, get a shiny new template, and put some new life into it.  I think it’s definitely an improvement – hope you enjoy it!

 

fMRI of Bit “Hearing” My Voice

This is what an fMRI of Bit’s (current) brain looks like while listening to my voice (red is active neural structures – it indicates a higher membrane potential). This will probably be the last picture before the video of the associative learning demonstration – I think I’ll be ready to record by Sunday night (hopefully). Exciting stuff!

Auditory Processing – Virtual Cochlea

Before Bit can hear like humans do, I needed to make a “virtual cochlea” – a piece of software that would take auditory input from a microphone, convert it into frequencies (like the hairs in your cochlea do), and send the data into Bit’s peripheral nervous system. I got most of it done tonight – I made a real-time graphing system as well. On the left, you can see the waveform data coming off the microphone (top is a straight tone coming off my KORG, and bottom is me talking), and to the right is the data run through a Fast Fourier Transform to convert the time-based waveform data into a frequency based distribution. This can then be sent directly into a neural nucleus in Bit’s brain via the TCP nervous system.

Increasing Network Complexity – Oscillating Neurons

As you can see from the membrane potential graph (lower left hand corner), I injected some current into this genetically grown virtual neuron (over a TCP connection), and it started keeping a steady pulse on its own – still going after 15 minutes!

Start of Multithreading Capabilities

Since the genetic engine is pretty much finished up now, I’ve started on some loose ends of things I want to implement in SynthNet. This is a stress test for the (start of the) new multithreading capabilities – using a simple strand of DNA to direct a base stem cell to continually go through mitosis and differentiate. These daughter cells then follow a genetically programmed spiraling migration path. You can see patterns start to emerge amongst the thousands of cells.

Some parts of the processing engine are crashing out right now, so it’s apparent I’m having some kind of issues arising from sharing information between threads – I’m going to shelve the functionality for now and then complete it up after the end of phase 1 – there may be quite a bit involved.

Mitosis and Differentiation Complete

After about 8 hours of programming, I got mitosis and stem cell differentiation working in the genetic engine yesterday. Pictured is a 1840 neuron columnar nucleus, grown in a linear fashion initially, then radiating outward via differentiating mitosis. SynthNet is now able to regulate growth (so it isn’t cancerous), as well as direct growth based on protein signaling markers, allowing it to grow differentiated structures.