Posts Tagged ‘Robots

10
Jan
11

It’s FIRST Robot Season!

It’s FIRST Robot Season! Start of the 6 week build season. To start with I want to make sure the password is out for all. It’s kind of hard to type in but can cut it from below and paste it in the encryption password.

5Time4For3Robots2to1Dance!

Next, I want to say how excited I am about the build season. This week everyone should be understanding the game, brainstorming and begin designing their Robots. Plan what needs to be done before you talk about how to do it.

I’ve read the game manual twice. I’m ready to help our FIRST team 704 to start understanding the game and brainstorming tomorrow. I know a lot of people aren’t sure where all the various resources for the game are so I want to list all the resources I’ve found so far.

At the NASA Robotics page you’ll find the full kick off video, the game animation, and a video by Grant Imahara (Mythbusters) on Robot design. Everyone should re-watch the game animation to make sure they understand it.

There is a LabVIEW update on the NI site that, I believe, is a mandatory update. You should probably run it to complete preparation for the Robot Season.

There is also a cRio update that everyone, LabVIEW or not,, must run.

National Instruments has a LabVIEW guide to FRC Robot programming that put on your hard drive that has a lot of information on the robot, robot code, and all things NI for the FIRST Robot.

Also, on the Kit Of Parts page on the FIRST website, there is more information than just the kit of parts. Make sure you scroll down. There’s a lot of information (data sheets) on a lot of the technical parts, the Pneumatics Manual, and a lot of sites you can go for help. There’s information on the sensor’s that should be helpful. But don’t forget about the LabVIEW examples for FRC. They can be really helpful.

There is a lot of information out there to help, especially for rookie teams. Remember, there is help out there. Also, I can be reached at frc704mentor@qweztech.com and I can help or at least let you know where you can find help.

Get out there and start brainstorming and designing your Robot.

Advertisements
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.

28
Sep
10

FRC LabVIEW Programming – more basics

LabVIEW is a Graphical Programming Language. As a programming language it has a lot of the constructs as text based languages but also has a lot of features that make it easier to use. It also has things to keep in mind when you’re programming.

First thing to remember is that LabVIEW is a data flow language. What that means is that a block has to have all its connected data inputs ready before it executes. Also, there is no guarantee of order of execution of the blocks unless they are wired from one to another. In the example below, block 1 will not put out its output until the two inputs are both ready. Also, with block 2 and block 3, there is no way to tell for sure which block will execute first.

The main way to sequence blocks is to use the error wires to sequence the blocks as shown below.

Above, since all of the inputs have to be at the block before it executes, since the output of block 2 goes to block 3, this will force block 2 to execute before block 3.
Another important item that you need to be aware of is that Loops are threads. What that means is that each loop executes independent of each other and executes at the same time…as far as you’re concerned. An excellent use of this feature for your FRC Code is one loop waiting for a button to be pushed to kick while another loop is taking Joystick inputs to drive the robot. The two loops below both run at the same time and would see no difference in execution. One thing to remember is to put “wait” blocks in the loops. Without the wait blocks other loops may not have any time to execute because one is taking up all the processor time. In the example below, without the wait block in the loop with the button read all that would be going on is the processor waiting on buttons the joystick. The loop with the joystick read would only run occasionally and you would see a lot of sluggishness in the movement of the Robot.

Another important construct in any programming language is the state machine. The state machine allows the robot to do one step, once complete, do the next, then do the next, etc. This is great for the autonomous mode where you want to do a sequence of steps. Such as move forward, stop, kick, move forward again, etc.

The pictures below show a simplistic state machine example with 3 states and an idle state (state 0). In the Begin block (in robot main) you would initialize the State Number.vi with a 1. Then once you start executing the loop the state machine is in it would execute the case #1. Of course you would actually need to do something where below I just say to do something. It may be drive the motors forward for a certain amount of time. The true/false case inside the state case should have the output of something with the output of false if not complete and true if the operation is complete. Once the operation is complete a 2 would be output and put into the state number.vi.

Once the state number is 2 then the state case 2 would be executed. Notice the true/false case shown in the picture below shows the false case. What this shows is that if the operation not complete (i.e. a false is output) the state case number stays at 2. And again, once whatever operation is complete and a true is fed into the true/false case, the case number would be changed to 3 (not shown below).

Once the state case is 3, again some actions are performed. Since 3 is the last case we have, once the operation is completed a 0 is put into the state number.

In this case we do nothing else we would just stay in case 0. In this case there is no way to move to another case without re-starting.

Now that I’ve talked about LabVIEW and some concepts of programming, next week, I’m going to go back and talk about some LabVIEW navigation and short cuts that are helpful.