So IMDL has finished and so has my robot for now! I've attached the demo videos, which didn't work perfectly, but demonstrated the concept well. I'll be back in am month or so to clean up this site and step through my progress and how Beethovent Bot works. So till then enjoy the vids!
New solenoids have arrived!
All that's left is to code some LED notifiers to show what state the robot is in and perfect the final code before Media Day tomorrow morning. Well, things have been getting worse and worse since Pre-Demo Day last Tuesday.
In this project, a micro-controller controls all the mechanism on the robot. This includes the: 1. Ultrasonic sensors 2. Bump sensors 3. Stepper motors 4. Writing mechanism This micro-controller is an Arduino MEGA 2560. In this post, I'll be covering the basic software process of the Arduino, it's flowchart. At the moment the robot is programmed to listen and determine a single note and then convey that single note to the Arduino to be written. In essence, the Arduino waits for the process and work of the Raspberry Pi to complete and send the musical note data via SPI, then it begins to work. The Arduino waits until it receives a single character. Depending on the character, the motors are told to rotate left or right and move to the correct vertical location on the music staff. Then the note is written, currently planned to be done via a solenoid in a stamping motion. After the note is written, the motors direct the robot back to its original center location. The robot moves forward and then awaits for the next note to be heard. The Arduino's full code is uploaded in the files page. This is illustrated below: First and foremost, object avoidance is not imperative to the function of Beethoven Bot. Since Beethoven Bot operates on a known surface in an known area, it does not need to actively move around any objects. Given that function, Beethoven Bot is programmed to utilize its ultrasonic sensors to see if any object are in its way and stop until those obstacles are moved. On the other hand, object avoidance for roaming robots is a good concept that should be learned for any robotic hobbyist. Given the name, object avoidance is pretty self explanatory, it is the active detection and reaction to avoid objects that would impede a robot's movement. In the case of ultrasonic or IR sensors, your robot will take samples from those sensors periodically and depending on what threshold you give, the robot will understand that an object exists in its way. Normally your robot will have at least three distance sensors pointed out in a sort of "W" formation to see directly in front of the robot and off to both sides (to see in front of the wheels). If an object is sensed to the left of the robot, it will turn away to the right to avoid the object and vice versa for an object on the right of the robot. If directly in front, the robot will back away from the object and then rotate to avoid running into the object again. These are the simplest reactions a robot can do, aside from just not moving. Now there are certain "traps" that the robot can run into. For example: What should the robot do if it senses a corner, where there are objects to the left and right of the robot? Your robot will turn away from one side only to see the other side and turn back. There are many ways to combat this trap. The first would be to randomly generate a reasonable integer and for each turn your robot does in quick succession, you count up. If you reach that random integer, you tell your robot to turn around or back up for a few seconds and turn away from that corner. In this post, I'll be explaining the stepper motor as best as I can and how it is wired in my Beethoven Bot. Well, first off what is a stepper motor? There are quite a few different kinds of motors: DC motors and stepper motors to name two. DC motors are normally used for mobile robots as they are relatively easy to use, they go relatively fast and their speed can be controlled. The downside is that they normally require encoders to obtain feedback to drive straight. Stepper motors on the other hand are relatively slower, more accurate in motion, and are open loop systems (no feedback). So how does a stepper motor work? A good explanation video I've found is linked here: http://youtu.be/bngx2dKl5jU. Basically there are bipolar and unipolar stepper motors. This pertains to the number of pairs of coils inside the motor. The motor is driven by magnetism at its core. In unipolar motors, there are two pairs of identical coils, one pair per phase. A controller passes current to one pair of coils and this changes the magnetic polarity of the coils. Since the coils are alternated, by alternating the magnetic polarity of the phases you have a switching effect of going North to South polarity over and over. This causes driven motion when the center gear is magnetized, causing the gear to be attracted to the coils of opposite magnetic polarity. The gives a sort of production line effect as the gear begins to rotate as it follows the alternating polarity of the coils. Now this is just my understanding of how the motor works, if you wanted to know more I'd suggest googling how stepper motors work. Now what about MY Nema 17 Stepper Motor? Well the product page is here: http://www.pololu.com/product/2267. Well NEMA stands for National Electrical Manufacturers Association. It basically is a standard motor mounting geometry and the 17 means the dimensions of the motor is 1.7'' x 1.7''. This motor has a 1.8° step angle, which means 200 steps/revolution of the motor. The reason I chose to use a stepper motor, was that Beethoven Bot does not roam or follow, he moves from note to note, meaning he doesn't need to travel fast, rather he needs to be accurate. Thus a stepper motor would be more ideal than the DC motor since the stepper motor moves in steps/revolution. Now the stepper motor comes with four cables, two for each phase, which means we need to have something to control which cable passes current at what time. This task is completed by motor driver carriers. The motor driver carrier I ended up with is http://www.pololu.com/product/2134. This is a low voltage stepper motor driver carrier, which operates between 2.5–10.8 V and can deliver up to approximately 1.5 A per phase. Essentially, the motor driver takes two power supplies, a logic level 3.3V or 5V and a driving power supply 2.5-10.8 V to run the motors. A 100uF capacitor is recommended between the driving power supply and ground. And STEP and DIR pins are input from a microcontroller to tell the motor driver how many steps to go and in what direction. The wiring of the motor is in pairs along with the motor driver wiring are shown below : Well, the motor driver PCB has yet another error. This time the part footprint was designed in reverse pin order, making the traces go to the wrong pins on the dip chips. This was fixed as shown to the left. The schematic is also included below for those interested. Long time no update. Well the robot so far is half assembled, the base required a few iterations to decrease size and machine bolt holes for assembly. The stepper motor mount was found and installed underneath the robot. The ultrasonic sensor platforms were machined and mounted. The robot is able to perform rudimentary object avoidance through feedback from the ultrasonic sensors. However the robot is not currently mobile as the power PCB was delay a few weeks due to PCB design errors. The third iteration of the Power PCB was made and populated, this PCB will be tested within the week. The stepper motors are driven through a motor driver controller, which takes battery voltage and logic voltage to drive the stepper motors forward or backwards by a set number of steps. This circuit was created on Perf board, but will be expanded into a PCB this week. The audio analysis was worked on and the frequency heard can now be done with a Bluetooth microphone. The Raspberry Pi will listen for a tone above a set noise threshold and then start recording the sound into a wav file, which will be analyzed through FFT to compute the frequencies heard. These frequencies are averaged and then the according note is send serially to the Arduino via USB cable. Work to be done next week is getting OpenCV to work with the Raspberry Pi and get the Raspberry Pi to use it's camera to detect staff lines of the sheet music paper. Also to install the bump sensors on the robot. Issues that are to be worked on:
Received motors, bump sensors, arduino, and ultrasonic sensors this week. I researched into a way to incorporate special sensor into robot. I completed the lab on using USART and the ADC to control the movement of a servo motor. I believe that the current path is to add a camera either to give an “eye of God” point of view or to use to take photos to compile. The camera used will be the Raspberry Pi camera since I already have a Raspberry Pi at home. The raspberry pi will perform the facial sight and translation from photo to bitmapping as the arduino controls the rest of the sensors and motors. |