The goal is to push the opponent off the circle. Some of the criteria: -The program must use multitasking -The touch sensor can't be activated for more than five continuous seconds at a time (ramming the opponent is bad, I guess) -The maximum amount of time the robots can be in a standstill collision is five seconds Here's my code so far. And why, exactly, are such easy goals being overly complicated with multitasking? This doesn't need multitasking. All these tasks will be conflicting with one another, controlling the motors as they are. This could be done much, much more cleanly with an infinite loop in just the one main task. Teks drama bahasa sunda lucu 6 orang. I myself haven't had much experience with multitasking, because I've never had the need to use it extensively. I'd ask your teacher why in the world would he require such a simple task to be so much more complicated by involving multitasking. Rule #1 of programming with RobotC: Don't multitask unless it's absolutely necessary. We do a lot of multi-tasking in our FTC code. The Multi-Bot project is also designed for you to experiment with and write your own programs for. To get you started with the sensors, the MBSensorTest test program will display continuous feedback from the four sensors (color sensor, ultrasonic sensor, and left and right touch sensors) on the NXT display. Mentor Notes – LEGO SUMO MindStorm NXT Robots Summary: These notes have five sections. The first provides a link to a version of this SUMO lesson in Microsoft Word 2003 format. ![]() ![]() A typical multi-threaded autonomous program would have - 1 thread which reads sensors (and populates global variables) so all the sensor reading code is in one loop. - 1 task that displays stuff, autonomous mission number, delay timer, sensor values, other debugging info, etc. To the screen - 1 task that applies some time based error correction to the gyro (this task only started if significant drift is taking place) - 1 task, the main thread, that based on sensor readings and mission selected, would actually do the autonomous code, i.e. This would be your main loop evaluating conditions and combinations of conditions (reads global variables from other tasks as inputs) and taking action. We would optionally spin off threads that would do things like, move a manipulator out and in while the main task does something with the drive train. We like this style of programming because we can divide up the code into logical chunks and work on them pretty much independently. Only had time for a quick look at your code so far, but it appears you are starting the readSensors task over and over. Start the task once and let it go. Using all bools I think you will be safe but depending on what kind of global variables you use you may need a hogCPU() and a releaseCPU() Then I recommend you start debugging this thing one loop or task at a time. First, run just the sensor task, run it, all by itself and monitor the variables in the debugger, or by displaying them to the screen, or by using the debug stream (we tend to like using the debug stream). Trip your different sensors by hand and watch the variables change value. Then run just the big loop in the main all by itself. Populate the global variables by hardcoding values in a separate initialization procedure. See if the main does what you want based on different combinations of variables. Then, when both are working separately combine them.
0 Comments
Leave a Reply. |