Registering for Micromouse

If you would like to register for Micromouse next semester and receive one credit hour, the information is below

ECEN 485 558 (CRN 20094)
ECEN 285 558 (CRN 20092)

I believe 285 is for freshman and sophomores, and 485 is for juniors and seniors. At least, that's how it worked last semester. Other than that, there shouldn't be any other differences between them. 


If you do not want to register and just be a volunteer, the meeting time next semester is 4:10 PM - 5:25 PM every Monday in ZACH 225A.

Wheels!

They fit perfectly!

11/11/13 Update

Most of the parts that I ordered come in. We have been slowly assembling the robot. I had a problem with receiving the wheels, but they should be here and on the robot by Monday (11/18).

We've noticed a few problems with the chassis and are considering redesigning and printing a new one. I don't have any tests this week or the next so I think I can do this Wednesday. I have some notes written down about all the little fixes that the team suggested. I can then email Chris Jones the .stl file and hopefully it will be ready for pick up Monday morning.

John Desaulos suggested that the Stellaris should be able to read analog signals and that we may not need to convert it to digital. So we will try it that way first. Michael Feller and two others researched example code online of the Stellaris reading analog sensors.

This week's IEEE Workshop is over ADC: http://ieeetamu.org/mcc/workshops/adc/ I did attend this workshop Tuesday and they said that it would be best to convert the analog signals into digital. So I'll bring up the argument again on Monday.

We will also need Stellaris specific UART example code. The IEEE Workshops did go over UART but it was for MSP430 http://ieeetamu.org/mcc/workshops/serialcommunication/

It seems that the DC/DC converter, that George found for the motors, can also be used for the Stellaris. http://forum.stellarisiti.com/topic/669-stellaris-launchpad-power-options/ This is really good because these are kind of expensive and bulky.

11/8/13 Update

Meeting on Friday with George Sullivan

Analog - Digital Converter: How it works

Written Notes: https://drive.google.com/file/d/0B-46Wb6HXkEETmJ6bXp4NjJ2UHc/edit?usp=sharing

The Stellaris has a 12-bit input/output range. So for the maximum voltage input (5V), it would output the number 4096 (= 2^12). Then for 0V input, it would output the number 0. The relationship is linear. Testing is need to verify this.

For example,
We are using two of these http://www.karlssonrobotics.com/cart/infrared-proximity-sensor-short-range-sharp-gp2d120xj00f/ on the sides. We placed it in the maze, in the middle of a block/square. We decided that 1V outputted from the sensor would be a good threshold for whether or not there was a wall in front of the sensor. Less than 1V means there's no wall, and greater than 1V means there is a wall. The highest output from the sensor is around 3V.

So 1V (outputted from sensor, inputted into Stellaris) would be about 819 (=(2^12) /5) outputted from Stellaris since the relationship is linear. We'll also need other thresholds in the future. If the mouse veers to the side, slowly running towards a wall, we can use the sensors to correct it.

Note: We want to avoid having the robot completely up against the wall. If the sensor is roughly less than 1cm away from the wall, the voltage drops. I say roughly because, when tested, all the sensors work slightly different, some will be better candidates. The datasheet on the second to last page shows their standard graph of voltage and distance. Using the 1V threshold, the robot would record this as no wall.


Mapping the Maze

Written Notes: https://drive.google.com/file/d/0B-46Wb6HXkEEWkZYUlU0SG9aeEU/edit?usp=sharing

In order to solve the maze and write the movement logic, first we'll need to figure out how to store the maze: break the maze into blocks, or walls. No matter the method, everything will have pros and cons.

Blocks
The robot would have to enter every single block on the maze to record if there are walls or not. This takes up time, but it would be easier to code and potentially solve.

Walls
Slightly different approach. We would want the robot to avoid redundantly exploring blocks where it has already recorded that wall, but from the other side. In videos, I've seen many robots skip over sections of the maze.

In the notes, George wrote down realistic problems that we may encounter when running the robot through the maze.


The Next Steps

ADC
- Write code to read the sensors
     - Assign pins on the Stellaris for the sensors
     - Read ADC values (function* see below)
     - Find/Test  ADC #s for important values
- Make UART/Serial debug connection for computer, so we can get a log of values displayed. We thought this would be a good way to verify that everything is working up to this point.

George drew a bubble map/flow chart in the notes.
Start with a move function, like move forward into a block, then in the middle of the block, read the sensor value. Read the sensor data (is there a wall or not, this would be the function* above) and store it in an array or vector of some sort. Next make a decision: should the mouse keep moving forward, turn left/right, or turn completely around. Finally, we are back to the move function.

Things that can be done without sensors in the mean time
- Make the robot go a path
- Figure out how long a block is (for now, breaking the maze into blocks seems to be simpler)
- Test turning & "1 block" motion to make sure motion & turning is consistent
- Start testing prototypes of mapping ideas

APEC Research

The different types of Micromouse competitions: http://micromouseusa.com/?page_id=23

Link to confirm the region we are in http://sites.ieee.org/local-sections-chapters/region-5/

Main website for Region 5 (which doesn't seem to be very informative about the competitions): http://ieeer5.org/

Link to the APEC Micromouse Contest (Which is the highest level in America) http://www.apec-conf.org/conference/participating-in-micromouse/

"APEC 2014 will be hosting its Twenty-Eighth annual Micromouse contest in Fort Worth, Texas. The contest will take place on the evening of Monday, March 17 starting at approximately 8:00 PM. It is not necessary for contestants to register for the conference in order to compete."

"The rules for the contest use a scoring system with a penalty for the time taken to map and run the maze, and a bonus for not touching the mouse ... The time for each contestant has also been reduced from 15 to 7 minutes. Within this time limit, the Micromouse may make up to 7 runs. Only one mouse per handler will be allowed this year." More specifically: http://www.apec-conf.org/wp-content/uploads/2013/10/Micromouse_Rules.pdf

Other goodies on the APEC Micromouse Contest website

Hotels: http://www.apec-conf.org/conference/hotel-travel/hotel-reservations/ Special rates for students if apec@courtesyassoc.com is contacted

A rough schedule: http://www.apec-conf.org/wp-content/uploads/2013/09/APEC_2014_Schedule_at_a_Glance.pdf

Different types of registration: http://www.apec-conf.org/registration/registration-whats-included/ 

After signing in with my IEEE member code, it showed three options 

Full Conference: $800

This registration category includes the following:

• Technical sessions
• Proceedings on USB
• Educational seminars
• Seminar workbook on USB
• Exhibition
• Social Event

Technical Session Only: $500

This registration category includes the following:

• Technical Seminars
• Proceedings on USB
• Exhibition
• Social Event

Educational Seminars Only: $400 

This registration category includes the following:

• Educational Seminars
• Seminar workbook on USB
• Exhibition

I have a feeling that we'll  be choosing the "exhibits only" option but it isn't available to click on until February 21, 2014. I will email apec@apec-conf.org and ask for more information.

11/4/13 Update

Some of the items that I ordered came in the mail and we attached them to the chassis Monday.

We discussed possible chassis modifications:
--buffer/slider on the bottom - There's only two wheels so the robot may wobble forward/backward when operating
--Velcro options for attaching the battery or other objects to the chassis
--screws/pegs for a more secured motor
--have the battery lay differently and then use a box cutter to make the mouse a little shorter
--acetone to dissolve the chassis material or use a file to shave off unwanted material if more room is needed

We briefly discussed infrared LED sensors. I purchased this http://www.digikey.com/product-search/en?mpart=IR7373C&vendor=1080 and this http://www.digikey.com/product-search/en?mpart=LTR-4206&vendor=160 They are pretty inexpensive.

I helped Wenjie Cao get CCS running on his laptop and I helped Michael Feller get the motor control code working on his laptop. 

The last IEEE workshop about serial connections will be helpful for us once we convert the analog sensors to digital using the Stellaris. The powerpoint and sample code is here http://ieeetamu.org/mcc/workshops/serialcommunication/

10/28/13 Update

The first thing we talked about was the SysCtlDelay function and how it works. The integer value does not seem to correlate to a linear frequency value. See excel sheet: https://docs.google.com/spreadsheet/ccc?key=0Au46Wb6HXkEEdEN2TXU1NU9HUDVTNk10aDBMUHRab2c&usp=sharing

Below are some things I researched:
http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/143842.aspx
http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/223839.aspx
http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/256106.aspx
Maybe try using com_sysctrldelay() instead, see if this is more accurate.

The next thing we did was talk about our next steps for programming.
--making the motor go a set path
--possibly have the mouse consider the maze made up of squares
--brief discussion of mapping/remembering the maze

The basic motor functions file finished Wednesday
--Here it is in the drive:
https://docs.google.com/document/d/1sPEHiAdNyChVj0hfdad3FLdOsYuANWOoqGi8X_L2XFY/edit?usp=sharing
--Under Micromouse > Software > CCS Header Files, I added the headers that I used. But if you download the examples from TI, you should already have these headers (and many more) on your computer.

Finally, the chassis was picked up Tuesday. I'll be buying supplies for the prototype thanks to the help of HKN. Hopefully we can construct some of it Monday.

Sorry it took me awhile to post this. I had a cold last week.