Music via midi?

Maybe I have added too many things that I am interested in pursuing with the RPis in my possession. However in one of the conversations with people that I work with, I now have become interested I working with the RPi in developing some midi applications, or at least using some already developed applications on the RPi.  I do posses some vintage midi gear that would come in handy here.  I have a DW8000 synthesizer, a Ground Control midi foot controller, a GMan sound module, a SQD-8 midi recorder, a TR-505 drum machine, a smaller midi controller keyboard, and a TR-1 midi thru repeater plus assorted midi cables to make it all work together.  Anyway, this shows that I have made some investment in midi gear and probably means that I should try and resurrect my keyboard abilities which if I remember correctly were sadly lacking back in the day.

I also have some midi related apps on my iPad which could be useful.  I already have a handle on the use of some Linux based midi applications including Jack and some decent sequencers.  I need to figure this one out.  Then again, maybe I should just stick to what I have been planning with the robot.

Maybe a pitch to midi converter via the RPi?  That would be an interesting use of the RPi technology.  Then you could use the RPi to interface to a guitar and play it through a midi setup or sound module. It would only take some fancy FFT processing and some comb filtering to accomplish.  Off turnings could be a problem though.

Project #7 - Add a TOR Gateway to the Network

As part of experimentation throughout the network, I would like to add a TOR gateway on a Raspberry Pi to push information over the TOR network.

Figured out how to make a set of tagged vlans from the Mac Mini

I was successful in determining how to set up the connection between two managed switches in my network to be a trunk with multiple tagged vlans.  I thought it might be nice to figure out how to have a trunk from my Mac Mini to one of my managed switches with the same capability.  I did determine how to add a port connection to a different vlan from the Mac via a USB to Ethernet adapter.  I decided to take the idea one step further and get a Thunderbolt to Gigabit Ethernet adapter for the purpose of getting the most speed out of the trunk line.  I plugged the adapter into Mac and fed an ethernet cable from the closest managed switch.  I then gave the adapter a fixed ip address in the home network range (same as the Mac); to have an ip address when the trunk cable is then limited to just tagged packets.  I created some VLAN Adapters on the network tool by running System Preferences -> Network, selecting the starred button on the bottom of the interface list and selecting "Manage Virtual Interfaces".  On each of these vlans I added a connection to the new adapter, selected DHCP, and set the vlan ID.  On the managed switch, at the port that my adapter was connected to, I selected the PVID line to be "VLAN only"; that makes sure that only tagged vlan packets are passed on.

In order to test this combination, I took one of the VMs that I had previously connected to the USB-Ethernet adapter and changed the bridge interface to connect to one of these new VLAN Adapters, with the same vlan ID as the USB-Ethernet adapter vlan ID.  I rebooted the VM and checked the ip that the VM had obtained.  It came back with the previous subnet that it was connected to and the same ip on that subnet (my third router remembers).  Once I was sure that the VLAN Adapter was working correctly, I moved all of the other VMs to that VLAN Adapter.  Now I have the same circuit setup as before, only this time I can reuse the trunk cable for additional tagged vlan traffic.

My next trick will be to setup a VM based router to allow traffic between vlans via the VLAN Adapters.

Starting to think about the IMU stick sensor

The Inertial Measurement Unit that I purchased some time ago, has a gyro, an accelerometer, a magnetometer, and a barometric pressure sensor.

I was originally thinking of using it to place onto my iRobot Create to form the basis for determining position.  Past that point, I haven't really given this that much thought.  As I am doing some research on how to use the thing, I am starting to realize that there is much that I do not know about how to use it.  There are many articles on correcting the drift errors apparent from each of these devices.  Never mind that I haven't put together an I2C interface so that I can check it out. In order to get distances from the accelerometer, you will need to do double integrations which are subject to drift in and of themselves. Some of the more interesting articles include:

• http://www.varesano.net/blog/fabio/simple-gravity-compensation-9-dom-imus which shows a gravity compensation for the accelerometer.  Mentioned in this article was the use of Quaternions, which minimize the accumulated round-off error of normal digital calculations.
• http://theboredengineers.com/2012/05/the-quadcopter-basics/ and http://theboredengineers.com/2012/09/the-quadcopter-get-its-orientation-from-sensors/ which outline how to get orientation (pitch, roll, and yaw) from the various sensors.  This article is in reference to some basic elements of getting a quad-copter up and running.
• http://www.x-io.co.uk/node/8 contains a fusion filter discussion.
• http://www.starlino.com/imu_guide.html and http://www.starlino.com/imu_kalman_arduino.html contain some additional information about the use of accelerometers and gyros together to measure distance.

It would appear from the above that I should change the way that the measurement - calculation stream is done.  I would use the Arduino to gather the info from the IMU on the I2C bus, do some preliminary calculations, and pass the information to the RPi to complete the calculations. The Raspberry Pi would have a better chance of performing the calculations.
More later.

FInally broke the code on the Vlan setup

Well, leave it to me to become confused about how to use my managed switches.  I own three Netgear GS108Ts and use them throughout my house in an effort to manage my home network.  These are a little overkill but I got them because I had this great idea about setting up multiple Vlans throughout the house and I wanted to learn a little more about configuring level 2 switches.  The problem was, up until this last weekend I really didn't have enough time to sit down and configure a "true" vlan using the boxes.  The main difficulty was figuring out how to mix untagged ports and tagged trunk lines throughout the house.  It turns out that I was reading the instructions wrong.  Yes, you heard that, I actually read instructions from time to time.

The GS108T instructions are a little vague on how to set up ports as tagged and untagged on isolated vlans.  I needed to set up ports between two managed switches with a trunk line, i.e. the packets were 802.1Q tagged, with packets going in opposite directions on the same physical ethernet line.  My problem centered around understanding what the instructions were saying, not that they are bad instructions, it's just that they left out some details or someone assumed that the user would automatically know what to do.  I am learning how to use the product correctly.  I found out that you needed to set up the ports on either side of the trunk line in the following manner:

1. you need to set the T on each of the vlans that you want to appear as tagged on the port; the vlan numbers should be the same on either switch.
2. on the PVID screen you need to set the acceptable frame types as "VLAN only" instead of "Admit All"; this forces the port to discard any untagged packets that appear
3. on the PVID screen ignore the PVID field for the trunk port; this was not clear in the documentation
4. on the PVID screen leave the ingress filtering to "Disable" as the opposite drops tagged packets that are not the id in the PVID field; since you can only have one number in the PVID field, this would not be a good choice (not clear in the documentation)

Ports that are not trunk ports, but are untagged members of the same vlan are configured as follows:

1. you need to have a U on each of the ports represented with the vlan that you want to recieve/transmit on; note that only one vlan should be present on the untagged ports to isolate the vlan from others; this is not true of the tagged ports
2. on the PVID screen change the PVID field to be the vlan number that you wish to have on the port
3. on the PVID screen leave the acceptable frame types to "Admit All" for the untagged port; this will ensure that the incoming packets will be destined for the specific vlan mentioned in the PVID field
4. on the PVID screen leave the ingress filtering to "Disable" on the untagged port; this will ensure that the rules in 802.1Q are followed for the port

Well, at least I feel better now that I can have isolated vlans running throughout the house.  If I need to move data between them, I will setup some routers to perform that function.

Added several VMs to the RPi subnet

Last night and this morning, I added a number of VMs to the Mac Mini in order to support development of the RPis and to aid in penetration testing of the subnet.  I pulled the VMs from the bitnami repository (http://www.bitnami.org) and also added some VMs that I already had working.  I am using VMWare Fusion on the Mac Mini to provide the host environment.  The VMs were:

• RPiDev - an ubuntu VM containing bouml, cross compilers, and Arduino development packages (need to add a VNC server so that I can access the VM from one of the RPis)
• Joomla - a CMS; here primarily for penetration testing
• LAMP - a generic LAMP package; planning on adding ajaxplorer, a DropBox like file management system; here for file storage plus penetration testing on a generic Linux box
• Trac - an issues tracking package
• Subversion - a configuration management package for storage of source code

I now have the equivalent of 5 different computers running on the subnet in addition to the Raspberry Pis that I have in operation at any one moment.  In addition, I opened up a port on the outside of Router-3 so that I could connect directly to the ssh port on one of the RPis, this will aid in being able to run a VNC or ssh connection remotely.

I will probably have to change the subnet addressing.  The reason is that my home network connects to FIOS via an ActionTec router that has the same subnet addressing.  I don't want the two subnets to ever be confused with each other.

Carved out a subnet in my home network for PwnPi tests

It was raining this weekend so I decided to finish up putting together a subnet in my home network for testing the Raspberry Pi.  This will also serve as an enclave for using PwnPi to do some penetration testing.  I have decided to get back into the swing of things security wise since I am taking another certification class.  I have been wanting to learn how to do penetration testing in preparation for going after a CEH (Certified Ethical Hacker) certification.  This is outside of the ISC2 certification domain; where I already have a CISSP (Certified Information Systems Security Professional).  I have a multifold purpose for wanting to do this:

1. I want to have a separate (logically and physically) network for penetration testing using PwnPi.
2. Doing penetration testing will not only help me to learn but will also let me know where the weaknesses are in my network.
3. I want to have a separate network setup to support development work on the RPi.
4. I want to have a network setup to test out the new OpenWRT package that runs on the RPi; therefore, I need to be able to place the RPi in a router like position easily.

In my house I have three routers and three managed switches which I can use to define separate networking elements.  On one end of the house I have a Mac Mini which I use as a server for experimentation along with several other physical servers which are normally turned off until I want to do some experiments.  Why?  Because I want to learn something about networks and this way I can immerse myself in some learning topic without having to pay money for classes.  At the other end of the house is the RPi experimenters area.  I have a managed switch close to the Mac Mini and another managed switch close to the RPi experimenters area.  The three managed switches are 1GB ethernet switches, so the ethernet cable between them carries a 1GB stream.  I use this as the backbone for my home network.  I realize that it is overkill, but it allows me to do some interesting things.  For my purposes, I wanted to move one of the routers to the RPi experimenters area and set up the switches so that I could use the Mac Mini to host some virtual machines to be connected to the RPi experimenter area.  Diagrammatically it looks like this (most of the information was removed to help in the discussion):

A secondary ethernet port was added to the Mac Mini by plugging in a USB to ethernet cable.  By setting up the router between two ports on the RPi experimenter managed switch, I am able to use the router to move between two separate Vlans.  Vlans (IEEE 802.1Q) are virtual lans and can have the property that more than one vlan traffic can be moving down the same wire but yet not have packets that interfere with each other.  In my case the 1GB wire between the two managed switches have tagged vlan packets that are logically isolated from each other.  This wire carries information from the VMs running on the Mac Mini through the separate Vlan to the router (LAN side).  This in turn is mixed in with the information on the RPis.  The router provides isolation between the Vlans and in a pinch can be disconnected from the main home network; for extra security.  The RPi managed switch and router are in close proximity and I can unplug the unmanaged switch (connecting the RPis together and plug it into the managed switch on a port which is in the home network as necessary.  This is not the only separated Vlan running through my house but I need the isolation in order to continue PwnPi experiments.  Should be fun.

The Blackboard Design Pattern

Having gotten together a lot of the lower level patterns, I am now turning to the Blackboard design pattern itself.  I am using the POSA1 book chapter on the Blackboard design pattern.  In addition I will be using a design pattern paper entitled, "Two complementary patterns to build multi-expert systems" by Philippe Lalanda.  This allows me to think about what goes into such a design.  The Blackboard pattern layout is in the following diagram:

Notice that in this layout, the Domain knowledge sources and Control knowledge sources are separate.  The ControlPlanNet is implemented as a StateChart design pattern as is the BlackboardControl element.  The ControlPlan itself is derived from the CommandProcessor design pattern so that command are executed separate from definition and that the commands can be "named".  In addition, the ControlPlan contains a number of ControlPlanNets, allowing the Control knowledge sources to select which one is to be the current control plan.  The Top_Control_KS affords the ability to intialize both the Blackboard and the Control plan and would of course be the first knowledge source that is executed.  Again, I am trying to allow myself the luxury of defining each of these structures from xml file definitions.

Addition of StateChart to Blackboard

The StateChart pattern, from a paper by Yacoub and Ammar entitled "A Pattern Language of StateCharts," is coming along nicely.  I have the classes together and most of the code is in place, although there are some interesting issues when creating the C++ code with Bouml - not a problem with the program, just a problem with my understanding of configuring it to generate C++ the way that I want.  The class diagram is as follows:

Notice that I have incorporated the CommandProcessor as part of the actions.  The way that this works is to have the state interface control the way that the states are manipulated.  The events are enumerations (to keep it simple and to be able to cause an event to happen remotely).  The actions that are executed when a given state is entered, use the CommandProcessor to separate the commands from the overall logic of the state and at the same time provide a "named" execution.  The other nice thing about this design pattern, is the ability to create new states and actions on the fly (e.g., from the Control knowledge sources) to manipulate how the system reacts in a given instance.  Although that is a nice ability, the StateChart design pattern does allow for orthagonal state charts which are independent from each other, but can be executed in parallel.  How to eventually implement this is a TBD at this point.

Working on the Blackboard Implementation

I have taken some time off from the electronics portion of my projects to concentrate on the software. I have been using the very affordable Bouml UML case tool (http://www.bouml.fr) to put together a design. The tool is very good at being able to generate C++ (and other languages) shells of programs. Then you take the source code generated and modify it using Qt Creator as the IDE.

I keep the design and source code on a USB stick and plug it into my Mac Mini or Work laptop, both running VMWare with Ubuntu VMs containing my code. I was able to get Bouml license keys to run a copy in both VMs, legitimate of course according to the developers license agreement. With this setup, I can work on the source code development at home, and also at the office during lunch and before work starts. Since the code is being run and tested in a Linux environment, it should transfer easily to the RPi when the time comes, via the USB stick. I will probably end up with close to a hundred classes in the design so I wanted to use some tools that made sense.

I have been working on the overall Blackboard implementation and have made several design decisions along the way.

1. I have decided to implement the Control Plan(s) as a StateChart. The advantage with this is that I can reuse the Command Processor pattern, and be able to setup portions of the plans that might be orthogonal (happening in parallel) while still being able to create the linkages via XML definitions.

2. The StateChart design pattern is developed after a paper by Yacoub and Ammar entitled "A Pattern Language of StateCharts."  I will be able to use this pattern in the Blackboard Controller implementation as well.

3. I will also be using some elements of a design pattern by Liebenau entitled "InferenceFramework: An object-oriented framework for constructing rule-based systems." He has some pretty good ideas in the paper. I hope to use his ideas in the construction of the blackboard data structure itself.

4. keeping with my original idea of building the knowledge structures and execution sequences via a definition in an XML file will go a long way in keeping my sanity as I develop test and rework the AI portion of the Robot. Besides, I like tinkering anyway.