The main improvements that I would suggest for my “dance” flow chart/code design is to ensure all features are operational by thoroughly testing each feature, thus this is to ensure the complied program’s performance is consistent regardless of the physical buggy.
Another improvement that I would incorporate is an algorithm that turns on all of the red LED’s if lighting conditions are extremely poor. If lighting conditions are slightly poor then just 2 LED’s will turn on. Hence, the microcontroller/microprocessor makes decisions based on the amount of light entering the light sensor (ambient light sensor) based on the algorithm. Potentially, this will improve the battery life i.e. extend operating period of the buggy whilst executing the instructions by making logical decision.
The final improvement that I would add to the program/buggy is speeding-up the movements by increasing the speed of the left/right motors e.g. instead of both the motors being set to speed = 150, I will set the speed = 200. This will potentially speed up the process of execution.
The main modifications that I would make on my buggy are by adding a mini LCD display to it. The purpose of this modification is to display message/graphics. If you say something e.g. “hello” the microphone will detect that you have said it. This will be displayed on the mini LCD display of the buggy.
I will add extra functionality my buggy, which behaves like the robot vacuum cleaner i.e. Roomba iRobot. I will add the support of collision sensors, which will prevent the robot from colliding into stationary objects like furniture. Another improvement that I will add to my robot is another algorithm where it automatically docks at the docking station when the battery is running low. This will mean the robot is self reliant in terms of recharging the battery.
Sunday, 29 May 2011
Evaluation and potential improvement/s (M3/D2)
Overall, I think my design for my control system has been well executed in terms of performance and functionality. My control system utilises two sensors on the programmable buggy. The two sensors I incorporated within my control system is microphone and light sensor (ambient light sensor). I think I have chosen the two right sensors to incorporate within my ‘dance’ program.
I created a program, which enabled the buggy to perform dance moves. The way I successfully managed make the buggy perform dance moves is by using pre configured parameters/procedures like “Forward (150)”, “Backward (150)” “Turn 90 degrees (150)” etc.... The parameters/procedures where implemented in the design of the program i.e. flow chart, for the buggy to execute.
The first sensor (microphone) prompted the buggy execute the code sequentially. The purpose of the first sensor had to listen for a “Clap” sound. Once the microphone detected a “Clap” sound was made, then the pre-configured parameters /procedures will perform the set procedures i.e. dance moves. In other words it will execute the procedures, which I have programmed for the buggy to execute.
The reason why I thought this sensor (microphone) was a good sensor to utilise is because it has to sense for a reaction i.e. “clap” sound. Thus, this prompts the buggy to execute the next programmed instruction.
Additionally, I utilised the light sensor within the buggy. The light sensor detects if the room suffers from low-light conditions. If the room suffers from low-light conditions, then three LED lights turn on. If the room does not suffer from low-light, then the three LED’s do not turn on, due to having sufficient light in the room.
The use of the light sensor (ambient light sensor) within the program benefits the buggy by it being visible in low-light conditions. Also the LED’s make the buggy look more visually pleasing.
I think using light sensor to detect when the three LED’s should turn on is good idea. The reason why having a light sensor is good to determine when the three LED’s should turn on is because in a room with low-light, LED’s will be highly visible opposed to a room with poor lighting, which reduce the visibility of the LED’s.
Overall the utilised sensors are working as expected without any known issues. I think they have been well implemented into the program. Also the sensors are used for a sensible purpose i.e. microphone to detect clapping sound and light sensor to turn on the three LED’s when there is low-light in a room.
The main flaw with compiling/running, the completed program onto the buggy is its performance. The reason why this is an issue is due to the poor build quality of the buggy. Sometimes the programmed features, which are debugged/running on the simulation, are not apparent when program is compiled on the physical buggy.
When you compile the code onto the buggy all of the features do not work straight away. I had issues in getting the light sensor to operate but I finally managed to get it to function after making the light sensor functional.
Overall, the sensors i.e. microphone and light sensor, are used appropriately. The design of the flow diagram has been well thought out with it performing well on the simulator. The only negative aspect is the poor performance when the program/flow diagram is complied within the microcontroller/microprocessor on the actual buggy.
This was due to some features not/semi-working on the buggy. As I have already mentioned previously about the poor performance of the light sensor. Therefore, the overall performance regardless of the buggy is inconsistent, due to some features working/semi-working.
Subscribe to:
Comments (Atom)