Monday, December 9, 2013

ADC Working

Resources
The file single_ended.c, which is an ADC example created by TI. It was included with the Code Composer download.
I used this link because they also had multiple sensors that needed reading
http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/200521.aspx

I used this piece specifically:
ADCSequenceStepConfigure(ADC0_BASE, 0, 0, ADC_CTL_TS);ADCSequenceStepConfigure(ADC0_BASE, 0, 1, ADC_CTL_CH0);ADCSequenceStepConfigure(ADC0_BASE, 0, 2, ADC_CTL_CH1);ADCSequenceStepConfigure(ADC0_BASE, 0, 3, ADC_CTL_CH2);ADCSequenceStepConfigure(ADC0_BASE, 0, 4, ADC_CTL_CH3);ADCSequenceStepConfigure(ADC0_BASE, 0, 5, ADC_CTL_CH8);ADCSequenceStepConfigure(ADC0_BASE, 0, 6, ADC_CTL_CH9 | ADC_CTL_IE | ADC_CTL_END);
I was accidentally putting "ADC_CTL_IE", which is an interrupt flag, on each configure step. So it would read the first voltage correctly, but the other ports were reading strange results.


Setting up PuTTY 
This is used in order to read the digital numbers. 
https://docs.google.com/document/d/1vS1P7lHgfN0qNN-VUYzAmbf1uEs35KgN65zdVGpilhs/edit?usp=sharing


UART and ADC code added to existing code
https://docs.google.com/document/d/1jRJDIFJe60oUCF9FxPxIToOBODayL5LCVNqKEs4tatw/edit?usp=sharing


Below are pictures of ADC working

The list below explains the voltages used
Sensor 1: 0.5V
Sensor 2: 1.0V
Sensor 3: 1.5V
Sensor 4: 2.0V
Sensor 5: 2.5V



Next, I put each one to 0V. For the last two samples, all of the power supplies were set to zero.



Lastly, I connected all the ports to the same power supply


Sunday, December 1, 2013

11/25/13 Update

Last official meeting for the semester

Monday (12/2/13) students are supposed to attend Friday classes, so if people are able I would like to have an unofficial meeting that day.

We discussed maze mapping and what the different types of data that will need to be stored.

https://docs.google.com/document/d/1Wu7waLjxTljn7O5gQABQTvZVNVyDUbZHxnj9jpVSczc/edit?usp=sharing

My friend, Brad Berger, he was pursuing a computer science degree for about 2.5 years and I've started to bother him about maze solving pseudo code. Below is a link to my notes about his recursion function:

https://docs.google.com/document/d/1p5ur2zxr1kikKd2vrjDfMCA7L8vXMStbqWzvAuT4IoI/edit?usp=sharing


Picture Time

George soldered the motor's wires sorter and made them very professional looking.



Here's a picture of the washer (silver part in red box), so now the bolts do not rub against the green wheels.


Here's a picture of the IR LEDs


Tuesday, November 26, 2013

11/22/13 Update

Meeting with George Sullivan

When testing the motor functions, the motor was getting warm again. We think that having the high pulse on for too long and/or having a small step frequency was heating the motor up. This should be verified by a professor who is more familiar with motors.We reviewed the data sheet for the motor driver, specifically page 6 http://www.ti.com/lit/ds/symlink/drv8805.pdf In the table it says that the smallest high pulse can be 1.9 microseconds. We tested 40, 30, and 20 in the SysCtrlDelay function and got the high pulse duration pretty small but not exactly 1.9 us. Before, in the sysctrldelay I was using 15625 which corresponds to 266.5 Hz or 3.752 ms. Below is a doodle:


Using an example George found online and the TI's example with Code Composer, we got the UART working. George explained how some of the ADC example code was working, but we didn't have time to debug everything Friday. In the picture below, I was trying to get the ADC to work. I think the 300ish number is representing a very small voltage.


11/18/13 Update

On Monday, Micheal Feller set up the LED IR sensors and tested some resistor values on bread board. More resistor values are needed for further testing. We want a large range for the output voltage. For example, the IR sensors that come in a package (http://www.karlssonrobotics.com/cart/infrared-proximity-sensor-short-range-sharp-gp2d120xj00f/) have a range of 0V to 3V. Later we can create some graphs for future reference. 

Also on Monday, Garrett Barbour tested the DC-DC converter on the motors. The converter can only output up to 1.5A but each motor needs about 1A, therefore an additional converter will need to be purchased. Other than that, the converter works perfectly for one motor.

John Desaulos suggested a better method of attaching the motor with the bolts. As of Monday, the bolts were rubbing slightly against the wheel's lettering and the wheel was slowly unscrewing the bolt. He suggested cutting the bolt shorter with bolt cutters. On Wednesday, I went to Home Depot and the hardware department person suggested using a washer to space the bolt away from the wheel versus using a bolt cutter or a saw and cutting it. Since it was the cheaper and faster method, I bought some washers and so far they seem to be working fine. If the washers become a problem, we can revisit the idea of cutting the bolts.

The new chassis was finished Monday and everything seems to fit nicely.

Things to do:
-The wheels need to rotate smoother
-Have robot complete all four motor functions correctly
-Calculate 1 block distance forward and backward
-Play with left and right motion

Tuesday, November 19, 2013

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.

Wednesday, November 13, 2013

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.

Tuesday, November 12, 2013

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

Thursday, November 7, 2013

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


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.

Tuesday, November 5, 2013

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.

Sunday, October 27, 2013

10/23/13 Update

Meeting on Wednesday with George Sullivan

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

Problem: Stepping down 9V to 5V for the motor.

Voltage divider using resistors
Based off the multimeter the stepper motor pulls about 1.1A on a 5V rail. In the calculations we set the current to 1.5A just to be safe. This method uses a lot of power. The battery would only be able to power one motor for about 15 minutes. So we turned back to buck converters.

Buck converter package
The problem with buck converters is that some require additional pieces, so we had to find something that already had everything together. George found this one: http://www.digikey.com/product-detail/en/V7805-1500/102-2171-ND/2352130 It satisfies our 5V and 1.5A requirements.

Software
We broke down all the things we would need to program for the microprocessor into a program map. Now one to two people can work on each block of code. George showed me how to make a function for the forward motion. I'll work on the three other functions for the backward, right, and left action over the weekend and Monday.

Real Time Operating System
On the second page of the notes, George was explaining how the RTOS works. He said that if a function accidentally has an infinite loop, the program will never be able to get back to the main loop and do any future functions.

Chassis
The chassis was 3D printed Friday. It should be ready for pick up Monday before we meet at 4 PM. Also, I'm asking the HKN treasurer if we can have about $40 so we can get a moving mouse soon.

Saturday, October 26, 2013

10/21/13 Update

Software & Mechanical
On Wednesday, I met with George who helped me set up CCS for the Stellaris. We got some sample code from TI's website working; just basic blinking LEDs. Then, instead of toggling the LEDs, I changed it to a toggling output pin, making a basic voltage square wave come out of the pin. Finally, I attached the Stellaris and motor to the motor driver and I was able to get the motor to step very slowly. 

The motor was getting hot very quickly. Originally, we drove the motor and motor driver around 400 Hz and a 5V to 0V square wave with the function generator. The Stellaris was inputting a 3.3V to 0V square wave, therefore that didn't seem to be the cause of the heat. The frequency in the Stellaris code was increased in order for the motor to rotate smoother. This seemed to fix the heating problem.

Stellaris Help
There are senior design meetings Monday from 8 to 11 AM (I think this time is correct) and Wednesday from 2 to 5 PM in Zachry 111B and 111C (senior design labs) near the equipment room. The TAs are covering the Stellaris and code composer. Whenever they aren't busy with their students, Dr. Villareal said we could ask them our questions.

Funding
Dr Villareal is asking companies and his associates if they are willing to help fund our project.

Monday, October 21, 2013

10/14/13 Update

Software - Still trying to fix the missing header file issue with the Energia environment. 

Some of the members attended the IEEE workshop and learned some basics about the MSP430 and Code Composer. A switch to CCS is up for debate. 

Mechanical - Finalized the file. We made sure that everything was inputted correctly. 

Front: http://i.imgur.com/uK0acG7.png
Back: http://i.imgur.com/auCvphv.png
Everything together: http://i.imgur.com/zgEYd9p.png


Friday, October 11, 2013

10/7/13 Update

Mechanical - Added in section on the chassis for the motor drivers. The motor drivers will require a breadboard to attach wires. Added sections for infrared LED detectors.

Software - Still cannot get some basic code to work and we need help with the libraries. The basic code simply makes the motors spin, but there were errors. Unfortunately, one of the more experienced software members could not make it.

There is an IEEE microprocessor workshop next week. The meeting will help members learn some basics with the MSP430 and Code Composer. At the end of the session, we will be able to ask the mentors questions about our concerns and for advice.

Friday, October 4, 2013

9/30/13 Update

9/23/13 Update
We just kept working on our projects; nothing too new happened. 


9/30/13 Update
The sessions are pretty good; a few volunteers are still coming. 

Chassis:
We have almost finished designing a chassis on Inventor for a prototype. I just received the 3D printing form from Dr. Villareal. 

Software:
A few guys are working on the MSP430 and a few others on the Stellaris that Dr. Villareal let us use. The pin out for the motor driver and how to connect it to the Stellaris has been determined. They attempted to upload some code to the Stellaris, but were not able to. The next step is to determine how to get the code onto the board, as well as discovering what libraries are need. Lastly, they will further work on developing an algorithm to solve the maze.

Motor Driver Testing: 
The motor driver was tested and the signal was analyzed on the oscilloscope. They found that the output was the correct signal and that the driver was working properly. They have suspicions that the driver was being driven incorrectly in the past. The next step is to try to get the driver to work efficiently with the motor and to test and improve the motor driver.

Monday, September 23, 2013

9/16/13 Update

There were a few less volunteers today, but tests are coming up.
I tried to get everyone onto the google drive; dont want to lose code/files like last time
The first report due Monday by 11PM

Mechanical:
We sketched some ideas for a "holder" to place everything on top
We decided to have the wheels attached directly to motor; this will require new wheels with a larger diameter.

Software:
A few worked with the MSP430 and some with Stellaris (a new microprocessor from Dr. Villareal)



9/9/13 Update

There were quite a few of us today, a lot of volunteers showed up. We reviewed where we were so all the volunteers were on the same page. Then we split into two groups; one working on software and the microprocessor, and the other group looking at the motor mount.

The mechanical group's goals:

-Method to attach the stepper motor; possibly have axle horizontal instead of vertical like in the kit
-Need some sort of holder to hold everything to get a prototype going. Would need to hold MSP430 launchpad, motors, motor drivers, wheels, sensors

Things we may need:

-bigger wheels
-more LED sensors

Software Group's Notes:

-Possible flow chart to help write maze solving code
-Experiment with uploading code to MSP430
-Get everyone to read and get familiar with the code

Other updates:

-For the next meeting, I will make a sign-in sheet, this way I can keep track of which volunteers stick around
-The president of HKN informed me that their budget is tight and that I need to write a proposal for funding
-I talked with someone last week about getting Inventor or Solid Works on the 225A computers

9/2/13 Update

--Microprocessor

Instead of using the MSP430, possibly change to an Arduino for more user-friendly coding. Then we can have a prototype sooner and start test runs.

--Motor Types/Options

DC Motor: has a counter on the axle but isn't very good
Stepper Motor: very accurate internal counter
Continuous Rotation Servo Motor: good torque and position reading

--Motor Shield

Needed for potential new motors. The example has extra stuff that we don't need (ex:http://www.sainsmart.com/starter-kit/mega-r3-starter-kit/sainsmart-mega2560-r3-l293d-motor-drive-shield-starter-kit-with-basic-arduino-projects.html)
Cost: Definitely less than $60

--3D Printing

Programs we may need: Solid Works, Inventor, or other AutoCAD versions
Need to know the printer's accuracy and what file type is acceptable

--Miscellaneous

First weekly report due 9/16 (if enrolled in the class)
Google drive called Micromouse - store code/files there for safe keeping
About 3 to 4 new volunteers might show up Monday

--HKN meeting notes

I attended the HKN officer meeting Tuesday night. They would like us to make a mini maze for demonstrations. Available funds still unknown.

8/26/13 Update

I emailed people and tried to see who was coming back this semester. The MSP430 and Seeley's completed code was returned. The sensor control code worked on last semester seems to be lost due to personal hardware failure. The maze solving code is lost, the person working on it never answered my emails.

A recruitment event was organized for the second week of school. Only two people showed up, but I got lots of emails from interested volunteers.

Monday, January 28, 2013

Semester Goals

Howdy! Tonight during our third semester meeting we are handing in our ideas about what we are to accomplish this semester and about what we learned these past few weeks that may help us in building our robot this semester. I look forward to seeing all class members this afternoon.