In this report I will be focusing on the improvements and modifications that I can make or use to simply ‘improve’ the buggy/control system that I’ve developed if I was given a more time to build it. I will be critically evaluating the design and performance of the control system that I’ve developed. This is where I’ll be focusing on what went wrong during the design stage or perhaps the testing stage and whether or not these problems could have been avoided or not. I will also talk about how I could have designed my system better, and also how I could make it a complete ‘Roomba’ home device (some in which I’ve explained earlier in the report).
The control system that I developed was a robotic buggy. The buggy is basically a 'robotic' device which has commands and codes installed onto it by a user, in which after this code or command has been installed onto this 'Robotic device' it should be able to generate or reply back to this command/instruction or code given to it by actually performing/giving an output. This output given or performed, is the robotic device actually performing the instruction given by the user (in the flow code diagram). In the simplest of terms, the buggy basically provides a platform in which it’s used to compete or take part in robotic events.
I used the flow code diagram to actually command or give instructions to the buggy. The flow code in simplest of definitions; is a flow code in which acts and IS a graphical programmable language designed for microcontrollers, where in this case the 'Buggy' itself is a microcontroller. It enables the user to create electronic systems in a short period of time (very quick) which is an advantage in terms of using this software.
There were several different improvements that I could have set or used if I was given more time. One of these improvements could be to increase the sound level to a more suitable level. Remember that the loudest the robot can take in terms of sound (MIC) is 255, and I set the sound power at first to 30. This means that the sound is near/around minimum and it would require almost quietness (not so loud room) and I’m in a class of around 20+ students so it would be almost difficult to make the robot respond to a command linked with ‘sound’. Increasing the sound to around a 100 (if I was given more time) would mean that a clap (that isn’t too quite like when the MIC/sound power was at ‘0’ and needed very quite noise to function) would be enough to move or make a response. This is therefore one improvement that I would need to make.
Have in mind that this robot system is some sort of a closed loop control system as it would react ‘accordingly’ to some sort of feedback (via/set in the flow code diagram) which would then change this input into the output which is the feedback that is given/presented (as a result).
There is the possibility that I could use this system or the buggy that I’ve developed for purposes such as acting as a vacuum cleaner (where it does the house vacuuming itself). In a lot of cases it’s really difficult (when vacuuming/cleaning the house) to get into really difficult positions such as under the bed under really small corners/gaps, and in my opinion I could add improvements onto this buggy that I’ve developed to make it ‘able’ to do this vacuuming.
To be able to do this, I firstly would need to add some sort of a filter bag (which takes the dirt in) and a hose that sucks the dust in. I am then able to use the flow code diagram to make the robotic buggy able to sensor walls; so if the buggy makes some sort of ‘collision’ with a wall then it moves away into a different direction. This is a really good feature because if the buggy wasn’t able to sense any sort of collision with barriers such as walls/doors, then it would just get stuck and the user must have to get it off the barrier on many different occasions, so it’s therefore really significant for the buggy to be able to sense barriers. In other words adding more sensors to the vacuuming tool would bring more functionality which is what I want.
I could also make the robot ‘buggy’ be able to sensor a light and sound that would in some way combine to create an outcome. When the user thinks it’s enough vacuuming done by the buggy itself, then sometimes it’s really difficult to get the buggy out of awkward positions that the user may find difficult to get it out such as under the bed or under sofas/chairs etc; so if there was some sort of sensor that if there was a sound (MIC) made at around 175 powers then the buggy would stop and set a delay time of 2 seconds before it also senses light and follows the light and stops there. What this means is that I’ll be using the flow code diagram to make the buggy respond to a sound (made by the user to let it know to ’stop’ what it’s doing). When it stops, then the user could put the light on and the robot buggy would probably go to the brightest area of the room and stop (which would make it a lot easier for the user to collect the robot and put it to place). All this would also contribute into making my the designs of my systems much better
During the overall course of the project (design, implementation and testing stage) I had to work with (on) two different programs. One of the programs was to develop a buggy (simple one) whereas with the second program, I had to develop and/or construct a program in which is able to use more than one sensor (so I developed one with two different sensors).
The first program that I’ve developed was a simple program with the aim of moving forwards and backwards. It used simple macros which where ‘Forward’, ‘Reverse’ and the other macro ‘Stop’. This was set within the flow code diagram, where this code would control the movement of the buggy itself once it has been chipped on to the device (the robotic buggy).
However, the second buggy needed far more focus and user input especially when it came to setting up the flow code diagram and setting instructions within the flow code diagram which I really found difficult. This is where the majority of difficulties and problems started to occur. The aim of my second program (the buggy which had to include two different sensors) was; when the light in the room or area where the buggy is at is greater than or equal to 50 then a component macro (designated to make the buggy spin) is called in meaning when the light sensor senses that the light is equal to 50 or is more than; then the buggy would spin in the direction ‘left’. Now a macro is called in 2 seconds after this spinning, and although the buggy will keep spinning this new macro that’s called in called (macro-listen) would then sense that if the sound is greater than a fifty (50 parameter/power) then the buggy would then stop; stopping because the sound (MIC) macro has sensed that the sound parameter/power is equal to 50 or is over fifty so it stops the buggy.
This is where I know that I’ve successfully done the tasks I was asked for as I’ve made a program (in terms of the buggy that I developed) and made it respond to events and actions using two different sensors.
Along the way (to implementing the buggy that uses two different sensors) there were many difficulties and problems that I’ve experienced and found difficult in dealing with. During the designing stage using the flow code diagram, I tended to rely on the code of other classmates within my class (using their code/copying parts of their code) which meant that when it came to independent understanding of the work, I would find it really difficult to actually build my own program. Therefore could easily have been avoided by doing some research myself such as reading the tutorials and probably asking the teacher to give me some sort of demonstration of the basic functions within the game. This I did at a later date, as I when everyone was on their break from lesson, I asked my teacher to show me the basics of the flow code diagram and its features and how it functions. He (teacher) gave me (roughly) a 20 minute demonstration on the actually flow code program itself, and what the macros and the rest of the features are there for and how the function, and also how I would attach the flow code (instructions) onto the buggy when I’ve completed setting up the flow code instructions. This was huge beneficial lesson that I’ve gained, and it also bolstered my confidence and more importantly my understanding of the whole system. With the combination of this demonstration with the tutorials that where online, where I was then able to start the using the flow code diagram (program) to actually design the type of sensors I wanted to include and its purpose ‘independently’. This gave me enough confidence to actually test my program (the buggy with two sensors) and it turned out to be a success which enabled me to get a video of it (to act as some sort of proof that it worked). The difference now to before be that before I didn’t do the work independently which meant that I was more liable to get errors as their program may be wrong, but with the program I developed I can test it myself and find out the errors myself in person, instead of someone else doing it for me.
