We would like to use if statements to limit travel via limit switches (touch, magnetic, or software) on our robot. Now, once the if condition is checked and validated, the loop inside executes and the condition is not rechecked until the inside loop is finished even if the original condition turns false. We have searched on line and find reference to multiple thread execution, volatile flags, breaks, etc. A while statement ties up the entire code waiting for the condition to change. Is there an easier way to do this?
It’s hard to propose a solution to your problem without seeing the code.
Using a limit switch to prevent damage is a great thing to do. You souldn’t need any fancy code to acheive what you want to do.
Assuming that your code has a main loop, then you need to check the limit switches and output motor commands every time around the loop. In fact, the best time to perform the test is just before you output the motor command. Make sure you only limit the motor power if it’s moving towards the limit switch. So, determine which switch gets activated when moving with positive power and which switch is activated when moving in the opposite direction.
Roughly speaking… something like this every time around your main loop…
armPower = desiredMotorPower.
if ( ((armPower > 0) && forwardLimitSwitch) ||
((armPower < 0) && reverseLimitSwitch) ) {
armPower = 0;
}
armMotor.setPower(armPower);
1 Like
Thx for the reply. We’ll try this in an if/else arrangement. Currently ( I can get a code snippet later) we test kinda like this, then setPower according to a joystick level else setPower=0. However, once the condition tests the limit switch the first time and a TRUE test lets the joystick apply power inside of the if brackets, it will run by the limit-not retesting each scan. If you intentionally stop on the limit, the program will inhibit further motion in that direction as intended, But this code is cleaner and looks like it will test each scan. Thx.
For what it’s worth, you should always avoid any sort of multithreading in FTC, with a few exceptions it is only harmful. Many concurrent actions can be emulated using loops.
I don’t know exactly how the FTC app is set up, but for almost all real-world application multi-threading actually makes sense. If a micro controller has two CPUs, I will use them for different tasks. The robot controller though may already be using it’s cores for different purposes, e.g. behind the scenes stuff like monitoring pins (this is just a guess).
There are ways to do a virtual multi-threading approach. The OS can mix and mach each of the “threads” and seem to run them simultaneous. The Lambda operator does this sort of.
I haven’t seen many example using multi-thread though, and really the few I’ve found are for vision (Those exceptions @Luner mentioned).
By the way, logic statements are minuscule compared to other stuff, they may take less then a millisecond to process. You can also have the stop condition in the main loop placed elsewhere, like other loops, and if statements before long calculations.
The robot controller app does indeed make use of many threads internally for various SDK functions such as communicating with the Driver Station; however, due to the model of how hardware calls (setting motor power, reading an encoder, etc.) are handled, using threads in user code is almost always a bad idea. (Not to mention the usual dragons that come with multithreading, e.g. race conditions, deadlocks, etc). Every hardware call is a blocking write/read operation, and there is a master lock present on the serial connection allowing only one write/read sequence to be ongoing at a time.
1 Like
I had a software problem I thought I’d solve using threads.
Nwo I
have 97 sfotware
problmes.