Team 2102 Problem With Control Interface

Technical Control System
1

Hello,

We use our 2009 robot often for demos or sponsor presentation. Within a presentation, out of nowhere we completely lost control. Our drive is 4 wheel drive 4 wheel steering. We have a steering centering portion of our code, as well as a recognizable autonomous mode. Heres the current symptoms which started suddenly without any changes to the robot:

No driving control whatsoever through joysticks or gamepad, when autonomous switch is toggled, the robot does start auto mode. When set to teleop, it drives forward full speed, no other motors move except steering centering. Disable switch stops robot. Drivers station is fully updated. We checked wiring all seems correct. Cannot figure out problem! Please help!

A programing mentor thinks it might be a timer on the first side of the crio programing which ran out, any similar problems? Any suggestions?

Thanks
Kevin Brice
Team Paradox 2102

2

Is your watch dog enabled? If it is, are you feeding your watch dog?

The watch dog is a timer that makes sure that if, for example, your code ends up stuck in a loop and it’s not being fed it’ll disable your robot. I think that is the timer your mentor is talking about?

You can tell if it’s a watch dog problem because in the line on the DS LCD where it says Enabled or Disabled, it says “WATCHDOG” instead. If that’s not the case, then it’s not a watchdog issue.

3

I’ll start by stating that there is no such timer. If it worked before, it works now. He may be thinking of the license expiration - the LabVIEW environment expires after a little more than a year. However, this would just prevent you from loading the programming environment, it would not modify deployed code and it would not create bad code.

Those symptoms tell me that the robot is doing exactly what you are telling it to do : the error is in your code, not in the system. Set some probes to figure out exactly what you are sending to the motor commands.

4

Not a watchdog issue. What is surprising is the code hasn’t changed since competition when the robot code was working superbly. Thanks thought, any other ideas, we are all drawing blanks.

Kevin

5

Do you have any sensors providing feedback from the steering modules?

6

We will run those tests, but honestly the code hasn’t changed, it just stooped working correctly. The lights on the jaguars all are normal, drivers station indicators normal too. Is there a way to completely format the crio, blank slate, and then we could upload code piece by piece to error check? Will removing all objects from onboard memory sufficiently reset it?

Thanks
Kevin

7

There is, but I doubt its the code. It sounds like your code is working correctly. Code just doesn’t magically change on its own once it’s written to the cRIO. Do you have any sensors (limit switches, encoders, gear tooth sensors, pots, etc) that might not be giving feed back to your code?

8

we use pots, limit switches, and center encoders. We considered these may be malfunctioning, and they very well might, but we can’t see how that would influence us loosing control over our turret and shooter.

9

Uh, actually it has a lot to do with you not having control.

I’m making an assumption that since you have these sensors you’re most likely running a closed loop system.

If your sensors are not providing feedback to the cRIO, then the cRIO doesn’t know the position of your turret or your steering modules.

Think of it like this:
If you try to turn your turret to a set point (ex: 225) and sensor (say, the potentiometer) isn’t working correctly then the cRIO is going to keep reading an incorrect value (ex: 5 or some other floating value) and will continue trying to turn the turret.

Make sure your sensors are working correctly. They can play a very big role in why your robot isn’t working correctly all of a sudden. Since the code worked well during the season, I highly-highly doubt that it changed all of a sudden.

10

Will do. I really hop that fixes it. We only have pots and encoders on the steering, the turret is just limit switches. Would the turret not rotate, nor an other motor system due to steering problem? Also any insight on why the drive is shooting forward? Could it all return to a bad sensor?

On a separate note, our team is very interested in the team san diego telepresence meetings. Please let us know of any support we can offer, i don’t know how involved you are with that project.

Thank You very much!

Kevin

11

I was using your turret as an example. Might be related to more than one sensor. I don’t know.

  • Make sure that the potentiometers and encoders aren’t just spinning in the shaft.
  • Do you have pots or encoders on your wheels? Or just steering?
  • Is your analog breakout board getting power?
  • Is your digital sidecar powered? communicating with the cRIO?
  • Are you sure the phases of the encoder aren’t backwards?
  • Did you unplug any sensors and plug them in wrong?
  • Are the contacts in the three pin (pwm) connectors secured?
  • Is the wire making a good connection with the contact on the PWM housing?

Those are just somethings to look at.

It could be something really small or something really big. It’s tough to say, you’re probably going to have to do a little investigating to figure out what’s actually wrong.

12

Double check that the multipin connectors that feed the sidecars are fully seated. At a quick glance they may appear to be OK but a full check might show that the connector is pulled on one side and the connections are intermittant or non functioning.

13

It sounds to me like one or more of your sensors has become unplugged. Under such a condition, a closed loop system like your steering control would try to move to a new position, but because the sensor is not giving readings, it never thinks that it gets there so it keeps going.

I would follow Al’s suggestion, but you can also try printing out your sensor readings in your code so you can verify that you are getting sensible numbers out of them (in my experience this is generally quicker than tracing wires for a large number of sensors, especially if they are buried in your chassis).

14

I was thinking unhappy sensor too, but the symptoms made me second guess that thought. My understanding is that they have no control over anything, period - each of the motors have their favorite setting (ramming or snoozing), and they just go for it when enabled. I’d think that with a sensor malfunction, unrelated components would still be ok.

This makes me think that while a unhappy sensor may be the cause, it can not be the underlying cause. It could be that the student’s code isn’t being allowed to run. For example, lets assume that the camera feeds that loop, and it became unplugged. In this case, the loop would be forever waiting for the camera to initialize and pass its reference in. Assume also that the drive motors were given a speed once elsewhere - for example, autonomous ended with the motors going forward. Assume thirdly that the watchdog is either disabled or mis-used, and we fing ourselves in a situation that closely matches theirs.

I know I made three unlikely assumptions in that analysis, but maybe it will trigger a neuron somewhere on chiefdelphi that will lead to a more likely scenario.

Could you post the code?

15

Hey all, I’m the student programmer who wrote this code along with mentors. Unfortunately, I’m away at college right now so I can’t be around to help.

I just wanted to add the following to the discussion, based on my knowledge of the code:

The code for operating the turret is called within the thread that houses steering and driving, so its entirely possible some lack of feedback is causing this thread to crash. The camera control is on its own thread, but there’s no real way to check if this is thread is in flight at the moment, due to the way the multithreading environment is laid out in the code. What you can do is change lines 1981-1984 in the code, which currently looks like:

	
if ( bPressed_SnapshotButton )
	{
		m_bRequestSnapshot = true;
	}

to something that will take images all the time. You can tie this to the timer code that’s already implemented, or for a quick (and quite ugly) solution you can have the camera take images as fast as it can (about 30 fps), with

	
if ( CameraInitialized )
	{
		m_bRequestSnapshot = true;
	}

and then check the drive via ftp for the image files it drops.

Another thing I would suggest is to check the log file. To do this, uncomment line 56:

//#define USE_LOG_FILE

Then, use ftp to examine the log file on the run for “Start Competition” line, the “Alliance Selection” lines, and the “Loaded Steering Config:” lines. This should give you a hint as to where the code is crashing. Also, make sure no errors come up.

I would consider some of the other suggestions here as well, definitely double check electronics. Its entirely possible something died somewhere along the line.

Anyway, I’m posting here in the hopes that this information will be of help to everyone that’s helping the team. Thanks to everyone who’s posted advice.

I’ll try to keep tabs on this thread and supply any other information if requested.

Thanks,
Bryan Cheng

16

Thanks for all the advice. We will not be able to test any of this until monday. We have the heads of programing, electronics, and build meeting as well as a couple mentors. I will print the entirety of the thread and post with our findings. Thank you everyone for the input, it was very fast and helpful.

Kevin Brice
President of Build
Team 2102 Paradox