Archive for the 'Sensors' Category

31
Jan
11

FRC – Analog and Digital Sensors

Sensors can really help with robot performance. There are several sensors that come in the Kit Of Parts (KOP), limit switches, the encoders (2 kinds), IR sensors (for line following), gyro, camera, and accelerometer. There are several different ways these sensors interface with the computer. Some through communications protocols such as TCP/IP that the camera uses or I2C protocol that some of the Lego Mindstorms sensors use. There’s also a digital interface used by the Quadrature wheel encoder and the limit switches and an analog interface used by the gyro and the magnetic wheel encoder. I’m going to focus on the the two simplest, digital and analog sensor interfaces.

A lot of the analog and digital sensors use a 3 pin interface. There is a ground (minus) and 5 volt (plus) pins to provide power to a device. The third pin is a signal. On the analog input the signal pin accepts voltages between 0 and 10 volts. On the digital input, it accepts a voltage between 0 and 6 volts. If the voltage is above 3.2 volts (I think) a “1” is read and below 3.2 volts a zero is detected.

The Analog bumper is shown but digital side car has the same pin out.

As long as any sensor you have is 5 volt you can wire the 5 volt sensor line to the 5 volt pin on the analog or digital interface, the ground to the GND pin (minus) and the signal line to the SIG pin, the sensor should work. Note that if you get the ground and power lines backwards, the sensor may burn up. In other words, be careful about wiring and look for black spots on the chip or a funny smell after you hook it up.

A sensor that uses a digital interface basically sends an on/off signal. Limit switches are the best example. When the limit switch is closed, a one can be read by the computer. When the switch is open, a zero is read. Limit switches are good for checking the end of a mechanical movement or when something is in place like a scoring piece. The quadrature encoder sends digital signals for each rotation to the digital sidecar. This creates a pulse stream as shown in the diagram. By counting the digital signals, the computer can tell how far the robot has traveled. That’s basically how the LabVIEW encoder blocks work.

Analog sensors send out a voltage that can be measured by the analog module on the robot. Analog sensors such as distance sensors will put out a voltage based on the distance an object is from the sensors, the closer the object the more voltage the sensor puts out. If you know how much voltage is put out per inch, the distance can be figured out by multiplying the distance per inch with the voltage. The gyro puts out a voltage as the gyro is turned.

If you read the data sheet on a sensor it should say if it’s analog or digital, what pin is for power, what pin is for ground and what pin is the signal. Almost any sensor for analog or digital should be able to be used fairly easily. If you have any questions about sensors or about other robot issues you can e-mail me at frc704mentor@qweztech.com. Good luck.

Advertisements
23
Jan
11

FRC build week 2 musings

I hope everyone’s Robot planning is going well. I’m also hoping all the teams have their strategy down and have a plan to fit the Robot to the strategy. Make sure whatever strategy is chosen is done well. If it’s a defensive strategy make sure the Robot is built to push other Robots around or to be the best blocker possible. If you have a scoring robot, make sure you can score quickly and efficiently.

The Kit Of Parts (KOP) came with many sensors, everyone should try to make use of them where they can. The sensors can be used to aid the driver in Robot operation and to help in autonomous mode. Some of the sensors like the wheel encoders can let you know the distance you move. The linear encoder can help the Robot tell the distance an actuator moves. The gyro can help your robot tell which direction it is pointing. All the sensors have examples that are runnable. To get to them, open LabVIEW and in the lower right hand corner of the opening screen are the FRC examples. All examples have diagrams of how to hookup the sensor. Also, all the data sheets are located on the site http://www.usfirst.org/roboticsprograms/frc/content.aspx?id=18530. Make sure you scroll down.

Right now is a very important time in the build, some parts of the Robot are coming together well, some parts are not coming together and are in need of redesigned. Don’t get discouraged, just keep working at it. There are only four weeks left in the build season but it is plenty of time to get things together.

One thing people should think about is Prototyping. Prototyping is to build a quick and dirty model of whatever you are prototyping. One example is the kicker on last year’s robot. We (team 704) built a wooden frame, screwed it down to the floor and then used different things to kick a soccer ball. We made a kicker and tried various pneumatics, surgical tubing, and bungee cords. We made prototypes of different ways to kick a soccer ball. This year you might prototype various ways to put the game pieces on the scoring pegs. Come up with a way to score the game pieces and build something to try out your ideas.

It’s important to get your robot to a point you can test it before the ship date. Getting out there and running it through its paces is a key to success. Last year’s FRC challenge contained humps the robot had to go over. Our robot was ready somewhat early (a week early) and so we did some testing on a practice field.

During testing last year, after a couple of test runs our chains started to fall off and this bent axle is what we discovered. This along with a torn aluminum pan holding the battery. You don’t want to find out about this during the competition.

Good luck to all. Figure out what to do and do it.

15
Jan
11

FRC Robot Season – Getting started in programming

Its FIRST Robot season and everyone should be well into making sure they know the game and into discussions on what they want their robots to do. The game is fairly simple in concept and can be played in many, many ways. The programming of the robot can be key, the way you move around the arena, the way the game piece manipulator is operated, and how autonomous is played.

Really, there’s three sets of programming the teams need to be concerned with, the Robot, the dashboard, and the mini-bot. I’m not really going to write much about the mini-bot for now, mainly because we are putting that part off for a while.

The LabVIEW programming is fairly close to last years. After opening LabVIEW, make sure you remember about the “Find FRC Examples…” in the lower right corner. It will bring up the LabVIEW example finder to the FRC examples, but there are thousands of other standard LabVIEW examples in the example finder. There are tutorials on various FRC subjects. The tutorials don’t go into depth but show you how to get started on the different subjects. It does have some important information on how to set up the camera. The left side contains LabVIEW projects that have been opened and new projects to be started with the Dashboard project and the Robot project.

Also, when starting your project, don’t forget to put in your cRio IP address. The project that is opened is the way LabVIEW (and other programming languages) group required files together.

The Robot Main.vi is the starting point. Make sure you read the green area’s those are note added by the NI people to help guide the teams as they navigate the code.

For now I’m just going to write about the Autonomous and Timed Tasks, circled in red below.

One thing to remember is that LabVIEW is parallel, each top level while loop acts independent of every other loop. One programming issue that should be remembered is that different things you want the robot to do should be put in separate while loops. In other words, you should put your game piece manipulator control vi’s in one while loop, other controls in another while loop, and leave the motor drives in another while loop…such as the Telop.vi.

The Timed Tasks block (named Periodic Tasks.vi) is designed handle this. There are several while loops set to run at different time intervals, one at 10 ms and one at 100 ms. There is also an example while loop to flash lights as a demonstration. In one loop, the code for the apparatus movement should added. This will make the apparatus code not interfere with the apparatus code.

Also, remember, when taking human inputs, i.e. push a joystick button, the average teenage human only has a reaction time of 100 ms. So if you’re watching for a button be pushed, the 100 ms timed loop should be fast enough. Also, make sure there is a timer in every while loop.

The autonomous independent.vi is controlled separately by some underlying NI code, it is only called once. There is a simple line follower in the vi. I’ve not tried it yet but it requires the IR sensors. The IR sensors in the KOP are 12 v sensors. The wires to the sensors are as follows:

  • Blue: Negative (NEG)
  • Brown: Positive (POS)
  • White: Dark Out (DO)
  • Black: Light Out (LO)

That means the Blue and Brown wires go to the power distribution board and either the white or the black wires go to the digital IO on the sidecar.

The line following routine doesn’t take into account the Y in one of the lines. This would have to be taken care of somehow. Also, the apparatus movement would need to be added to the vi so that it doesn’t interfere with the movement.

Well, that’s it for now. Remember, if you have technical questions you can e-mail me at frc704mentor@qweztech.com or get onto the NI forums at www.ni.com/first

ADDENDUM:  I tried the line following in Autonomous Independent and it didn’t work. You should probably look at the line following tutorial at http://decibel.ni.com/content/docs/DOC-8923 to see what NI was thinking when they implemented the code, I know I am.

Thanks and Good Luck.

07
Nov
10

FRC Touch Sensor

Sensor’s come in handy in Robots. Sensors can be used when the robot is autonomous or when the driver needs some help. In the breakaway game, to help the driver we used the camera to see the ball on the far end of the field and to line up on the target from the middle area. Touch sensors could have been used to sense when the ball was in place and ready to be kicked or distance sensors on each side to help go through the tunnel. And I’ve already talked about encoders to move specific distances.
For next year’s FRC game who knows what sensors can be used. So you need to be ready and understand how sensors work and how you get information from them.
I’ve put in these links before but they are important learning about sensors. National Instruments has some good papers on sensors and their effective use. They have some basic sensor information and their basic paradigm is ”Sense Think Act”.
Digital I/O (DIO) is one of the simplest Sensor inputs. This can be used for touch sensor to tell when you’re against a wall or when something is in place. To get to the Digital IO go to the WPI Robotics Library >> IO >> Digital IO >> DigitalInput pallet.
> IO >> DIO” />
In the DIO example it show’s on the blue digital sidecar that there’s a signal diagram showing three connections, a positive, power, and a signal. For a simple touch sensor, electronics store have some touch sensor switches. Or a simple switch for touch can be built with some stiff wire going through a loop as shown below.

The resistor should be a 2.5 Kohm. The 5Volts will make the value hi when the wire through the loop is not touching. When the ground wire touches the loop it will ground the signal to a 0.

The LabVIEW code from the example is shown below.

The block diagram shows the Digital IO is opened according to the slot the DIO module is in and the DIO line. This example will simply show the value coming in from the digital IO line on the front panel. However, this can be used to sense when something is being touched, a wall, a ball is in the right place, or you’re in contact with a tower. It’s simple but very useful.
More about sensor’s next week.

26
Oct
10

FRC – Sensor basics – Encoder

Sensors are the way the robots interact with the world when not being controlled by the driver. NI has some basic sensor information.
They can also help the driver with operations for control. The basic paradigm for using sensors is Sense Think Act. This link has some good information on the Sense Think Act paradigm.
Think Sense Act means to use the Sensors to sense the world, distance, objects, orientation. Process and integrate the data from the various sensors. And then act on it, move in the direction or do an action based on that data.
The first thing to do is understand the sensors, how they’re used, and how to communicate with them. Some of the easiest sensor communication is digital I/O. Sensors like limit use digital I/O (DIO). The compressor pressure switch also uses DIO. DIO indicates on or off, it’d that simple. From there some thinking has to occur. “Are we at a limit?” “How many times has a DIO turned on?” Things like that.
Another easy to use interface is Analog Input. Analog input measures the input voltage of a sensor. Distance sensors are a good example of how an Analog Input can operate. Some distance sensor output a higher voltage when an object is close and a lower voltage when an object is farther away. The voltage would have to be calibrated to distance. Just note that not all Distance sensors are analog input.
Some sensors have serial communications. This can be a little more complicated than the simple DIO or Analog In data but you can get a lot more information from sensors and data can be sent to the sensor for various reasons.

Blocks for sensor communication

There many different serial communications protocols. A protocol is the process for sending and receiving data. Who sends what, when, and in what order. Serial, I2C, and SPI are two of the protocols supported by the robot code. There are blocks for standard serial communications, I2C communications, and SPI communications in the WPI Robotics library
Each device that uses serial communications has individual commands and responses based on the sensor. The user’s manual should have information on how to communicate.
The WPI Robotics Library has interfaces to most of the sensors used by the FRC robots. This makes it easy to interface with the standard sensors.

In my opinion, one of the more useful sensors are the wheel encoders. There are examples, sample code, and blocks to support them. Encoders can tell how far your robot has moved. It’s based on the number of DIO “ticks” happen. Ticks are each time a DIO line goes high then low. Each tick represents a distance. The number of ticks for a distance is determined by seeing how many ticks it is for one rotation of the wheels and figure the distance traveled with one rotation of a wheel. After that, if you want to go a certain distance, divide the distance to go by wheel rotation distance and multiply by ticks. That will give you the number of ticks it takes to go a distance.
# ticks = (D / Cw) * tick per rotation
D is distance to go
Cw is Circumference of wheel (wheel base)

If you want to turn, you have to have one wheel encoder go more than the other wheel encoder. To do a turn where one side wheels don’t turn and the other turns the robot you need to have the wheel encoders on one side move while the others stay in place.
There is a good encoder example for the encoders that come in the Kit Of Parts. From the LabVIEW opening screen, in the lower right hand corner, there is an examples area. At the bottom of that, there is a “more…” folder. Click on that and look for the encoder example. Below are some pictures of the encoder example.

Encoder example front panel

Encoder example block diagram

On the front panel there is a picture of how to hook up the encoder and a ready to use block diagram for deploying to the robot. Hookup the motor encoder leads according to the picture and then hit the run arrow. This will deploy and run the example. The driver station must also be hooked up over the network, running, and enabled.
Notice in the block diagram there is an open, configure, and start blocks outside the while loop. The encoder get is inside the while loop and so that it will execute over and over. There is a 100 hooked up to a timer which means the loop will execute every 100 ms.
Before you run the code, if you click on the “highlight” execution button, in red above, you can follow the execution.
Encoders are an easy to use sensor that can really help, especially during autonomous mode.
More on sensors next week.