I hate this robot

8/9/2006 4:54:52 AM

we have a microcontroller board designed for LEGOs
we have a compiler that crashes on anything more serious than a syntax error
we're using a language that doesn't support macros, chars, or long integers
we have opamps that weren't designed for this application (one that could hit V- would be nice)
we have a TA who tells us not to follow the specification, sometimes. he's wrong half the time.
and we have a professor who doesn't show up to class.

wtf were they expecting in 2 weeks?

8/10/2006 3:01:49 AM

It also would have been nice if the manual had mentioned the limit on the number of processes I can start. I know I'm over it, whatever it is...

8/10/2006 3:32:19 AM

make it work.

8/13/2006 5:14:05 AM

another blog thread

8/13/2006 3:21:40 PM

is it the renesas M16C board?

8/13/2006 11:14:01 PM

it was mixed a couple renasas and the rest were Handyboards....renasas bots had DC motors(much quiter but slower motors) while the Handyboard bots had servos. I think I would have rather had a renasas board for the sneek attack on the block

In the end the renasas bots were screwed over because NCSU had an update overnite which corrupted all the renasas software rendering the bots useless for a refresh download....

8/14/2006 10:03:43 AM

ouch

when i took the class i had a handyboard bot, they were easier to program but not as fast or accurate as the renesas ones

8/14/2006 10:26:21 AM

Grades are finally up in Past Semester Grades on Packtracks. Looks like a decent curve

8/14/2006 8:12:06 PM

Definitely a nice curve. I bombed the second test and missed 2 homeworks and still ended up with a decent grade. I like Dr. Chow again.


I still have an issue with the ultrasonic range finder receiver. There seem to be two general approaches to this:
1) measuring signal strength with an analog input
- Send pulses.
- Measure how strong the received pulses are through the ADC on one of the analog inputs.
- Convert this value to distance and adjust your controller to slow down and stop.
2) timing pulses with a digital input
- Send a pulse, start a timer.
- Stop timing when an echo is received.
- Convert this time into a distance and make the robot stop.

From what I heard, it seems everyone was using the first approach. The TA even eventually told us to use an analog input. However, it was given that our signal path should be as follows:

receiver -> amplifying opamp -> half wave rectifier (diode) -> comparator -> digital input 7 (TIC3)

Designing the amplifying opamp circuit and comparator opamp circuit were requirements in the project. The presence of the comparator alone, ignoring the diagram showing a connection to digital in 7 (given as an example), suggests that we should have produced a digital signal - 1 for receiving an echo, 0 for no echo (or vice versa). This indicates to me that the first approach (timing pulses) should be used. In addition, several websites gave examples of code for implementing a sonar range finder on the handyboard and all of them timed pulses using a timer internal to the uC triggered with the TIC3 input.

Unfortunately, I was not able (and I don't think anyone else was either) to produce an edge detectable by the TIC3 input (digital in 7) or any other digital input using the 411 opamps we were given. The 411 can only output within about a volt and a half of it's negative supply, and even after sticking the output through a voltage divider I don't think we could produce both detectable logic lows and highs. The TIC3 input requires a detectable edge to be used to stop a timer.

I ended up using an analog input on the board for the output of the comparator. I consistently got about 3 values (out of 255) indicating pulse detected, and 2 other values for no pulse. If we had access through interactive C to a decent timer, this should have been enough to implement sonar by measuring the time for an echo. The only timer I could come up with was to read system time before sending a pulse and after receiving an echo ( while(noEcho){sleep 1ms} ). This did not work well. I measured between 2 and 5 ms for echos regardless of distance to the object if the object was close enough to bounce back a detectable echo. End result - the robot stops about 6" away from the box always, not good.

I think the 411 opamp is not the apropriate choice for the comparator in this circuit, and the handyboard is not documented well enough to use advanced features like starting and stopping a timer. A clearer project description (either "make sonar work however you want" or "this is the circuit we want you to use, design these two blocks and then use this circuit") would have been nice too.

/rant
discuss, if anyone still cares

8/18/2006 10:47:24 PM

to use the second method a timer would have to be implemented that ran a lot faster than 1ms. The problem I had was running a method withing a method. In other words while the robot was in a loop looking for a recieved signal it should also do what is supposed in following the line ever 100 ms. Basically if the loop to look for the signal was raised to pole ever .001ms then maybe a calculation could take place to stop the robot a little closer due to more accurate timing on when the pulse was sent and received. As far as my bot went I just sent out a pulse used an analog input to read the received signal and then timed a stop. I used 450ms before the motors would shut down. So send pulse---->see box---->run full speed for 450ms----->shutdown everything----->hopefully not hit the box. It seemed to work we were consistently getting within 2 inches...

8/22/2006 2:36:14 AM