Re: Uhh
 

Not necessarily. Once we smooth out a few wrinkles with our INS, we should be able to sustain a hit of several G's accompanied by a rotation of up to 300°/sec without any ill effects to our autonomous mode.

OK I did some more testing in my lab.

When I did the previous tests I had the robot controller connected to the operator interface with the tether cable. In this configuration the link cycles when you tap the breaker that is powering the RC (and the OI).

I looked at the signal on the scope. The 12V drops to 5V for about 1mS.

Then I tried it again with the radio link instead of the tether cable. The Robot controller will NOT reset when the breaker is tapped or smacked.

This is good news. I opened the RC up and saw the same thing noted in someone elses post above - 1000uF cap on the 12V input.

So the RC is not what was resetting - it was the OI, getting its power from the tether cable.

So thats good for most teams - I have to correct my first post - further testing shows the breaker does NOT cause the Robot Controller to reset when impacted (in the normal configuration used on the playfield).

I believe another possible cause of our teams robot controller reseting in those two matchs is this: we have 4WD, and when we slammed the railing all four motors most likely stalled at the same time, probabally popping all four 40A breakers together. This might have been enough current surge to drop the voltage at the fuse box below the dropout voltage of the RC - causing it to reset when the 4 motor breakers opened and the voltage returned to normal.

Im not sure why our robot reset during automode the other time though - when we were pushed to the bottom of the ramp and hit by another robot. I guess it could be the same cause - the drive motors were stalled and the battery was putting out a large amount of current.

I dont think we have any loose crimps on our bot - we always made the pirate noise when we crimped terminals on the cables (RRRRRRrrrrggggggggghhhhhh!) - maybe we have a cracked fuse box?

I think Ill have all the students bring all the pillows from the hotel and we'll tiewrap them all around the bot for bumpers at our next event (Toronto) :c)

EDIT: I had said 'relay' when I meant 'breaker' -Ken

Never say "never" but good work on the testing. You mentioned relay several times in that last post, but I am assuming you were talking circuit breaker. I am still concerned that you were able to reset on tether but not with the radio. That still sounds like a high resistance connection or a lot of current on the OI side or something else. We have had a problem over the years with the little fuse holders on the side of the controllers. They are prone to break where the pin leaves the printed circuit board. (This is a problem when you have a lot of wiring run close by that side of the controller.) That break is very hard to find and diagnose, but the good news it is repairable. Innovation First will take care of it for you. Let us know if find anything else.

AL - thanks for the catch on 'relay' - I meant breaker - Ill will go back and edit last post.

When I did these tests in our lab I used a bench power supply (so I can see the current draw) and alligator clips on the breaker, RC power...

Its possible we have a squirrely connection still on our bot - but dont think there are any intermittant connections on the lab bench setup.

When we first started putting terminals on wires this year I made the pirate noise while I wrenched the crimper. As the students gave me a funny look (happens often) - so I explained if you dont make that noise, the wire will not stay in the terminal. Now all our sparkies make the pirate noise when using the crimper :c)

Also - we sheared the little round fuse on our RC this year when our battery decided it wanted to be 1" further forward than where we had it mounted. That RC is now on last years bot with a hand mod fuse attached.

We are using last years RC in the bot now. We asked the FIRST guru at Cleveland about this during the event, he said there would be no difference.

BTW - scuttlebutt is there will be a whole new control system next year (USB has finally caught up with FIRST?!)

looking forward to it.

-Ken

I know this is beside the point on your robot reset issue. However, in autonomous mode, you can and should write your current "state" to EEPROM and read it back on the next cycle. You have to make sure you clear it out when you transition out of autonomous mode.

We assumed that we would have a reset during autonomous operation and didn't want to experience the problems you described.

EEPROMS have a limited number of write cycles, something like a million?

I dont think you want to be writing to the EEPROM on every SW loop. When something is running at hundreds or thousands of loops per second, it doesnt take long to get to a million.

in fact, how could you program this? if your bot did not finish auton mode the last time you ran it, or got hung up for some reason - how would you reinitialize it the next time you WANT to power the bot up?

wouldnt it try to go back and start from where it left off last time?

how does the RC know if the reset was a glitch or a deliberate power on / power off cycle?

EEPROMs
 

A million cycles is a probably on the low end of actual times you can program an EEPROM, but even so, we have found ways around this problem in the past.

Even writing to the same address every time you can still run for over 400 minutes without hitting a million writes, large but not large enough, perhaps.

We used a few tricks.
#1, read the contents first, only write to them if there is a changed state.

#2 move to another EEPROM address as you wear out the "real" EEPROM address. Basically keep track of how many addresses you've worn out -- increment the index after you find a write didn't take. To see if you have "worn out" an EEPROM address, check the contents after the write command.

#3 Devote a programming slot to essentially nothing but this purpose. I have never run out of code space entirely. So, I always have a slot to burn (pardon the pun). Basically use a RUN 7 command to run to your EEPROM burning code and then at the bottom of the EEPROM burning code do a RUN X to get back to your regular code. If you have to burn up EEPROM addresses, better that they all be from the same programming slot -- once you've worn out an EEPROM address, it cannot be used for program space either -- this could be a problem if you burned up all the EEPROM space in slot 0 for example -- this would leave you with no way to even download code to jump to another slot -- an extreme example, perhaps, but not impossible.

Something like this should work fine:

ADDR_INDEX data 0
ADDR_STATUS data 0 (256)
'reserves 256 locations for your burning needs
'omit the zeroes above if you do not wish to overwrite the prior
'stored values when downloading new code
temp1 var byte
temp2 var byte
status var byte
do
'start of loop code
read ADDR_STATUS, temp1
read ADDR_INDEX, temp2
if temp1 <> status then write ADDR_STATUS + temp2, status
read ADDR_STATUS, temp1
if temp1 <> status then write ADDR_INDEX, temp2+1
if temp1 <> status and temp2 = 255 then gosub _EEPROM_Error
'rest of loop code
loop

While there are a lot of reasons not to write every time through the loop (it takes too much time being the biggest one in my opinion) a scheme like the above can effectively make your EEPROMs last forever (in FIRST time, at least).

Joe J.

P.S. the above code is right from my brain, I did not get our old code out or even check syntax on it. I believe it is sound, but make no promises. JJ

Ive been thinking about this EEPROM idea over lunch - its a cool idea

but taking two steps back, if your robot was reset during auton mode, then something drastic has happened to it:

- it got lost and smacked a wall

- it got nailed by a superiour being (a faster bot)

- you have a loose wire somewhere...

so given that you dont know what is going to cause the robot to reset during auton mode, you cant possible know what to do when your RC resets, except maybe shutdown and do nothing?

Error detection is one of those weird problems in engineering. Its usually very easy to detect than some sort of error has happened (like an unexpected reset) - and its almost always impossible to decide what to do next - except log an error message and shut down.

If you could anticipate the error condition, then you can program / design the system to expect it, and handle it the way you want - thats not an error condition anymore, its another variable in your more robust system's normal operation :c)

FYI, the BASIC Stamp Manual gives 100,000 as the number of writes per location for a BS2SX. (BS2e and BS2p are also given as 100,000. BS1 and BS2 are 10,000,000.)