timer after restart

[sciguy125]

I set up Timer 1 as a simple timer. I initialize it via a function called from User_Initialization() - that's what it's called right? It uses the internal clock and has the prescaler set to 1:8. I also set up interrupts to increment a counter every time the timer overflows. I also have it initialized to a value such that it overflows every 50ms. The interrupt routine that handles the counter also toggles rc_dig_out18. I've verified that it works with an oscope.

The problem is that it doesn't work after I reset the controller. It's fine right after programming. After a power off or pressing the reset button, the output doesn't change any more. I'm not sure if it's because the timer isn't working any more or if something happened to the output. I suspect the former, however.

Is there some difference between what happens right after a download and after pressing reset? I have a feeling that I need to initialize something somewhere, but I can't find anything.

[X-Istence]

My camera does not track anymore after a robot reset, the only way to get it to track again is to hit the power button, and restart it.

[bear24rw]

We have the same problem here on team 11 with out camera not tracking after a robot reset, we need to turn it off, turn it on, press reset before it works... does anyone have any ideas as to why this is happening?

[RedBarons]

I have experienced more or less random behaviors when hitting the reset button. For example, motors starting spinning for no reason. I also have a 50ms interrupt-triggered timer, and have experienced similar problems.

[Joohoo]

I have been told, that many times the reason that many robots do random things after an "unclean" shutdown or just after a weird start up is that not all the values get reset.I'm not sure if that is all of your problems it may be so for those without the camera. I haven't found any fix to the problem except just play it by the book and cross your fingers.

[Mike Betts]

I can not speak to the timer issue in this thread (I suspect your timer initialization routine is not complete). However:

The camera requires that the operator press and hold the reset button on the RC for 4 to 5 seconds for a reliable camera reset. This is true using both the 2005 or 2006 camera with any of 2004 or 2005 or 2006 RC.

The reset button on the RC must be used. The "RC reset" button on the OI will not work.

The results of power-on resets have been mixed. I have attempted to train our field team to always do a 4-5 second reset after they turn on the power.

Regards,

Mike

[Matt Krass]

Originally Posted by Mike Betts

I can not speak to the timer issue in this thread (I suspect your timer initialization routine is not complete). However:

The camera requires that the operator press and hold the reset button on the RC for 4 to 5 seconds for a reliable camera reset. This is true using both the 2005 or 2006 camera with any of 2004 or 2005 or 2006 RC.

The reset button on the RC must be used. The "RC reset" button on the OI will not work.

The results of power-on resets have been mixed. I have attempted to train our field team to always do a 4-5 second reset after they turn on the power.

Regards,

Mike

We've actually found a way in software to force a reset in under 2 seconds if the camera stops sending data, its also part of our initialization, so even if we have a bad power-up, the camera does come online, it simply takes a bit longer. I don't have specific code for you, I'll email Mark McLeod and ask him to post it when he has a chance, but it essentially clears out the involved variables and sends a few databursts to "wake" the camera, then re-runs the initialization packet sequence, it works pretty reliably for us.

[Mike Betts]

Originally Posted by Matt Krass

We've actually found a way in software to force a reset in under 2 seconds if the camera stops sending data, its also part of our initialization, so even if we have a bad power-up, the camera does come online, it simply takes a bit longer. I don't have specific code for you, I'll email Mark McLeod and ask him to post it when he has a chance, but it essentially clears out the involved variables and sends a few databursts to "wake" the camera, then re-runs the initialization packet sequence, it works pretty reliably for us.

Matt/Mark,

I'd love to see it (and, I'd imagine, so would many other teams).

Regards,

Mike

[Mark McLeod]

Sorry, I've been sick and out of it for awhile.

Here's the re-initialization we're using that Matt referred to. Nothing fancy, it's only a simple check for dropped communications packets, followed by a reset and reinitialization of both the camera and Kevin Watson's camera.c state machine. We don't use the tracking code, so you might need more for that. A normal initialization takes 1.2 seconds, however, since we don't know how long power can be interrupted and because some states are funkier than others, we continue to periodically attempt to initialize the camera as long as it's not responding anyway.

Re-initializing doesn't help the roughly 1:30 chance the camera won't power up in any kind of state to communicate. For both that and the regular case we use rapidly blinking LEDs to indicate the camera has not (yet) initialized, because the camera LEDs can be in any state and aren't a good indicator of a hangup. The blinking LEDs are easier for the drive team to identify a camera initialization problem.

We tested this by repeatedly pulling the power connection for the camera, cycling the RC power, and mounting the camera on a jigsaw as a vibration source.

This file doesn't include checks we added for invalid and incomplete T packets we see periodically that can also affect results.

I forgot this was an rtf. Here's the true txt version.

[Mike Betts]

Mark,

Thank you. I am sure that many teams will find this useful.

Mike

[Mike Betts]

Back to Phil's first question: I just checked and we are initializing TIMER 1 almost exactly as outlined in the Timers White Paper.

Mike