The logic falls out of the loop and continues on…

Short answer: It moves past the loop.

Longer: Unless you’re in another loop, or you’re in a function that’s triggered, which sounds like what you need to do.

Basically set up an event (and a function) that triggers each time your sensor is bumped. How to do that would depend a bit on the tools the sensor gives you.

Thanks for the answers. This is trickier than I thought! I need to be continually polling the sensor, which means everything needs to be inside a while(true) loop. But that also means that any loop within that loop is going to repeat as well, and very quickly. I think I have found a fix, but I won’t be sure until I get a chance to go to the lab and download the code to my robot and see if it behaves.

What you might do would be to introduce a recursive loop at the beginning so that it pulls the function when it encounters the condition. Just put it on one of the outside loops

The best way is with interrups but assuming this is beyond the scope of what you are doing just put a “check button for depression” function in the loop. If you get a yes increment a variable that you have created earlier. This variable must be visible outside your “check button for depression” function. The function that sets the motor speed must use that variable.

I don’t remember, does C let you do this?
(haven’t done C in a long time, hopefully this is kida correct syntax)

https://gist.github.com/169770abb0191535ee3f

My above answer needs another counter. When you detect the button depressed, start a counter to count down to zero. Make the counting last for about ½ second. Don’t look at the button again while the count is going on.

@Rock2 is correct, you don’t want to be constantly polling anything because it will burn down your batteries. Using timers is the way to go so that you’re only hitting the sensor every so often.

If you are using C++ or C#, you can create a separate task to handle the sensor. The method of creating tasks and events in C# is, IMHO, a little convoluted but not difficult to master. The task could loop forever. Use the sleep method to sample the sensor and allow the rest of the code to execute. When something of interest happens you could trigger an event that other parts of the code can subscribe to.

As suggested above, use of an interrupt would be ideal and remove the need for a loop or a separate task, but even in that case, it makes good sense in terms of code design to have a separate class for the sensor and provide the class with an event that can be subscribed to by other parts of the code. Always keep the following guide lines in mind – a class corresponds to one “thing” and a method does only one thing.