![]() |
Possessed robot
Can anyone help us, Our programmer wrote a function for our Elevator Mechanism to get a certain heigt by using he inches per second that the arm go at the push of a button. Our problem is that while the Elevator Mechanism is getting that height we would lose control of the robot untill the arm is finished getting to that height, so if we were going a full speed while it is getting a height the robot would keep going at full speed even if we let go of the drive joysticks.
|
Re: Possessed robot
What type of a function did your programmer use for the arm? Is it inside a separate while loop? Last year, if I used a while loop for anything inside the operator control, I would have to insert the Tank Drive code inside it because everything outside that while loop would get ignored. So, if you have teleop mode and a while inside, everything inside the while loop will operatre but nothing outside of it will work until the code exited the loop.
|
Re: Possessed robot
Quote:
|
Re: Possessed robot
Your programmer has probably written the "extend elevator" code as a loop waiting for the elevator to get to the desired location. A loop like that "stalls" the rest of the code. I'm surprised your robot isn't shutting down due to a communication watchdog timeout.
What you'll need to have instead is to start the motor and do a one-time computation of a global variable defining how long to run the motor when the button is first pressed, then a quick test in the teleop code to see if the time has elapsed and stop the motor if it has. Teleop is already called repeatedly from inside a loop. |
Re: Possessed robot
I know exactly the problem: make a boolean that triggers false when the arm action is initiated and set the PWMs to 127. So when the action is done, the boolean is turned true and you can drive again. The boolean has to be set to true again in the Arm function when the whole arm thing is done.
Code:
bool Drive = true; |
Re: Possessed robot
Quote:
|
Re: Possessed robot
Are you using the "Drive" function given to you by WPI? I suggest you look at the source code and see how it operates. You will then see why it is happening. That is why I rarely use functions that other people make.
|
Re: Possessed robot
Quote:
|
Re: Possessed robot
Kory, if you'll post the section of code you're using to make the elevator go up when the button is pressed, I'll show you exactly how to "unwrap" the loop to let it work simultaneously with your drive motor control. Make sure to include the part at the very beginning where it reads the button.
|
Re: Possessed robot
Quote:
|
Re: Possessed robot
Code:
class RobotDemo : public SimpleRobotI took a pic. of the problem on windriver |
Re: Possessed robot
Eh, not exactly "custom" function... Personally, I feel that there is no point in using C++ if you are not going to use classes per se. I think it defeats the whole purpose of using an object oriented language. Yes, I know the library is essentially a whole bunch of classes and straight C would not recognize it. Personally, I would say clean up the code. I am not saying it is not "dirty" (it can be optimized...) but it is congested. I learned the very hard way, once when a fairly good programmer gave me a lecture on not splitting up the source into separate files and classes and other last year, when I essentially wrote spaghetti code, the inspector and mentor was appalled by it. Robotics does tend to make you write any code that "works" over organized, optimized and clean code that works.
Ok, see what I wrote before (it's not going to run as is, it is essentially pseudo code) and pay attention to why I do certain things. I will not spoon feed you. |
Re: Possessed robot
The reason the robot is possessed is that you are calling Wait inside if Elevator_get_the_heigh and Carriage_get_the_height. The tasking thread is told to wait for some time and cannot return back to get the next teleop packet containing new joystick values. The packets where the drivers let go of the joystick are being sent to the robot, but they are ignored because of the Wait().
There are many ways to fix this, but it is very easy to introduce. First make sure the explanation makes sense to you and any other programmers working on the robot. Assuming time can be driven by the ~20ms arrival rate of new teleop packets, what you want to do is record the time that you started the carriage or elevator motor in a static variables, or perhaps if you do want to use objects, create a static object that holds the pending movements of the motors, the time movement started, and any other info that is helpful. Each time you enter into teleop, do a quick check to see if a motor has been on long enough and should be turned off. This is also when you'd turn on the elevator motor. Pay special attention to the initial values and any overrides that the drivers may need that turn the motors off before they reach their target. Once you get rid of the waits, the exorcism should be complete, and perhaps you can even turn the watchdog back on. It will help identify any other placed in your code which wait or loop and block communications. Greg McKaskle |
| All times are GMT -5. The time now is 12:30. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi