I’m currently using EasyC to make a simple program to test the bumper switch. I’m using an “If” statement for when the bumper is pressed then one of the motors should go the different direction, but I can’t seem to get the code right. Any assistance?
Post the code you have so everyone can see it. This is the best way to get it debugged without asking someone else to write it from scratch for you. It could be something very simple.
I already tried codes like “If (Bumper Switch1 == Pressed)” and “If (Digital1 == 0)”
Have you defined the bumper switch as a variable and added the bumper switch block prior to your if statement?
Could you still share your code? There are lots of things that could easily go wrong in easyC, ironically, and it’s difficult to take a stab in the dark and still be helpful!
I’m almost sure he forgot to put the if in a while loop.
You must continually check, so something like this…
// Loop forever checking for something, if found doSomething is called
while(true) {
if(something) {
doSomething();
}
}P.S. this can be written in a shorthand fashion like so…
// Loop forever checking for something, if found doSomething is called
while(true)
if(something) doSomething();
-Cody
If there’s anything I’ve learned from trying to teach people how to program, it’s that you make them put curly brackets in all the time. While the shorthand is obvious to us, it’s pretty confusing to a new person. Better to be verbose.
Someone correct me if I’m wrong, but the code here should work, right?
It’s been a while since I’ve used a bumper switch in EasyC.
That only makes it go backward while the switch is pressed. In other words, as soon as it backed up enough to depress the switch, the bot would go forward again.
I don’t have EasyC but here’s the pseudocode:
int bumper = getDigitalInput(1);
bool backwards = false;
if (bumper == 1)
{
backward = true;
}
if (backwards)
{
SetMotor(1, -127);
}
else
{
SetMotor(1, 127);
}Edit: I guess what you wrote is what the OP actually asked for. Not sure if this is what was intended or not though.
Yeah, I was trying to get him what he wanted. I’m not sure what the point of this code is other than testing if the bumper switch is working, but there you go.
Wildcat, I’ve uploaded the code here in a .zip file if you wanted to download what I have up there.
Bumper Switch Testg.zip (1.96 KB)
You don’t need the variable or the ‘==’ for that matter…
bool backwards = false;
while(true) {
if (getDigitalInput(1))
{
backward = true;
}
if (backwards)
{
SetMotor(1, -127);
}
}Let’s explore why, first:
Q. Why don’t you need the variable?
A. Because you only use the value once. If you use a value more than once it’s a good idea to store it, but if you only use something once storing the value almost never makes sense. getDigitalInput() returns a value and we can use this return value directly in the if() statement. In short, the if will see the value returned by getDigitalInput(). So we could write:
if(getDigitalInput(1) == 1)
{
doSomething();
}But there is a neat trick we can use, which brings us to the second point:
Q. Why can we remove the ‘==’ ?
A. Because in binary 1 is the same as TRUE, and 0 is the same as FALSE. Since this function returns 1 or 0 and the if is looking for a 1 or a 0, there is no need to do a comparison, and in fact most compilers will figure this out and remove the comparison anyway in code optimization.
So…
if(getDigitalInput(1))
{
doSomething();
}works just the same.
Bonus question:
Q. But Cody what if I want the opposite (the if to trigger if FALSE)?
A. You mean…
if(getDigitalInput(1) == 0)
{
doSomething();
}Easy, we just prefix the function with a ‘!’ which is C means ‘NOT’ so…
!1 == 0
!0 == 1
!TRUE == FALSE
!FALSE == TRUE
So we can just write…
if(!getDigitalInput(1))
{
doSomething();
}And doSomething() will get called whenever getDigitalInput() is 0 or FALSE.
As far as these tricks go, idk I agree that teaching beginners to do things with the training wheels on is good, but they NEED to know these things to A. become better programmers, and B. to have any chance in h3ll of reading professional code.
I think these tricks produce cleaner code that is faster and easier to read. For example I can rewrite the entire code block like so…
bool bumped = false; // Flag set when bumper switch is pushed
while(true) {
if(getDigitalInput(1)) backward = true; // Check bumper switch
if(bumped) setMotor(1, -127); // If bumped, go backwards
}That’s 13 lines of code down to 6, over a 50% reduction of crap I have to scroll through as a programmer. That’s important and becomes even more important when projects get big, and then get really big.
So yeah, I’d teach the easy way first then teach the tricks once the kids have a good grip on what they’re doing. Maybe I’m wrong, but kids have in the past blown my mind in just how capable they are.
I taught a bunch of middle schoolers 3ds max and they soaked it up. By the end of the month they had a better proficiency in the program than most of the people here.
One of them even taught me a hotkey I didn’t know. It was outright amazing, I sat there stunned and was forced to rethink how I teach. I no longer assume that people are idiots when they don’t understand something, I assume that people who don’t understand something either lack motivation or a good teacher and that changes everything. At least in the context of you teaching something.
I actually like teaching, and am trying to explore ways of doing it in my own style. I’ve been asked by many teams this year for help with various little things, and the video tutorials on max seem to help. But I think 3ds max isn’t all that interesting to people here. I might need to explore a different area of interest, perhaps Inventor or RobotC.
Oh well, I’m way off topic. There should be more than enough here to help the OP. -Cody