My students are doing a bumper bot project where the bumper switch turns on their drive train but will also will disable drive train motors when tapped by another robot. We cannot get the bumper switch to disable the drivetrain when the gyro is controlling the turns. Is this some limitation of the IQ v1 brain, or is there a way to fix this? I attached a screenshot of the code we are using. It works fine without a gyro, but when the gyro is a part of the program the bumper switch will not turn the motors off when the bot is turning.
It’s not a limitation as such, however, when we are turning using the gyro VEXcode is using another task (additional code that is running) to monitor the gyro heading and control motors appropriately. That task is going to run until completion (either the turn completes or timeout happens, there’s really no way to stop it.
In addition, the forever loop you have will always be running once started, you would need to have a way to exit that loop when you wanted to stop driving, that would at least allow the turn to complete and then the robot would not move anymore.
Thanks for your response. It makes sense. Would this theoretically work, then? I can try it but I would like to know your thoughts.
I believe that the simplest solution would be to set the drive velocity and turn velocity to zero in your ‘when bumper pressed’ code. It would still run the loop but not move.
There’s actually no good way to do this on either IQ or V5. It’s something we should improve in the drivetrain class, that is, cause “stop driving” to break out of these internal loops when turning.
We can make some code work for your use case, but we are relying on the fact that if we send stop to the motors often enough they will not have a chance to move when receiving a command from the turning code, here are a couple of solutions, neither ideal, but at least the robot will actually stop when you hit the bumper switch.
This solution does not use the “when bumper pressed” events, that’s another problem area with the original code, technically they would both have fired on the first press.
This code waits for the first bumper press, then starts another process waiting for the stop bumper press by sending a message. Once we see the bumper pressed the second time, we continually send “stop driving” to the drivetrain and also set a flag that eventually causes the loop under when started to exit.
This version uses code to wait for completion of each step, but uses same idea where bumper switch is polled and a forever loop entered sending “stop driving” constantly to the motors.
If you wanted the bumper pressed again to re-enable the robot that would require adding additional testing in the loop stopping the motors.
Looking into this actually highlighted another couple of issues (again with both V5 and IQ) with the drivetrain class (really the underlying C++ SDK) that we will address in a future update.
Thank you so much for your detailed reply. I couldn’t get either of these two suggestions to work.
In the first example, the bumper did not turn the motors on. Basically nothing happened.
Not sure why.
In the second example, the bumper works for turning on and disabling motors during driving forward and turning (how cool!). The movement pattern stopped, however, after one iteration of driving forward and then turning.
While doing this project in class the code did (surprisingly) work with the two “when bumper pressed” events. I’m not sure why, but the students can get functioning code with these two blocks running simultaneously. I have actually encouraged them to use that. Is that incorrect? I’m honestly not quite sure how to teach them the essence of the boolean programming for this unit. Perhaps you can direct me to some resources.
While running your two suggested code examples, is it possible that I did something incorrectly with the creation of the bumperWasPressed variable? All I did was create the boolean variable. Is there something additional that needs to be done?
Thank you so much again. I’m so happy to have a fast and knowledgeable source of information!
Nor do I, it was tested, perhaps configuration was different.
That’s how it was supposed to work, it was just an example, it would have needed more logic to allow another press to re-enable the robot.
I’m looking for the best approach to guide my students in a bumper bot activity. The bumper should turn the motors on and then have the robot move around in a defensive and offensive manner. If the bumper is tapped by another robot it should disable the motors. I’m looking for some sort of continuous, looping pattern of movement (drive forward for 30 mm, turn right for 90 degrees) that persists until the bumper is pressed by another bot.
My students were disappointed by the fact that there is no straight forward way to do this while utilizing the gyro. I’m still at a loss for how to guide them and where to access resources to assist us in this project.
If I understand you are needing 2 states of drive. One that is active and it can drive around normally or a second state where it has been tagged by an enemy bot and needs tagged again by a teammate bot in order to re-engage normal mode, is this correct?
If so, I would consider having a variable “drivestate” and all the bumper does is takes the variable and multiplies itself by -1. This way every bumper strike switches between 1 and -1.
Then have a drive code that evaluates the variable. If the variable is 1, normal drive code, if the variable is -1, “spin out” mode until bumped again (thus evaluating at 1 again)
Is this using VEXcode blocks? I don’t know how to do what you’re suggesting. I’ve scoured the web for resources but have come up short.
I would be inclined to try something like this (I have not tested this). I simply took the example code of a LH arcade stick and nested it inside an additional “if statement” which evaluates whether the variable “Drivetrain_state” is a positive or negative. That number is flipped every time the bumper is hit
That will work for drive code, but the fundamental issue is that the drivetrain (and motor) rotate to type functions cannot be interrupted once started even though they will respond to the motor being stopped. The gyro turns have another issue in that they will be sending motor spin commands until the turn is complete. The kludge I showed a few days ago would constantly send stop and more or less override any motor spin commands. You could use a flag and test for it between each step in the code sending drive forward and turn commands, but that would only stop the robot between each command.
Using text, desired behavior can probably be achieved, run the drivetrain commands in another thread and stop or start that thread each time the bumper is pushed.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.