I've been looking into how to build a custom MIDI instrument using the Arduino that I can connect to my laptop running Pure Data. The following are some good resources on this matter.
MIDI
Wikipedia's MIDI page (yes, of course)
MIDI Communication article on tigoe.net
MIDI Protocol Guide by Hinton Instruments
Arduino+MIDI Hardware
MIDI Output Using an Arduino (from ITP Physical Computing)
Controlling Garage Band with Arduino (from ITP Physical Computing)
Arduino Note Player (from arduino.cc)
There are some nice MIDI shields available on SparkFun that include just the essential components needed to build a MIDI instrument with a MIDI output port.
Arduino+MIDI Software
Arduino MIDI Library
Arduino Shields
MidiVox shield for Arduino
Arduino Piano Squealer Synth (and on Make as the Pocket Piano)
Pd
Using MIDI (FLOSS Manuals)
Configuring Pure Data (FLOSS Manuals)
Programming Electronic Music in Pd (Johannes Kreidler)
Goodbye.
Monday, April 12, 2010
Wednesday, March 17, 2010
SIGCSE 2010 Notes
Recently, I attended the SIGCSE 2010 conference in Milwaukee, WI as a student volunteer. I attended a couple pretty interesting talks, one by Microsoft and the other by Intel.
Timothy Ng from Microsoft presented "Getting Started with F#". Learn more about F# at the F# website.
Stewart Christie from Intel presented "Intel Atom Processors in Academia". In this talk, Stewart focused his talk on the Intel Embedded Development Board 1-N450, which Intel is using to attract hobbyists, researchers, educators, and the like. Pretty cool. Intel's goal is to start an open community around the N450 and similar boards. At the moment, this open "community" is no community as it's just getting started. In this talk, Christie also mentioned something called a "beagle board". It's not from Intel. What is it? It turns out that the Beagle Boards are pretty nifty development boards that can run Linux. Check 'em out (here).
I also meandered through the conference hall on more than one occasion. Encountered were various exhibitors, such as Google, LEGO, IBM, as well as Intel and Microsoft. Intel's exhibit was my favorite. They were showing a Mini-ITX cluster running on-site called LittleFe, and a Hexapod that used a servo control model learned with a Q-learning algorithm. Definitely neat.
Timothy Ng from Microsoft presented "Getting Started with F#". Learn more about F# at the F# website.
Stewart Christie from Intel presented "Intel Atom Processors in Academia". In this talk, Stewart focused his talk on the Intel Embedded Development Board 1-N450, which Intel is using to attract hobbyists, researchers, educators, and the like. Pretty cool. Intel's goal is to start an open community around the N450 and similar boards. At the moment, this open "community" is no community as it's just getting started. In this talk, Christie also mentioned something called a "beagle board". It's not from Intel. What is it? It turns out that the Beagle Boards are pretty nifty development boards that can run Linux. Check 'em out (here).
I also meandered through the conference hall on more than one occasion. Encountered were various exhibitors, such as Google, LEGO, IBM, as well as Intel and Microsoft. Intel's exhibit was my favorite. They were showing a Mini-ITX cluster running on-site called LittleFe, and a Hexapod that used a servo control model learned with a Q-learning algorithm. Definitely neat.
Sunday, February 7, 2010
Dialog with a Robot
It seems that a machine that could explain itself down to the procedure level would be rather appropriate. This machine would be able to refer to the software that defines it's self. The software might not be correct, but would serve as a concrete foundation for a human to reason about and with the machine. To illustrate this, consider such a machine named Robot engaged in a dialog with some human named Human. Let Robot and Human be at the point in a discussion when Human inquires Robot with "Why?". This is in response to Robot's previous assertion which was not understood by Human. Robot explains its meaning using some abstract verbal syntax that Human can readily interpret. Despite Human's familiarity with the syntax, Human does not understand Robot's motivation. Human again inquires, "Why?". This dialog between Robot and Human continues until Robot states "I say this due to my programming in the procedures named <Procedure A>, <Procedure B>, ..., and <Procedure N>." This seems like an appropriate behavior for machines that humans can interact with in some way similar to how one human interacts with another human because it allows such natural interaction to take place, but provides the option to the human (or perhaps another machine) to discover the precise mechanisms that entailed the behavior that summoned inquiry.
Tuesday, April 15, 2008
Hello, Automo
I've decided to refer to my RC-to-autonomous truck project as Automo. There's no more particular motive for choosing this name than it sounds similar to "autonomous" and "automobile", both of which are relevant for this project. It's interesting to note that the character string "automo" is the matching substring for the words "autonomous" and "automobile", but this is coincidental in that it played no role in my choosing (I realized in while writing this update)!
I've been experimenting with various H-bridge and control logic circuit designs for the main driving motor, but haven't yet come up with one that is optimal. I haven't had time enough in the past few weeks to further develop the H-bridge circuit design due to school and work obligations, and haven't gotten anything tested on the truck.
Aside from tinkering with various circuits, I've written a simple application (using Visual Basic .NET with GDI+) that simulates the ultrasonic sensor and servo configuration I plan to use for basic environment map generation and navigation. A few screen captures of the program follow are shown below:
The "compete" program window:
The map of the physical world and the player and sensed distances:
The program generates a simple 2D physical world, places a "player" point (representing Automo) in the world, and then draws lines corresponding to the read distances taken by the ultrasonic sensor at a specified read frequency. In the shown screen captures, the read frequency is set to 12 reads/revolution, so readings are taken every 30 degrees. The ultrasonic sensor that I'm using for Automo has a maximum range of approximately 3 meters. I'm modeling this in the program such that if no distance is measured less than the maximum distance, the entire green line is drawn.
Before moving onto adding more features to the program, I'm going to clean up and organize the code code a bit, in order to make it easier to work with. After this brief janitorial intermission, I'll likely instate a consistent pixels-to-meters scale, better organize the ultrasonic distance readings, and add automated navigation based on this data. I also plan to add a simulated infrared sensor that sweeps 180 degrees back-and-forth (continuously) on the front of the player. The infrared sensor data might be used for more immediate navigation decisions, while the longer-range ultrasonic data might be used for things like planning ahead or guessing which general direction to move.
Expect a nice post regarding Automo's front steering circuit and associated AVR-C control code relatively soon (and maybe some other random information).
I've been experimenting with various H-bridge and control logic circuit designs for the main driving motor, but haven't yet come up with one that is optimal. I haven't had time enough in the past few weeks to further develop the H-bridge circuit design due to school and work obligations, and haven't gotten anything tested on the truck.
Aside from tinkering with various circuits, I've written a simple application (using Visual Basic .NET with GDI+) that simulates the ultrasonic sensor and servo configuration I plan to use for basic environment map generation and navigation. A few screen captures of the program follow are shown below:
The "compete" program window:
The map of the physical world and the player and sensed distances:
The program generates a simple 2D physical world, places a "player" point (representing Automo) in the world, and then draws lines corresponding to the read distances taken by the ultrasonic sensor at a specified read frequency. In the shown screen captures, the read frequency is set to 12 reads/revolution, so readings are taken every 30 degrees. The ultrasonic sensor that I'm using for Automo has a maximum range of approximately 3 meters. I'm modeling this in the program such that if no distance is measured less than the maximum distance, the entire green line is drawn.
Before moving onto adding more features to the program, I'm going to clean up and organize the code code a bit, in order to make it easier to work with. After this brief janitorial intermission, I'll likely instate a consistent pixels-to-meters scale, better organize the ultrasonic distance readings, and add automated navigation based on this data. I also plan to add a simulated infrared sensor that sweeps 180 degrees back-and-forth (continuously) on the front of the player. The infrared sensor data might be used for more immediate navigation decisions, while the longer-range ultrasonic data might be used for things like planning ahead or guessing which general direction to move.
Expect a nice post regarding Automo's front steering circuit and associated AVR-C control code relatively soon (and maybe some other random information).
Saturday, February 23, 2008
Looking into the front steering unit
Today, I disassembled much of the RadioShack Hummer H3 RC truck with the goal of determining the where and how the 6-pin connector connected, and how I could interface with the existing steering unit. After a few hours of careful tinkering (careful to prevent misplacement any of the many screws!), I uncovered a gearbox that contained both a DC motor and a potentiometer. The motor and potentiometer are connected by a series of gears, such that the rotation of the motor will also rotate the potentiometer. Photos of the gearbox and connector are shown below.
The 6-pin connector, extending from the front steering unit:
The opened-up steering unit gearbox showing the motor and potentiometer:
The opened-up gearbox and contents from another angle:
The complete gearbox unit, with the back piece, the contents, and the front cover. The front cover contains the gears that attach to the external arm:
The contents of the front cover of the gearbox:
The back of the gearbox with the motor and potentiometer in place:
The complete gearbox, in two pieces:
The complete closed gearbox:
The following video demonstrates the gear operation that takes place within the gearbox covering (I apologize for the probably-too-short length of the video):
With the gearbox apart, the physical connections for each of the wires in the 6-pin connector were inspected. The connector's wires, from left to right are (1) brown, (2) red, (3) orange, (4) yellow, (5) green, and (6) blue. Wires 1, 2, and 3 are connected to the potentiometer, while wires 4, 5, and 6 are connected to the motor. Wire 1 is connected to the middle terminal of the potentiometer, and wires 2 and 3 are connected to the side terminals. Wires 4 and 6 are connected to the DC motor terminals, and wire 5 is connected to the motor's metal casing (ground).
The resistance between wires 2 and 1, and wires 3 and 1 vary as the potentiometer is turned, while the resistance between wires 2 and 3 remains constant. The constant, and maximum resistance between wires 2 and 3 was measured as approximately 4.9 kiloohms.
With the gearbox unit out of the truck chassis, resistance measurements were taken for the turning arm in left and right extreme positions, and the approximate center position between wires 2 and 1, and wires 3 and 1. With the arm in the extreme left position, the resistance between wires 2 and 1 was 4.51 kiloohms, and the resistance between wires 3 and 1 was 0.57 kiloohms. With the arm in the extreme right position, the resistance between wires 2 and 1 was 0.49 kiloohms, and the resistance between wires 3 and 1 was 4.62 kiloohms. In the center position, the resistance between wires 2 and 1 was 2.54 kiloohms, and the resistance between wires 3 and 1 was 2.67 kiloohms.
A document containing these measurements is located on Google Documents and can be viewed by following this link.
With these measurements, I placed the steering gearbox unit back into the truck chassis. The gearbox is situated between the left and right sides of the housing for the front driving mechanism. The driving mechanism entirely encapsulates the steering gearbox with only the 6-pin wire exposed to interface with the motor and potentiometer in the gearbox. Photos of the gearbox and front driving mechanism are shown below.
The approximate location of the steering gearbox in the driving mechanism:
The opened-up front driving mechanism:
The closed front driving mechanism with the 6-pin wire exposed:
With an understanding of how the existing front steering system operates, I plan to design and build circuits to detect when the wheels have been turned to an extreme position, and to prevent any attempt of turning further than this (to prevent the gears from grinding). In addition, I'd like to be able to turn to an exact position and quickly re-center the wheels.
The 6-pin connector, extending from the front steering unit:
The opened-up steering unit gearbox showing the motor and potentiometer:
The opened-up gearbox and contents from another angle:
The complete gearbox unit, with the back piece, the contents, and the front cover. The front cover contains the gears that attach to the external arm:
The contents of the front cover of the gearbox:
The back of the gearbox with the motor and potentiometer in place:
The complete gearbox, in two pieces:
The complete closed gearbox:
The following video demonstrates the gear operation that takes place within the gearbox covering (I apologize for the probably-too-short length of the video):
With the gearbox apart, the physical connections for each of the wires in the 6-pin connector were inspected. The connector's wires, from left to right are (1) brown, (2) red, (3) orange, (4) yellow, (5) green, and (6) blue. Wires 1, 2, and 3 are connected to the potentiometer, while wires 4, 5, and 6 are connected to the motor. Wire 1 is connected to the middle terminal of the potentiometer, and wires 2 and 3 are connected to the side terminals. Wires 4 and 6 are connected to the DC motor terminals, and wire 5 is connected to the motor's metal casing (ground).
The resistance between wires 2 and 1, and wires 3 and 1 vary as the potentiometer is turned, while the resistance between wires 2 and 3 remains constant. The constant, and maximum resistance between wires 2 and 3 was measured as approximately 4.9 kiloohms.
With the gearbox unit out of the truck chassis, resistance measurements were taken for the turning arm in left and right extreme positions, and the approximate center position between wires 2 and 1, and wires 3 and 1. With the arm in the extreme left position, the resistance between wires 2 and 1 was 4.51 kiloohms, and the resistance between wires 3 and 1 was 0.57 kiloohms. With the arm in the extreme right position, the resistance between wires 2 and 1 was 0.49 kiloohms, and the resistance between wires 3 and 1 was 4.62 kiloohms. In the center position, the resistance between wires 2 and 1 was 2.54 kiloohms, and the resistance between wires 3 and 1 was 2.67 kiloohms.
A document containing these measurements is located on Google Documents and can be viewed by following this link.
With these measurements, I placed the steering gearbox unit back into the truck chassis. The gearbox is situated between the left and right sides of the housing for the front driving mechanism. The driving mechanism entirely encapsulates the steering gearbox with only the 6-pin wire exposed to interface with the motor and potentiometer in the gearbox. Photos of the gearbox and front driving mechanism are shown below.
The approximate location of the steering gearbox in the driving mechanism:
The opened-up front driving mechanism:
The closed front driving mechanism with the 6-pin wire exposed:
With an understanding of how the existing front steering system operates, I plan to design and build circuits to detect when the wheels have been turned to an extreme position, and to prevent any attempt of turning further than this (to prevent the gears from grinding). In addition, I'd like to be able to turn to an exact position and quickly re-center the wheels.
Subscribe to:
Posts (Atom)