19-11-2012, 03:53 PM
143.472 Fire-Fighting Robot
[attachment=40204]
Introduction
Project Introduction
Throughout the past 3 years of our Mechatronics degree at Massey University we have gained knowledge in areas such as: mechanical, electrical, software and electronic engineering. We have in particular focused on: motion actuation, sensing, signal processing and microprocessor control. For the paper Industrial Systems Design and Integration we were required to combine and demonstrate these skills by means of a group project.
This year the project was to design and build a Fire-Fighting Robot. The robot was required to move around obstacles and detect and extinguish small fires, which were simulated by candles. The robots were required to be built by the end of semester one with a competition against the other groups as a final assessment.
As to building the robot itself we were also required to complete a report and web page for our robot. These were to give greater explanation of the design and construction phases of the robot as well as to visually show diagrams and
photographs of the robot we constructed.
Design
Design Overview
As with most projects the design stage of the project is very important. We were aware that decisions that we made early on in the project could have big implications later on regarding the overall success of the project. For that reason we made the decision to spend several weeks on the design stage of the project in order to ensure that we had covered all aspects of the project and come up with the most suitable design possible.
We decided to work first on the mechanical design aspects of the project. We adopted an open approach to design ideas
from the team. From these initial discussions we were able to quickly zero in on the best solution. We then moved on to
the other mechanical aspects of the project. We were initially less concerned with the electrical and control aspects of the
project as what controller we decided to use would have no impact on the mechanical portion of the project. We had been
made aware that often the teams left the mechanical aspects to the last minute which had resulted in a back-log of work
for the workshop staff. We therefore ensured that we got as much of the mechanical construction done as quickly as possi-
ble so as to avoid delays.
While we were working on the mechanical design and construction of the robot we were also researching the best options for the control and sensing aspects of the project. We took quite a lot of time to make final decisions on these aspects of
the project. As it turned out it was worth waiting to ensure that we got the right components. We had initially decided to
use a Microchip PIC-based microcontroller but after further consideration we decided to go with the cheaper and more
powerful Renesas M16C-based controller. This was a controller that Matthew had worked with during his summer job and so he was familiar with its use.
Having spent a lot of time designing the mechanical components we had very little difficulty with things not working properly. There were several minor components which we designed as the need for them arose. We all imposed high standards on our own work; this resulted in a well-built and reliable robot. This hard work in the construction of the unit would result in significant time savings during the testing stages, as we did not have the long down-times that some of the other teams experienced due to reliability issues.
Additions to the Design
There were a number of changes made to our original design which was of circular shape with a diameter of 200mm. We
mounted a second level as we required more room to place our circuit boards and our extinguishing device. This second
level was again 200mm in diameter and the distance between the two was 50mm. By adding a second level we needed
supports to hold the second level in position. W e used a “C” design for these brackets. W e then thought that w e could
mount the 3 distance sensors on these brackets, which would save making additional mounting brackets from the top level.
We also found we needed to increase the stability of the now two-level chassis. We thought of using ball bearings which
could be locally purchased but in order to keep cost down we designed and made skids for the front and back from material in the workshop. The skids were constructed from nylon and followed the shape of the chassis. If these skids did not work satisfactorily we would have purchased the ball bearing wheels.
From the top level we designed a holder for our fan (used to extinguish the flame). It was designed to be higher than the top level and be angled downwards on a slight angle to help with the extinguishing of the flame.
Implementation
We decided that it was important that we were able to get a full field of view in front of the robot. In order to get this we worked out that if we crossed our sensors over we would effectively have a screen; the areas where one sensor was unable to see would be covered by the other.
This layout also allowed us to see objects which were approaching from the front, along with those on the side. Since we wanted to take the same actions for both (turn away if possible) this was not a problem.
As mentioned the robot would turn away from upcoming walls as with equal importance to those on the side. We could effectively affect the priority it gave to each of these by altering the angle we had the sensors set on; pointing more forwards would mean that turning from an upcoming wall was more important than keeping a distance from a wall on the side. In the end we came up with an angle for the sensors which was able to meet both expectations along while still being able to detect smaller objects directly in front of the robot quickly enough to take evasive action.
With the sensors crossing over we were able to accurately detect objects which were within 200mm from the side of the robot and 250mm in front. Any object needed to be within 70mm of a sensor for the reading to become unreliable. This
translated into being approximately 20mm away from the chassis of the robot, by which stage evasive action should hopefully have been taken.
One issue of the sensors themselves was that occasionally they would return a false reading, which was was often valued at
zero. To fix this we included a method (in software) which would average out the last five readings from the sensors. While
this reduced response times we found that it remained quick enough to avoid all but the smallest objects. This averaging
prevented the behavior “Escape” to trigger unpredictably, as it had before w e im plem ented the system . In an attem pt to
increase response times we added a linear weighting to each reading, the newest being five times more important than the
oldest.
Conclusions
The rounded chassis combined with the centrally located wheels worked extremely well for the robot and its ability to navigate the world in which it was placed. We encountered no problems using skids to provide support for the front and back of the robot.
After deciding to use a fan to extinguish the flame and testing its performance we were extremely happy with our choice, in fact our successes prompted other teams to abandon their original preconceptions to adopt our method.
After seeing the trouble other teams had with circuit design we were most pleased that from the start we chose to use keyed connecters as opposed to hard wiring external devices.
Our use of crossSense® worked extremely well for large oncoming objects yet had caused problems when objects were to the side, and had just been navigated past. It was able to detect the sharp or continuous upcoming obstacles so long as they had a reasonable depth.
The UVTron created some difficulty in that it was not originally direction sensitive, and thus required the addition of a custom designed shell. It was extremely reliable once we had completed this physical modification.
Using an M16 developer board to control our fire fighting robot made debugging a lot easier due to an on board LCD unit. Although programming the M16 using the supplied programming solution was slow and tedious, the micro itself was
reliable and presented no problems until a port was overloaded due to human error.
The control system we used was by far the most complicated part of our project; the behaviour control was a good choice to make, as it managed to simplify the process substantially. A major part of our control was using pulse width modulation to control the speeds of our drive motors; this was successful however it caused problems with the stalling point of the motors as the battery voltage dropped off.
[attachment=40204]
Introduction
Project Introduction
Throughout the past 3 years of our Mechatronics degree at Massey University we have gained knowledge in areas such as: mechanical, electrical, software and electronic engineering. We have in particular focused on: motion actuation, sensing, signal processing and microprocessor control. For the paper Industrial Systems Design and Integration we were required to combine and demonstrate these skills by means of a group project.
This year the project was to design and build a Fire-Fighting Robot. The robot was required to move around obstacles and detect and extinguish small fires, which were simulated by candles. The robots were required to be built by the end of semester one with a competition against the other groups as a final assessment.
As to building the robot itself we were also required to complete a report and web page for our robot. These were to give greater explanation of the design and construction phases of the robot as well as to visually show diagrams and
photographs of the robot we constructed.
Design
Design Overview
As with most projects the design stage of the project is very important. We were aware that decisions that we made early on in the project could have big implications later on regarding the overall success of the project. For that reason we made the decision to spend several weeks on the design stage of the project in order to ensure that we had covered all aspects of the project and come up with the most suitable design possible.
We decided to work first on the mechanical design aspects of the project. We adopted an open approach to design ideas
from the team. From these initial discussions we were able to quickly zero in on the best solution. We then moved on to
the other mechanical aspects of the project. We were initially less concerned with the electrical and control aspects of the
project as what controller we decided to use would have no impact on the mechanical portion of the project. We had been
made aware that often the teams left the mechanical aspects to the last minute which had resulted in a back-log of work
for the workshop staff. We therefore ensured that we got as much of the mechanical construction done as quickly as possi-
ble so as to avoid delays.
While we were working on the mechanical design and construction of the robot we were also researching the best options for the control and sensing aspects of the project. We took quite a lot of time to make final decisions on these aspects of
the project. As it turned out it was worth waiting to ensure that we got the right components. We had initially decided to
use a Microchip PIC-based microcontroller but after further consideration we decided to go with the cheaper and more
powerful Renesas M16C-based controller. This was a controller that Matthew had worked with during his summer job and so he was familiar with its use.
Having spent a lot of time designing the mechanical components we had very little difficulty with things not working properly. There were several minor components which we designed as the need for them arose. We all imposed high standards on our own work; this resulted in a well-built and reliable robot. This hard work in the construction of the unit would result in significant time savings during the testing stages, as we did not have the long down-times that some of the other teams experienced due to reliability issues.
Additions to the Design
There were a number of changes made to our original design which was of circular shape with a diameter of 200mm. We
mounted a second level as we required more room to place our circuit boards and our extinguishing device. This second
level was again 200mm in diameter and the distance between the two was 50mm. By adding a second level we needed
supports to hold the second level in position. W e used a “C” design for these brackets. W e then thought that w e could
mount the 3 distance sensors on these brackets, which would save making additional mounting brackets from the top level.
We also found we needed to increase the stability of the now two-level chassis. We thought of using ball bearings which
could be locally purchased but in order to keep cost down we designed and made skids for the front and back from material in the workshop. The skids were constructed from nylon and followed the shape of the chassis. If these skids did not work satisfactorily we would have purchased the ball bearing wheels.
From the top level we designed a holder for our fan (used to extinguish the flame). It was designed to be higher than the top level and be angled downwards on a slight angle to help with the extinguishing of the flame.
Implementation
We decided that it was important that we were able to get a full field of view in front of the robot. In order to get this we worked out that if we crossed our sensors over we would effectively have a screen; the areas where one sensor was unable to see would be covered by the other.
This layout also allowed us to see objects which were approaching from the front, along with those on the side. Since we wanted to take the same actions for both (turn away if possible) this was not a problem.
As mentioned the robot would turn away from upcoming walls as with equal importance to those on the side. We could effectively affect the priority it gave to each of these by altering the angle we had the sensors set on; pointing more forwards would mean that turning from an upcoming wall was more important than keeping a distance from a wall on the side. In the end we came up with an angle for the sensors which was able to meet both expectations along while still being able to detect smaller objects directly in front of the robot quickly enough to take evasive action.
With the sensors crossing over we were able to accurately detect objects which were within 200mm from the side of the robot and 250mm in front. Any object needed to be within 70mm of a sensor for the reading to become unreliable. This
translated into being approximately 20mm away from the chassis of the robot, by which stage evasive action should hopefully have been taken.
One issue of the sensors themselves was that occasionally they would return a false reading, which was was often valued at
zero. To fix this we included a method (in software) which would average out the last five readings from the sensors. While
this reduced response times we found that it remained quick enough to avoid all but the smallest objects. This averaging
prevented the behavior “Escape” to trigger unpredictably, as it had before w e im plem ented the system . In an attem pt to
increase response times we added a linear weighting to each reading, the newest being five times more important than the
oldest.
Conclusions
The rounded chassis combined with the centrally located wheels worked extremely well for the robot and its ability to navigate the world in which it was placed. We encountered no problems using skids to provide support for the front and back of the robot.
After deciding to use a fan to extinguish the flame and testing its performance we were extremely happy with our choice, in fact our successes prompted other teams to abandon their original preconceptions to adopt our method.
After seeing the trouble other teams had with circuit design we were most pleased that from the start we chose to use keyed connecters as opposed to hard wiring external devices.
Our use of crossSense® worked extremely well for large oncoming objects yet had caused problems when objects were to the side, and had just been navigated past. It was able to detect the sharp or continuous upcoming obstacles so long as they had a reasonable depth.
The UVTron created some difficulty in that it was not originally direction sensitive, and thus required the addition of a custom designed shell. It was extremely reliable once we had completed this physical modification.
Using an M16 developer board to control our fire fighting robot made debugging a lot easier due to an on board LCD unit. Although programming the M16 using the supplied programming solution was slow and tedious, the micro itself was
reliable and presented no problems until a port was overloaded due to human error.
The control system we used was by far the most complicated part of our project; the behaviour control was a good choice to make, as it managed to simplify the process substantially. A major part of our control was using pulse width modulation to control the speeds of our drive motors; this was successful however it caused problems with the stalling point of the motors as the battery voltage dropped off.