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.
2 Likes
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.
6 Likes
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!
2 Likes
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.
4 Likes
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.
1 Like
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)
4 Likes
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
1 Like
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.
4 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.