Programming sensors

Hi, last year was our first year doing vex. We use some simple sensors like a bump switch and a limit switch.

This year however, we want to try and use some more sensors on our robot. I have been searching the internet to try and find a tutorial which explains how the different sensors work and what they do. Unfortunately I have been unable to find any.

I was wondering if any of you know where I should look. I would also be interested to find out your views on what sensors are most useful this year my team has:
Optical shaft encoders
Bumper Switch
and Limit switches
Any help would be much appreciated


On a lot of the teams last year, they just had limit switches on the back to initiate different parts of the autonimous mode by hitting them in order. You could do something simple like that. I would sugest that, because of the simplicity of it, and you know exactly what your robot will do instead of your robot deciding what it will do every round.

Just using switches to activate autonomous functions may be simple, but just programming your motors to run for specified amounts of time is not very accurate, especially if your batteries begin to die.

The more advanced sensors can be easily programmed with a set value, so the robot isn’t doing what it wants to, but rather what you tell it to.

The more advanced sensors can be easily programmed with a set value, so the robot isn’t doing what it wants to, but rather what you tell it to.

Can u expalin this in a bit more detail please, I am not quite following you.

Also, what I meant to ask in my origional question is what the differnet sensors do and their uses. Sorry if I was unclear.

Anyway thank you for your advice 1039b I will look into using a switch to chose autonmuses

First of all, are you on EasyC or RObot C? I personally think optical shaft encoders and potentiometers are the most important sensors any team can have on their robot. These can be used to make an autonomous routine incredibly accurate and consistent. What i think the previous poster meant was that sensors don’t have to be used for the robot to “search” or “think” in the autonomous, simply you just tell the robot to go forward until the sensor reads a certain value. In other words, you are telling the robot how far it should move in a very accurate and precise manner.

Um, well optical shaft encoders measure rotation not necessarily distance. Also, I’m not actually very knowledgable of EasyC cause i only use RobotC, so i might not be able to help that much sorry. Overall though, SENSORS ARE GOOD!!


Measures rotation in some arbitrary unit (or maybe not arbitrary I’m not sure) but you can use it to choose autonomous routines by setting a block of values to refer to a single number which refers to a certain autonomous routine (aka potentiometer values 0-400 then 0-100, 101-200, 201-300, 301-400 each refer to one of four different autonomous routines). Alternatively the potentiometer can be used for arm presets. In testing you can attach the potentiometer to your arm and record the minimum, maximum arm heights as well as any other signifcant points in your arm’s rotation and have your arm raise until it reaches a certain value then stop (arm presets actually much more complicated than this I think).

Optical shaft encoder

Measures rotation in ‘ticks’ I think, another unit that might or might not be arbitrary. Unlike potentiometers which only have a range of maybe 180 degrees before mechanically stopping, shaft encoders can continue to spin in one direction infinitely. This is perfect for slapping onto a drive axle and measuring distance. A certain distance can increase the shaft encoder value a certain amount (aka 1 foot = X amount of ticks). This value can then be used to move the robot a certain distance forward, backward, turn a certain amount, etc. Also you can use the encoders to compare the relative speed of the two sides of your drive and slow one down/speed one up to make sure they go the same speed and your robot drives straight.


Don’t have much experience with these but I understand that they measure tilt? Could be used for balancing your robot potentially.

Bumper/Limit Switches

Some of the most useful sensors in the VEX arsenal. They give a 1 or 0 depending on if they are pushed or not. These can be used to select different autonomous routines (like the use for the potentiometer mentioned above). Alternatively they can be used to detect when the robot hits a wall or obstacle and move on to another step in the autonomous routine. They can be used to detect objects that are in position for intake/collection. They can be used on goals to detect when to score objects. They can even be used to detect other robots and either stop the routine to protect motors or push back or do an alternative route.

Hope this introduction to these sensors helped, there are also hosts of other sensors that are just as useful to a sound autonomous routine.

Edit: Our team uses RobotC not EasyC and I’m also not our programmer so I’m not sure how much of this is RobotC specific.

@SweetMochi That was a very good description lol.
To the original poster: You might want to consider learning RobotC. ALthough some people think EasyC is better, there is a pretty large community who are extremely advanced with RobotC and would be able to answer questions much easier. If the syntax scares you, then you can stick with EasyC, but I personally find RobotC to actually be easier than the so called “EasyC”

Hi Thondor I would really like to use Robot C to programme. The trouble is my school have very little money so vex give us most of our parts. They told us easy C was easier to use and gave us a copy of it. I think it is extremely unlikely that I will be getting a copy of Robot C soon.

I was just wondering though what are the advantages of using robot C?

and thanks Sweet Mochi that has made things much clearer.

One thing RobotC has more freedom, has its own debugger, and it downloads faster. It costs $4 more I think than EasyC. EasyC works great, but if you want to get more advanced, you probably want to work with RobotC. EasyC will still work great for competitions.

Accelerometers measure the derivative of tilt, or how fast the tilt is changing. Yes, they’re incredibly useful for balancing the robot. Our team had an aluminum chassis with a heavy (~7-10 out of 15 lbs) arm that extended up to 42 inches. We used an accelerometer to detect when the robot was tipping to solve this problem.

Back on topic: I agree, RobotC is better than EasyC for intermediate or advanced programmers. If you don’t have money to buy it, though, EasyC’s not half bad.

Let me tell you, using time alone on an autonomous is a very bad idea. We had an alliance at Nationals who literally had no sensors what so ever. The horror was further pressed into our minds when they ground into a goal post for a solid 15 seconds during autonomous.


We have always used optical shaft encoders and potentiometers, even some limit switches if needed.
As for the choice of compiler, I have always liked RobotC. Then again, I have programmed in C++ for quite a long time so it came a bit easier to me. I can imagine how the syntax could scare people, but there are some decent RobotC tutorials online that are great for getting started.

Some nice things about RobotC is that it does have a rather descriptive compiler, and it is rather forgiving. Let’s say you referenced a function, but forgot the semicolon after. IE: “DoSomething()__”. RobotC will warn you about it, but automatically place a semicolon in for you. Also, the debug stream is really helpful if you want to see a live output of sensor values, text or even simple failsafe code.

But as Mobius said, if you don’t have the funds, EasyC is a pleasant alternative. Although I don’t use it, I have heard positive comments about it from various teams over the years.

I heard somewhere that if you insert “Blank Codes” or something like that, you could effectively record your autonomous mode as you drive. apparently that is how the pros do it. Im just wondering if there is something, like that anywhere

I’m not sure about the “blank codes”, but our team has been working on a “dummy” program that is very similar to what you have described.

I think I know what you are talking about, though the way I understand it it requires alot of databases and a lot of fine tuning to get it right…

Ours directly takes advantage of the debugstream in RobotC haha. It works pretty well…but there is a lot of perfecting to do.

Haha, that’d be too easy!
Jk, but I’m using EasyC, so it sounds like giant arrays for me!

Well mostly it calculates things like turn velocity, rates of deceleration and such.
It also spits out sensor data, so I can directly plug that info into a C file :slight_smile:

This depends on what your autonomous does. For Gateway, we had a very reliable program with no sensors. It scored in the center 30" almost every match we were in. When it didn’t score, it effectively blocked so that we could score in driver control. And we put a stop command in the program, so that it didn’t grind into goalposts for 15 seconds.