Design Rationale

Control over trajectory arc
Allow for variable strength during tuning phase
No need for fast motor to provide throw force, use potential energy from elastic instead.

Having a physical mechanical stop is necessary to transfer as much of the potential energy into the throw as possible
If we simply released the winching motor, the spring would backdrive the winch and we lose lots of energy.
Using a motor with limit switches allows us to get enough force to move this without using timing.

Works in conjunction with the latch. This allows us to only have to worry for the pulling back, and not releasing (on this component).
Can pull all the way back with a high torque motor.

Single servo can control both bean bags, as they will be put in sequence and we can use half-steps.
Assume that the catapult is in reset position -> Don't have to mount the mechanism high.

Can mount motor away from actual wheel position.
Control over gear ratio and speed
Using a chain instead of a belt or gears gives us lots of reliability in driving.

Allow any command with a single button.
- Essentially, we have a server that can issue commands to any serial connected device, and the actual action depends on the implementation on the microcontroller.
- This lets us debug easily with a direct serial connection from Arduino to a laptop, and seamlessly move that wireless when needed.
Using a webserver allows us lots of high-level logic, and compatibility. If our main laptop dies for instance, we can switch to another computer or even a phone without trouble.
This also gives us access to a keyboard for control, so we don't need specific hardware code for a joystick for example (use virtual, or WASD).

Allows remote operation without looking at field
Use existing software to reduce development time, debugging, and reliability.
Tradeoff: Because we mounted the camera to the front facing forward, we had no visual feedback of the status of the robot's components -> rely of sensors.

Google Sites

Report abuse