Dec 20

Maestro MuzaBot

Every year at GroupT there are one or two so called Engineering Experience projects. These projects usually involve a team consisting of around five people from the same year. This semester it was time for ‘Engineering Experience III’.

I started off mailing people even before the start of the semester because I wanted a good, functional team to work with. My dreamteam was a group of only EA (electronics) students, but it was not possible partly because I didn’t know enough people who are going to do EA starting next semester besides a couple of friends.
After a few requests and another handful of e-mails the composition of our team was finalized. Diversity  all around with two biochemical, one electromechanical and two electr(on)ical engineering students.

The objective of this project was to create a machine or robot that could be controlled by a computer using LabVIEW, Computer Based Control. Joy for the EA folks, a little less happiness at the other quadrants of the GroupT spiral. Nonetheless, no one has died from this course yet so there we were, trying to come up with a cool and realistic idea.

After an hour of brainstorming or so we had a couple ideas written down on the blackboard. Some were too hard to even consider them, others were too silly or too easy. Being a musical person myself I proposed a robot that could play some instrument, just like The Trons. Eventually everyone agreed and we quickly decided to use a metallophone  and some homemade drumming construction.

After over hundred hours (per person) of working on the software, construction and electronic circuits the result is pretty satisfactory. It could’ve been a better had we not neglected deadlines a couple of times (not gonna happen again, ever!) as we had to rush some things in the end to make it ready for the presentation.

The construction of the modules consist of Fischertechnik, LEGO and LEGO Technic blocks. Since those don’t always fit flush together we had to glue some things to make it work. The big parts are

The Read Module

Read Construction

This part of the robot can read homemade music sheets which it translates to numeric values so LabVIEW knows how to handle it. This is achieved by using a set of IR-LEDs and IR-receivers (photo-transistors) . You feed the construction (not shown) a music sheet, it’ll detect it and start pulling it in. Once the sheet has gone through the reading part the motor automatically stops.

The Metallophone Construction

Metallophone

 

Next up is one of the two modules who take care of reproducing the music. This part contains 2 motors, four musical tones (C, D, E and F) and a couple of switches. Based on what is in the arrays the hammer will first move on the x-axis to the correct position and then move in an arc-like motion to ‘slam’ on the metallic plates. A bonus thing is, both this and the drum module are ‘in sync’ as they will hit their respective target at the same time.

The Drum Module

Drum

The  drum can either hit a metal can or a plastic cup. This is the simplest construction of the robot as it only uses one motor and two switches put in parallel. As mentioned before, the hitting takes place as soon as the x-axis of the metallophone signals it’s ready to start the “hit” sequence.

The PCB and DAQ

PCB

 

 

 

The missing link between the modules and LabVIEW on our computer is the actual PCB which every electronic component is connected with. This specially designed for this course circuit board contains some basic things such as 9V and 5V voltage sources as well as other in and out gates. Another interesting component is the H-bridge so we could easily make the motors run in both directions.

Aside from this PCB, we also had a National instruments DAQ card, the 6008-USB. This DAQ-card was hooked up with a computer which runs LabVIEW. It’s relatively cheap but it’s got more features than we could’ve asked for.

GUI

Actually using and controlling the robot can be done through a GUI I made. Here you can see what is going on (yellow part), how many beats are ready to be played and how many have already been played (orange) and the virtual representation of what is being played (green).
The blue and red parts are the areas where you can either save/load music or enter your own tunes. This makes a total of three ways to add music information into the robot.

This project was a lot of fun in my opinion, and I’ve learnt a lot by designing the program in LabVIEW and helping with the construction of the different modules. Last but not least, feel free to check out the following video of the machine in action (sorry for the crappy audio/video quality!)

May 04

Developing in team

As you might know I’m the ‘lead’ of Saturn Valley Online. It’s an MMORPG game I started way back in 2006 when all I knew was PlayerWorlds (which I now know, sucks compared to a real game engine). Since then a lot of things changed, people came and went but luckily two are still around (is it that hard to find dedicated people in this age?).

We started out with vbGORE, an engine written in Visual Basic 6, it got to a point where it was seen as ‘finished’ for a vanilla engine to work with, this being said, using Subversion (SVN) was pretty easy and an absolute must when we were working together on program code and graphics. Luckily the other guys were smart enough to make good use of this.

As simple as it may seem I’ve found that it’s pretty hard to keep people around when you’re just familiar with each other through chatting over the internet. It has happened multiple times already that people ask to join our development team explaining they can and want to do this and that, but in the end they weren’t motivated enough to stay around and maybe did only a handful of things (or less) before they quietly left, never to be heard from again.

It seems when there’s no actual paycheck involved people tend to make impulsive decisions about wanting to help out but as fast as they said they would help out they disappear again only days (or in some cases a week or two) later. This is pretty frustrating as you make a schedule for things that need to be done and assign a couple of tasks to these people. In the end these tasks don’t get executed well, if at all.

Therefore, if you ever find yourself in a situation like this (being a person who wants to join a dev team) stop everything you’re doing and take a few minutes to consider if you really want to spend time developing things. Even 2 to 3 hours a week (that’s less than 30 minutes a day!) is fine for smaller teams and applications that are being made ‘for fun’. If you can’t keep this up do yourself and the team a favor and do not ‘apply for a job’ because it will only cause frustrations. Rather freelance stuff for the project, this way you can do it whenever you feel like it and no one will complain if it takes a long time or if you disappear for 5 months.

SVO has been around for 4 years now (2 years publicly) and because of the above we’re still in the early stages of the game (another thing to take into account is the switch of game engines) instead of having a real enjoyable online game for the Earthbound (or Mother if you prefer) fans out there. Luckily this project is just for fun and because we can else it would’ve been trashed a long time ago.