!!Code automatically generated by ‘ROBOTC’ configuration wizard !!// #pragma config(Motor, motorC, leftMotor, tmotorNXT, PIDControl, driveLeft, encoder) #pragma config(Motor, motorB, rightMotor, tmotorNXT, PIDControl, driveRight, encoder) #pragma config(Sensor, S4, sonar, sensorSONAR) #pragma config(Sensor, S3, light, sensorLightActive) #pragma config(Sensor, S2, sound, sensorSoundDB) #pragma config(Sensor, S1, touch, sensorTouch) How do I get this to stop when it reaches the end of the ‘follow line’ loop? A concept like “drive” provides a wrapper around the concept, so that universal behavior of that concept becomes possible (without having to duplicate such behavior in dozens or hundreds of places peppered all around the code). Every time something is repeated (like you’re always writing TWO motor=p together), that is probably a CONCEPT that deserves a function (in C++ this might become an object).
#Robotc tasks software#
This represents a fundamental concept of software engineering.
#Robotc tasks code#
The volatile keyword enforces a rule by which the code is sure to obtain a “fresh” read on the value, so that if other threads have changed eStop, the test involves the actual, current value and not some cached value local to a thread. If this is not used there could be times when a test of eStop is made, but the code responds to an “out of date” version stored locally. This keyword instructs the compiler that the value of eStop should not be cached when being evaluated. It might require the “volatile” keyword, though.
One could argue that the global value “eStop” needs protection with a semaphore, but fortunately it doesn’t matter in THIS case. Now, even if multiple tasks are calling “drive”, only one at a time will prevail. call this one time during initialization code So, you should lock access to the “drive” function, so that ONLY ONE THREAD can control motor power at a time. This means the program could attempt to stop the motors WHILE ANOTHER TASK is in the process of applying power. However, if you DO have multiple tasks running, it is possible that multiple tasks are attempting to control the motors AT THE SAME TIME. You mention TASKS, but the code you provide is in the “main” task - there’s only one of those. However, there is another potential problem that requires attention.
THEN, you can can stop tasks at leisure by other means. Now, when you respond to the button for emergency shut off, you set eStop to true, then call “drive( 0, 0)”, and then ALL TASKS THAT MIGHT DRIVE WILL AUTOMATICALLY APPLY ZERO POWER. You no longer need to do this at the top of a loop. With this, EVERY place you “drive” the bot, you’re checking for epower. assume some global emergency power flag exists If EVERYWHERE in your application you’re writing “drive” to power the drive train, then the drive function becomes the place where you can globally control that power.
Your main goal is that there should be ONE SINGLE PLACE TO CONTROL POWER. Everywhere you’re currently setting motor power for two motors (and in some systems FOUR separate motors), you can merely code:
This is more convenient everywhere you code changes in drive power. It is typical that such constructs are “drive” concepts. What you need to think carefully about is this construct: Let me give you a viewpoint from a developer with many years of experience. I’m a volunteer in a local Vex robotics club, a parent to a member there, and a software engineer (so I teach programming to the club members). I’m new to the board, so let me introduce myself a bit here.
0 kommentar(er)
