Team Eight/Final Paper

Mechanical Design

1. Mechanical design should be as simple as possible, minize the number of moving parts

2. Pay special care to the mounting and connection. Bump sensor should be mechanically mounted on the corner. Never use glue until you have no option.

3. Circular design is a mandatory requirement for this project. Turning and search could be much fun with circular chassis.

4. Center of mass should be placed as near to the wheel as possible between two axis to avoid tilting problem during manuvuering.

5. Binding post is good choice for non-driving moving joint.

6. Plastic caster, blue rubber wheel provided by staff are reliable for any use. Cut your own acrylic wheel with large teeth and buy reliable ball caster from McMaster

7. Test , test early. Mechanical design is difficult to change near the end.

8. Bearing is necessary for rotating shaft with loading.

9. Square bracket could make life much easier. Procure lots of them at the beginning of the project and design the mounting/connection around the bracket.

10.Use lithium battery to reduce weight.

11.Think about gear installation from the beginning. It's much harder later to incorporate gears.

12.Choose multilayer design versus single layer design.

13.Use epoxy for motor-chassis mounting and wheel-motor mounting, mechanical mounting is not enough for high vibration, high torque connection.

14.Place the camera very far from the front and design a very strong and adjustable housing for the camera.

15.Use acrylic glue for acrylic board, it makes like much easier

16.Manufacture a small test chassis with only wheels, motors and necessary sensor for EECS team to test navigation/vision. Communicate frequently with EECS engineers to know their requirement in terms of sensor mounting/orientation, device housing and navigation strategy requirement.

17.Add side wheels to enable the car to move when hitting the wall

18.Don't add any robotic arm design, it's difficult to incorporate with software

19.Drill more holes on the body for adjustment and circuit wire arrangement.

Electrical Design -Motor Controllers

Four motors were required in our design. For the two DC motors that powered the wheels, we controlled them with Arduino via a qik 2s9v1 dual serial motor controller. For the servo that was used to throw the balls over the wall, we used the PWM signal from Arduino to control it directly. For the DC motor that powered the ball-collecting rubber band roller, however, since the analog output of the Ardruino is no larger than 5V whereas the voltage needed to drive the motor is 12V, we needed a control circuit. What we did basically was to employ an NPN bipolar transistor as a switch that was controlled by a PWM signal from the Arduino. One good thing about the PWM signal is that, by changing the duty cycle, we could change the saturation current of the transistor, thereby controlling how fast the roller rolled.

-Sensor Choice a. Bumpers

As an initial attempt, we used three bumper sensors in our design in order to carry out tasks such as stuck detection and aligning the robot with the wall before throwing the ball. However, as we soon discovered, bumpers were not as effective as we had expected. For one thing, bumpers broke easily when the robot collided with the walls. For another, sometimes bumpers got triggered when the robot were walking next to a wall, giving false stuck alarm. Therefore, we ended up with no bumper sensors at all. Instead, we detected stuck situations through image processing and dealt with wall-aligning jobs with IR sensors.

b. IR Sensors

One important feature of our robot was that it could follow the wall closely in a counter-clockwise fashion. In order to realize this, we used five short-range IR sensors in our design: two in the front, two on the right and one on the left. The purpose of these sensors was to detect whether there were walls in front, on the right or on the left of the robot respectively. We chose short-rang IR sensors over long-range ones because we wanted to keep the robot within 20cm from the wall, and short-range IR sensors were very sensitive at that range.

-Wall Following

Since the robot was to follow the walls in a counter-clockwise fashion, we had to make sure there was always a wall on the right side of the robot. Therefore, if the left sensor sensed a wall, the robot would need to make an 180°turn and went on the opposite direction so as to keep the wall on its right. If the sensor on the right sensed a wall, the robot could keep going in that direction and make minor adjustments according to how far it was from the wall. If the sensor in the front sensed a wall, then the robot needed to turn left. In our design, we actually put two short-range IR sensors on the right: one on the right front and the other on the right back. This is because we wanted to differentiate between two situations: there was no wall on the right at all versus the wall on the right came to an end. Under the the former situation, both IR sensors wouldn’t sense a wall, and the robot needed to go straight ahead until it found one. Under the later, however, there should be a certain period of time when the right front sensor failed to sense a wall but the right back one does. In such situations, the robot needed to make a turn to the right in order to continue following the wall. Also, in our design, there were two IR sensors in the front. One obvious advantage of doing this was that we could fulfill wall-aligning jobs with two sensors. Besides, we could achieve better wall following because they helped detect obstacles when the robot is half-blocked. One problem we encountered in wall following was that the robot tended to circle the green square obstacle on and on. We solved this problem by counting the number of right turns the robot made. If the robot made more than three right turns in a row, we forced it to go straight until it hit a wall in its front.

Software Design:

0) Development Cycle: Really need to coordinate with ME and EE people to start working with a prototype of a robot as soon as possible instead of hallucinating the whole architecture from the beginning. We could have won the competition if we had not wasted the first two weeks wandering around

1) Architecture: faster and faster!!! a) Vision: scipy.weave to embed c code b) Control: Arduino code to navigate with sensor information c) Logic: use pipe instead of queue for multi-process. Remember multi-thread in python is an illusion...

It took us three weeks, five versions of coding, to realize that this may be the best conmbination.

2) Test: If we had just one more day to test....

The full verison of source code is on https://github.com/Eminemya/maslab2012. Happy hacking

Stability of 5V power supply

The very first problem in our circuit manifested when we observed that the IR sensor works fine when the robot is stationary but freaks out when the robot is running around. By observing the 5v input voltage for IR sensor with oscilloscope, we discovered that it fluctuate as the motors are running. The supply voltage occasionally drops to 2v, which is way below the working voltage of the IR sensor. By reading datasheets of various parts in the circuit, we found out that the voltage regulator should be collected in parallel with capacitors at both input and output end. The capacitors effectively filtered out the high frequency part and insured steady voltage to the IR sensor.

Motor current limits

Initially we burn out motor controller frequently. It was due to the fact that the motor draws current directly from the motor controller, which supplied a voltage of 12v. When the robot get stuck, the effective resistance of the motors dropped drastically, hence the current increases and burnt the motor controller. Initially, we tried to fix this problem by adding a resistance in serial with the motor, so that the current will not get too high even if the motor is stuck. However, this can be problematic as well. Since the ground for the robot is not perfectly flat, it get stuck occasionally. The effective resistance of the motor drops and much less voltage is applied upon the motors. Therefore, the torque provided by the motor is then weakened drastically and the robot can never get out of stuck. The solution to this problem was sort of hilarious. We managed to get two motors with high static resistance so that the current will not surge above the limit of the motor controller while stuck and yet maintain high output torque.