The Gibbot - Revision history

Nelson Rosa at 09:19, 16 January 2013

2013-01-16T09:19:07Z

Nelson Rosa: /* Smart Wall */

2013-01-16T09:07:41Z

Smart Wall

Nelson Rosa: /* Main PCB Design */

2013-01-16T09:06:02Z

Main PCB Design

Nelson Rosa: /* Robot Frame */

2013-01-16T09:03:38Z

Robot Frame

Nelson Rosa: /* Power Module */

2013-01-16T09:02:37Z

Power Module

Nelson Rosa: /* Robot Frame */

2013-01-16T08:58:41Z

Robot Frame

Nelson Rosa at 08:55, 16 January 2013

2013-01-16T08:55:44Z

Nelson Rosa at 08:54, 16 January 2013

2013-01-16T08:54:29Z

Nelson Rosa: /* Robot Frame */

2013-01-16T08:30:58Z

Robot Frame

Nelson Rosa: /* Robot Frame */

2013-01-16T08:29:21Z

Robot Frame

← Older revision		Revision as of 09:19, 16 January 2013
Line 1:		Line 1:
	Question to the group: Where should we host the project? (Google Docs, ~~DropBox~~, GitHub, Google Code, SourceForge, etc.)		Question to the group: Where should we host the project? (Google Docs, Dropbox, GitHub, Google Code, SourceForge, etc.)

	Below is a list of projects. Each project will have a team lead responsible for keeping everyone on track. We also ask that everyone is constantly documenting their work and that they develop a test suite along with their deliverables. The tests should include operation under “normal” operation, bad operating conditions (how do you gracefully recover?), and really bad operating conditions (how will the system persist without your module? What are the redundancies in the system?).		Below is a list of projects. Each project will have a team lead responsible for keeping everyone on track. We also ask that everyone is constantly documenting their work and that they develop a test suite along with their deliverables. The tests should include operation under “normal” operation, bad operating conditions (how do you gracefully recover?), and really bad operating conditions (how will the system persist without your module? What are the redundancies in the system?).

← Older revision		Revision as of 09:07, 16 January 2013
Line 46:		Line 46:

	==Smart Wall==		==Smart Wall==
	We need an alternative form of position sensing for the robot beyond a camera. An alternative that we believe would work is to wire LEDs (1- or 2-inches apart) on the steel sheet. The robot would then pick up a pulse-encoded signal from the LED telling the robot where it is. Constructing the smart wall isn't a problem, it's maintaining it. If we look at 2-inch spacing, then for a 48 sq. ft. wall we are looking at 1,728 LEDs. If one burns out, how will an MSI employee find the LED and replace it with ease? ~~Can~~ you come up with a better design for a backup sensor that does not rely on conventional wireless communication?		We need an alternative form of position sensing for the robot beyond a camera. An alternative that we believe would work is to wire LEDs (1- or 2-inches apart) on the steel sheet. The robot would then pick up a pulse-encoded signal from the LED telling the robot where it is. Constructing the smart wall isn't a problem, it's maintaining it. If we look at 2-inch spacing, then for a 48 sq. ft. wall we are looking at 1,728 LEDs. If one burns out, how will an MSI employee find the LED and replace it with ease? If this problem is intractable because of scaling, can you come up with a better design for a backup sensor that does not rely on conventional wireless communication?

@@ Line 30: / Line 30: @@
 ==Main PCB Design==
-This project involves improving upon the existing PCB, for example, better connectors between components, moving the H-bridge onto the actual PCB board, and integration of modules from other groups.  There are various important control and data signals running across the PCB, but the signals are not easily accessible.  The redesign should include breaking out certain signals (e.g., sensors) for easy debugging on an oscilloscope.  We also need a good characterization of the on-board sensors.  How long can we rely on the sensors for tracking the robot before there is too much error accumulation.  The PCB currently has a current sensor, position sensor, gyro, accelerometers, and an XBee onboard.  Are these parts easy to maintain and replace?  Are there better variants out there?  We also want to record data to an external Flash card for data logging and send info back to PC through wireless.  When transmitting to the PC, the user should have a way of (securely) controlling the robot remotely and querying it for useful information.
+This project involves improving upon the existing PCB, for example, better connectors between components, moving the H-bridge onto the actual PCB board, and integration of modules from other groups.  There are various important control and data signals running across the PCB, but the signals are not easily accessible.  The redesign should include breaking out certain signals (e.g., sensors) for easy debugging on an oscilloscope.  We also need a good characterization of the on-board sensors.  How long can we rely on the sensors for tracking the robot before there is too much error accumulation.  The PCB currently has a current sensor, position sensor, gyro, accelerometers, and an XBee onboard.  Are these parts easy to maintain and replace?  Are there better variants out there?  We also want to record data to an external Flash card for data logging and send info back to PC through wireless communication.  When transmitting to the PC, the user should have a way of (securely) controlling the robot remotely and querying it for useful information.
 <!-- Deliverables: PCB should be able to interface with rotary sensors, gyros, and accelerometers.  There should also be a data logger to external flash present, so we can record and playback sensor info for debugging.  Designer needs to also make sure that PCB modules of other projects will fit into PCB design and that modules can be easily tested.  Documented library of functions with example code on usage.  Documentation should also include resolution of sensors and conversion from sensor units to real world units.
 Milestone: PCB components, size, and locations should be finalized.  Final sizes should be given to the Frame project.  Additionally, module sizes of other projects should be given to the respective module designers.

@@ Line 17: / Line 17: @@
 * motor selection and modeling
 * frame design, especially passing power, data, and control signals across the two links
-* powering the magnets which have to be attached to the wall while the robot rotates about its pivot point
+* powering the magnets which have to be attached to the wall while the robot rotates about its pivot point; assume we are using electromagnets.
 While you can assume that the robot will have some netting or soft landing material underneath it in the event of a fall, the frame should still be strong.  The robot should be expected to tow up to 10 lbs, including its own frame.  The rest of the weight will come from the batteries, motor, and electronics.  With this load, the motor should be selected so that the robot can still swing uphill.  Is it possible to design a clutch mechanism?  For the winter term, we would like to see a base frame constructed with a motor and magnets fully operational.  We would also like to see the motor have its own PCB module.  The module should have an H-bridge, encoder and current sensing circuitry, and perform simple PID tracking of trajectories.

@@ Line 4: / Line 4: @@
 ==Power Module==
-Build the charging station consisting of two metal pads, electrically isolated, with a smart charger on the back side of the wall.  For now assume you are charging the 11.1 V batteries we have in the lab.  The design challenge is in robustly delivering the power to the robot.  A few ideas are:
+Build the charging station consisting of two metal pads, electrically isolated, with a smart charger on the back side of the wall.  The design challenge is in robustly delivering the power to the robot.  A few ideas are:
 * the wall has telescoping power leads to reach the robot.
 * the robot has two spring-loaded contacts (springs, ball bearings?) to slide along the wall and make contact with the pads.

@@ Line 14: / Line 14: @@
 ==Robot Frame==
-We want to build a larger version of the Gibbot.  The links should be between 12-18 inches.  Currently, everything is pretty cramped inside the robot and we will need more space if we want to lug around a higher capacity battery.  We are considering using two 22.2 V, 1 lb Li-Po batteries that are 145 x 45 x 35 mm (5.71 x 1.77 x 1.38 in) that can supply up to 45 A continuous current.  This project consists of three very important components:
+We want to build a larger version of the Gibbot.  The links should be between 12-18 inches long.  Currently, everything is pretty cramped inside the robot and we will need more space if we want to lug around a higher capacity battery.  We are considering using two 22.2 V, 1 lb Li-Po batteries that are 145 x 45 x 35 mm (5.71 x 1.77 x 1.38 in) that can supply up to 45 A continuous current.  This project consists of three very important components:
 * motor selection and modeling
 * frame design, especially passing power, data, and control signals across the two links

← Older revision		Revision as of 08:55, 16 January 2013
Line 1:		Line 1:
	Question to the group: Where should we host the project? (Google Docs, DropBox, GitHub, Google ~~code~~, SourceForge, etc.)		Question to the group: Where should we host the project? (Google Docs, DropBox, GitHub, Google Code, SourceForge, etc.)

	Below is a list of projects. Each project will have a team lead responsible for keeping everyone on track. We also ask that everyone is constantly documenting their work and that they develop a test suite along with their deliverables. The tests should include operation under “normal” operation, bad operating conditions (how do you gracefully recover?), and really bad operating conditions (how will the system persist without your module? What are the redundancies in the system?).		Below is a list of projects. Each project will have a team lead responsible for keeping everyone on track. We also ask that everyone is constantly documenting their work and that they develop a test suite along with their deliverables. The tests should include operation under “normal” operation, bad operating conditions (how do you gracefully recover?), and really bad operating conditions (how will the system persist without your module? What are the redundancies in the system?).

@@ Line 41: / Line 41: @@
 <!-- ==Wheel Carriage (1 person)==
 Build wheel carriage prototype.  If it works well think of integrating it into the gbot design for spring term. -->
+==The (current) Gibbot==
+We would like to get the Gibbot doing gymnastics on the wall.  What can we actually do with the current version of the robot and how can we use what we know about it to guide the next iteration of the robot for the MSI?  This project will require building a model of the current robot and identifying the limitations of the current design.
 ==Smart Wall==