Grabbing Output from Robot Sensors

[ranc]

Wait you have no while(true) or while(IsOperatorControl()) loops?
I remember leaving out said while loop and getting the same issue.

[1951-44U]

Well, we have those loops, but we have no others. We have Feed()'s within those loops, too.

Does the line "GetWatchdog().SetExpiration(0.1);" in the initializers do anything? Can I delete this?

[BradAMiller]

Originally Posted by 1951-44U

Well, we have those loops, but we have no others. We have Feed()'s within those loops, too.

Does the line "GetWatchdog().SetExpiration(0.1);" in the initializers do anything? Can I delete this?

That sets the expiration time of the watchdog timer. That means that it must be fed within 0.1 second (100 milliseconds) before it times out and the motors stop with the "Watchdog not fed" error message.

If there are any Wait() calls in your loop that are greater than 100ms, the the watchtog will also time out.

[1951-44U]

Can I SetExpiration at some ridiculously high number to get rid of the watchdog error?

[ranc]

You could use GetWatchdog().SetEnabled(0) for turning it off right before your long wait and then use GetWatchdog().SetEnabled(1) for turning it back on again when you're not initializing whatever you're initializing (i'm assuming your long wait is due to setup of some component)

[1951-44U]

I'll try that tomorrow. But I haven't a single Wait() in the program. ._.

Can I completely delete the GetWatchdog().SetExpiration() or completely replace it with the .SetEnabled()?

[ranc]

Yes I think you could just use set enabled to turn it off

[1951-44U]

We tried setting the Watchdog at SetEnabled(0), but still get the same problem. We set it at 0 in the initializers, in autonomous, in the operator function, and in the operator loop. Setting SetExpiration() at an impossibly high number had no success, either.

[1951-44U]

New development!

We tried instigating the Watchdog error while watching the serial output, and found something very interesting.

We could get output from the serial output (meaning that we got the printf values from the code in the serial output) and the sensors were working fine! Outputting data! But once we turned on the target console on the programming laptop (the programming laptop and the serial output laptop are separate laptops) everything STOPPED. Came to a STANDSTILL. No more output, nothing. The serial output stream seemed to FREEZE. That may be why the dog was barking.

But the data we received from the sensors are somewhat strange. The different printf statements mixed and mashed with each other, seeming to overlap. I can't make anything of the data because they overlap so often.

Any ideas?

[BradAMiller]

So when you had just the serial cable plugged in and no target console, was the data reasonable? Is the problem related to having mixed serial output?

[1951-44U]

I'm not even sure what the data was -- it meshed and overlapped, so the numbers weren't nicely and neatly in line with respective labels.

Example:
______ Turns
______ Position

It was like:

Turns0003054Position

It jumbled all the output.

[byteit101]

did you have \r\n at the end of the printf's? this is the new line sequence. if you have printf("part 1") (more code here) printf("part 2 \r\n"), it should output like this:

part 1 part 2
part 1 part 2
part 1 part 2
part 1 part 2
part 1 part 2
part 1 part 2
part 1 part 2
part 1 part 2
part 1 part 2

so you can see 1 and 2 as the numbers fly by instead of

part 1 part 2part 1 part 2part 1 part 2pa
rt 1 part 2part 1 part 2part 1 part 2part 
1 part 2part 1 part 2part 1 part 2part 1 
part 2part 1 part 2part 1 part 2part 1 pa
rt 2part 1 part 2part 1 part 2part 1 part 
2part 1 part 2part 1 part 2part 1 part 2p
art 1 part 2part 1 part 2part 1 part 2par
t 1 part 2part 1 part 2part 1 part 2part 
1 part 2part 1 part 2part 1 part 2part 1
 part 2part 1 part 2part 1 part 2

and you have to do a print screen to look at them