Weekly report: 11/19/2009

Objectives

1. Put together a second board. Replaced, see below.
2. Test the communications system in conjunction with a signal generator. Met.
3. Get the “bug bot” system configuration working with the new board. Replaced, see below.

Notes
With the signal generation / filtering vetted I set up the prototype robot to use the custom PCB. I got the “Bug Bot” AI working on the prototype using the custom board, a major step towards a completed design.

During wiring of the collision bus I discovered several minor errors on the PCB. Two errors involved missing pull-up resistors and a third had to do with a mis-routed wire. I corrected all by cutting traces and hand-wiring leads. After these adjustments the boards seem to be fully working. I wired the board to the collision bus on the prototype robot and tested rudimentary bus communications.

I constructed the chassis and bus connections for a second robot. This one is a little cleaner than the prototype, with LEDs sunk into the plastic upper level, cleanly routed wires, etc. I am in the process of populating a second PCB (and applying the necessary fixes); when this is completed I will test the robots together and work on the firmware (mostly complete).

Objectives for next week

1. Finish populating the second PCB and mount on the robot.
2. Test “Bug Bot” AI on the second robot and on both robots in conjunction.
3. With the two robots, demonstrate inter-robot communication.

Weekly report: 11/12/2009

Due to unexpected obligations I did not post weekly report last week. This report covers the past two weeks.

I finished initial testing and debugging of a board with great success. I installed various firmwares to test all major components. I found one significant error in the design (that can be worked around with an additional, hand-attached wire) and several minor inconveniences, but no show-stopping flaws.

Due to cost I am not going to order a redesign of the board to fix the bugs found. I will hand-hack the existing boards for the actual robots.

I wrote the report and presentation on the special sensor (collision sensitive communications bus) and gave the presentation. I wrote additional firmware gearing up for the first full test of the communications system.

I was unable to test the communications signaling as I had trouble getting to the circuits lab (not the IMDL lab) when it was open. I was able to test most of the components at my house but I need access to a signal generator for the full test.

Objectives for next week:

1. Put together a second board.
2. Test the communications system in conjunction with a signal generator.
3. Get the “bug bot” system configuration working with the new board.

Weekly report: 10/29/2009

Objectives

1. Formalize the BOM. Met
2. Fill the BOM in preperation for the arrival of the PCBs. Met
3. If, by some miracle, the PCBs arrive, begin construction of one board. This and the subsequent debugging will certainly take the remainder of the week. Met, see below
4. Prepare the special sensor presentation on the contact bus / audio system. Postponed, see below

Notes
My first batch of PCBs arrived on the 25th and the components arrived on the 27th. On the 28th I began populating a board, enough to verify that one portion, frequency generation, is partly working.

I postponed work on the special sensor report as it was postponed for the class, and instead used the extra time to catch up on some other obligations while waiting for the PCBs and parts to arrive.

Objectives for next week

1. Finish populating and testing a board.
2. Record any necessary changes to the board and decide if it warrants correcting the circuit and ordering a second batch.
3. If I decide not to order a second batch, draw out the circuit diagram for any “hacks” to fix the board behavior.
4. Write the presentation on the special sensor.

Weekly report: 10/22/2009

Objectives

1. Wire the prototyping board in preperation for demoing obstacle avoidance next week. Met.
2. Assemble contact panels and limit switches. Met.
3. Tune up source code and test with hardware. Met.
4. Demo for the TAs. Met.

Notes
As shown above, all of this past week’s goals were met. I wrote a complete “Bug Bot” firmware that performs obstacle avoidance with the help of a software pseudorandom number generator (specifically a 32-bit linear congruential generator). Using bump switches and wire contact panels (see last week’s report) the robot was able to react to collisions on all sides.

I demoed the “Bug Bot” firmware for the TAs and passed the collision avoidance checkpoint. I had a slight setback when my rechargeable battery charger failed to stop charging, leaving me to wake up to a living room with battery acid, smoke, and melted plastic; one of the TAs (Mike) supplied me with a replacement battery holder, allowing me to demo succesfully.

Objectives for next week

1. Formalize the BOM.
2. Fill the BOM in preperation for the arrival of the PCBs.
3. If, by some miracle, the PCBs arrive, begin construction of one board. This and the subsequent debugging will certainly take the remainder of the week.
4. Prepare the special sensor presentation on the contact bus / audio system.

Weekly report: 10/15/2009

Objectives

1. Finish board layout. Met.
2. Send boards out for prototyping. Met.
3. Mockup contact-bus panels. Met.
4. When contact switches arrive, hook up panels and test collision detection. Not met, see below.

Notes
I finished the board design this week and sent out the boards for prototype production. I will be using the prototypes as my actual boards for cost reasons. I will use the IMDL lab resources (soldering iron, tips, solder, flux, etc) for board construction as my equipment is not precise enough for the surface mount components.

My simple design for the contact panels – aluminum foil attached to conducting coathanger segments – appears to be valid. It is lightweight and conducts with minimal resistance; the natural “crumpling” of the surface of the foil is a benefit, as it provides multiple contact points when two panels touch. My main concern is capacitance, because of the large surface area; how this impacts the design will remain to be seen. I have several work-arounds available if it does become a problem.

I was unable to connect the system for obstacle avoidance as the contact switches shipped late and have not arrived. They should arrive today (the date on this report), but UPS has traditionally had problems delivering to my address. I expect to have them by the weekend.

Important milestone change
I am not demoing my robot with electronics mounted this week, as I am currently waiting for the PCBs to arrive. I have verified this with the TAs and explained that I will demo next week (collision avoidance) with the development board, and then when the PCBs arrive and are constructed I will demo the completed system.

This change is not a delay to my schedule, but a consequence of my schedule being ordered slightly differently than the milestones, due to the specifics of my project.

Important note regarding required LCD panel
I am not going to include an LCD panel on my robots, due to cost. I don’t need an LCD panel, and I will ensure that sufficient LEDs are on-board so as to properly indicate the robot’s state and allow an observer to verify robot behavior. I verified this change with the TAs.

Objectives for next week

1. Wire the prototyping board in preperation for demoing obstacle avoidance next week.
2. Assemble contact panels and limit switches.
3. Tune up source code and test with hardware.
4. Demo for the TAs.

Weekly report: 10/8/2009

Notes
Unfortunately several significant scholastic and research commitments came up during the last week and my work on this project was delayed. I met the “electronics and base functioning” checkpoint, however, and am still on schedule.

The next checkpoint is obstacle avoidance. I have an order standing for limit switches that will arrive in a few days. The software to do obstacle avoidance is already implemented so it should be a “glue” process to make it work together to pass the checkpoint.

Until I send out my boards I will be unable to mount the electronics permanently, which hopefully will not be a problem for the TAs. I am also hoping to get an exemption from including an LCD screen on the robot. I do not need it for debugging purposes and it adds significantly to board space cost and monetary cost, as I am producing multiple robots. I will discuss this with the TAs and professors this week.

Objectives for next week

1. Finish board layout.
2. Send boards out for prototyping.
3. Mockup contact-bus panels.
4. When contact switches arrive, hook up panels and test collision detection.

Weekly report: 10/1/2009

Notes
Due to an illness and checkpoints required by the TAs, my original schedule was derailed. I spent the past two weeks writing the firmware for the robot, ordering parts, and in general making things work together.

The fundamentals of the firmware are in place. The drive train support is complete and tested with the servos to be used. The main firmware state machine is complete. Collision detection and opponent identification is written and will be tested when the required parts arrive. The audio “listening” system is written and tested with a fake signal (and will be fully tested after the boards to perform signal detection arrive).

I passed the “able to read sensors and control outputs” checkpoint by demonstrating PWM control as a function of ADC inputs.

I intend to pass the “robot frame constructed” checkpoint tomorrow. I purchased a “lazy susan” kitchen turntable; the two thin plastic disks can be seperated to provide two easily-cuttable layers upon which to base the robot. For the checkpoint tomorrow I cut one disk and mounted the servos to it. By laying the development board on top (as a demo) the robot prototype can drive forwards, reverse, and in circles until the fake signal (currently a potentiometer attached to the development board) is detected.

Objectives for next week

1. Finish board layout.
2. Write BOM.
3. Send prototype for signal generation and detection out for production.
4. Fill BOM.
5. Buy contact switches and test.

Control flow

I sketched out a flow-chart of control for the robot algorithm, shown below. There are two state variables:

• Mode: this state variable consists of a boolean mode flag that indicates whether the robot is offensive or defensive.
• Collision: this state variable consists of a boolean collision flag that indicates whether or not the robot is currently contacting something and a 4-element contact direction enumeration that indicates which of the four sides of the robot are making contact.

Scan: In this state the robot turns in a circle, listening for opponents. The threshold for detecting an opponent decreases with every turn.

Collision: This state is reached by an interrupt. The collision state variable is set and control returns to the interrupted state (which then transitions as indicated in the figure).

Bus detect: In this state the robot detects what it has collided with. The details of the contact bus will be described shortly.

Drive: In this state the robot is driving in a direction chosen by the scan routine.

DriveAway: In this state the robot is disengaging from a collision (without regards to scan direction).

Design proposal presentation

This is a 3-minute design proposal presentation I gave on Tuesday, September 15th, 2009.

Weekly report: 9/17/2009

Objectives

1. Finish board layout. Partially met, see below.
2. Research PCB manufacturing companies suitable for my desired process and resources. Met.
3. Present design proposal to professors and receive verification. Met.
4. Formalize robot algorithm, save for specific numeric calibrations. Met.

Notes
Board layout was not completed this week because of a change in the micprocessor package to be used and re-layout that had to occur after the manufacturer was chosen. After discussing with the TA in charge of the “senior design” lab, I decided to use a larger microprocessor package. I need to write a model for this package for the EDA tool I am using (Eagle).

I tentatively decided on Silver Circuits for board production. They specialize in one-off prototype production, produce ROHS compliant, lead-free boards at no extra cost, and allow some compartmentalizing. They also have low prices, which is very important for me. Furthermore they prefer to receive designs in Eagle’s *.BRD format and generate the Gerber files in-house. They also provide DRU files for rule-checking. This means that job submission will be fairly painless.

My presentation of my design was approved. Discussion with a TA yielded the decision to simplify the detection of opponents in the arena to a simple continous scan and memoryless decision about the surroundings, as opposed to my more complicated full-scan and stateful decision process.

The robot’s algorithm is formalized. When I clean it up somewhat I will post it on this blog.

Objectives for next week

1. Finish board layout.
2. Write BOM.
3. Send prototype out for production.
4. Fill BOM.
5. Write ADC code.
6. Test servo control.

(Next week’s objectives are optimistic; #3 and #4 may be postponed depending on how long #1 and #2 take, particularly since I would like to review my board layouts with the TAs before sending them out. I may also decide to produce the first prototypes on the “senior design” equipment to cut development costs.)