PROS won't take joystick input

I have a bit of a weird problem. I’ve been trying to find an error in my code forever, but from the behavior I think it’s probably a PROS/hardware thing. Basically what happens is that as soon as I add a 20ms delay into my while loop (in opcontrol), all joystick input breaks. I have no idea why or how, but I can’t do anything on the bot. The program is still running (I tested with some terminal outputs), so it’s not an infinite loop. Putting the delay before the loop doesn’t break anything either, but as soon as it’s anywhere inside of the loop I can’t control the bot. Now here’s where it gets really weird: if I lower the delay to 1ms, half of it works. The left joystick (both channels 3 and 4) works perfectly, but the right one still isn’t giving any input. Removing the delay fixes everything, but messes up some timing stuff I have, so it can’t be a permanent solution. The issue is (probably) not with my hardware, as

void operatorControl() {
	while (1) {
		motorSet(2, joystickGetAnalog(1, 3));
		motorSet(3, -joystickGetAnalog(1, 2));
		motorSet(8, joystickGetAnalog(1, 3));
		motorSet(9, -joystickGetAnalog(1, 2));

		delay(20);
	}
}

worked perfectly fine.

Here is my code. I fixed the issue, so I don’t need anybody snooping around my code anymore :slight_smile: I’m using some strange data structures and stuff because I’m trying to make it as portable as possible (right now I only have a chassis, so I’ll need to port the code to our actual bot at some point). It’s also not very well commented, but hopefully you can figure stuff out (if not just ask). If you want to play around with running the code on your own bot the only thing you need to change is the motor ports of the chassis variable at the beginning of opcontrol.c and the encoders inside of operatorControl().

void operatorControl() {

        ...

	// setup encoders
	chassis.encL = encoderInit(1, 2, true);
	chassis.encR = encoderInit(3, 4, false);

I appreciate any help or guidance anybody can give me.

What mode are you running in? If you’re running in STATE_CHASSIS_PROPORTIONAL, I could see some issues with limiting using encoders to limit the speed of your bot. It looks like you’re mapping encoder deltas directly to PWM output. The tick deltas are probably no greater than 10-20 (a generous estimate). I’d figure out some other way to ensure that your bot doesn’t drift too much. Try using the deltas as an indicator that you need to account for drift (and maybe how much), but those deltas should never actually directly control motor speed. Perhaps you could use delta_left - delta_right to signal how much to turn, then just add/subtract that to your left/right output motor values. ninjaedit: looked at your map function a little closer - might be as simple as changing


min2 +

to


min1 +

since you want your output motor speed to be in the -127,127] domain not however precise your encoders are.

I didn’t see anything out of the ordinary with STATE_CHASSIS_NORMAL after a quick look since it looks to be about the same as the traditional opcontrol loop, but with some extra function calls to go down into. I didn’t look at your


recording

or


position_tracking

code at all since I assumed you aren’t currently following those code paths.

Hope this helps.

Don’t mind the deleted post. Pressed quote instead of edit.

You should also probably add break statements in this.

switch (state.chassis) {
  case STATE_CHASSIS_NONE: break;
  case STATE_CHASSIS_NORMAL: chassis_move_normal(chassis);
  case STATE_CHASSIS_RECORD: buttons = chassis_move_record(chassis, etime);
  case STATE_CHASSIS_PROPORTIONAL: chassis_move_proportional(chassis);
}

Also, if you want a private (free) place to store code use BitBucket.

I’m running in STATE_CHASSIS_NORMAL, but proportional didn’t work either (now that I’ve fixed it it’s working fine, so there’s nothing wrong with my map function). Thanks for the input though.

Somehow that fixed it, so thanks. It’s weird though because that was working fine before I added the delay…

You were setting motors from multiple functions. With the delay whatever was last (chassis_move_proportional) would have had the most significant effect. I couldn’t actually reproduce what you were seeing but I didn’t add any encoders and that was probably the difference, but without the break statements that code was probably not doing what you wanted anyway.

Ah, now that makes sense. Proportional was last, and before I added the delay it would run through the loop probably thousands of times per second, so instead of slowly speeding up as the wheels moved, it just moved at full speed all at once, which I probably mistook as the normal mode. When I added the delay it totally stopped working because of a different (unrelated) problem in the proportional control which I fixed later. Thank you so much everything is working perfectly now.