What Examples do you want to see in the FRC Software Suite?

[MarkBlack]

Hey Community,

Your NI FRC support team is currently hard at work creating examples using the APIs that will be shipping with the LabVIEW FRC Software Suite. Most of our examples so far are simple demonstrations of the basic way you can control motors, read from sensors, etc.

But what we lack are ideas for higher level examples that will be critical for most teams to create a fully functional robot (such as two or more API interacting in a particular way to implement a specific function).

This is where we need your help! Let us know what examples you are clamoring for because there is a very good chance you will see them when you receive your Kit of Parts.

Cheers,

FRC Support Team

[LabViewEnthusiast]

Thanks for all of your hard work! I am a progammer and here are some examples that would be nice to see:

Examples of different ideas of how to mix the joystick X and Y axis and get a Right/Left Motor output. Scenarios that these examples are modeled for include: tank style, omni wheels, mecanum wheels, and all of those with examples for one joystick and for two joysticks.

How to scale the joystick inputs to make the input more sensitive, less sensitive, creating a dead zone, and creating what I call a "slow zone". This is simmilar to a dead zone, but the inputs that apply for this zone are higher than a dead zone, and instead of outputing 0% power, a "slow zone" outputs a single value for multiple input values (say, maybe, 10% motor power) (if an input is higher than the "slow zone", the output will be normal). It is helpfull for when you want to drive your robot slowly. (I have no idea if this type of thing actually exists, I thought of it myself)

Using the camera and the vision software to track objects and to make the robot do something depending on where the tracked object is or how large it is (i.e. drive right or left to "aim"; think 2006 game Aim High)

How to use 3D and 2D controls to show a robot (or even just a cube or rectangle) driving around responding to the joystick. Also, examples that show how you can display a simple field or some game pieces on the control. Maybe not have the virtual robot interact with the game pieces; that might be too advanced. At least have the robot stop if it is touching the wall of the field or something like that. This is useful for testing your joystick input/output and testing autonomous code when you don't acctually have a robot ready to test it with. Can also be used to see the approxamate possition of your robot on the field in-case you can't see it. And because it's downright cool!

How to set up a blinking button or some other indicator that notifies the user that the autonomous code is currently running. Also, it would be nice if you could make a big "sign" or an indicator like the one discribed in the previous sentence (maybe a button?) that can be switched (like an enum) between states. This would show the user which mode the robot is in, depending on the different modes/states in the strategy of the team.

And for those loyal C coders, examples of how to implement C (or C++) into LabVIEW VIs.

I think that's it, I hope that's what you were looking for and that I was of some help. Thanks again!

[LabViewEnthusiast]

Also, with the 3D and 2D control examples, there was a project done by NI employees or some college students that included this type of thing, so that's what I'm looking for. They made a tank and I remember that it had a camera on it. I posted about it before and someone replied back that they were going to get more information on it. Has more stuff been posted somewhere about that tank?

Also, in the tank project, they had the picture control make a line of where the robot had driven. They also had the capability of having the robot backtrack on that line. And I remember one thing that at the FIRST world championship, the "Nitro" robot had the ability to drive on a path that the user drew on a picture control. It would be nice to know how to do all of these things and to have examples on them.

Thanks!

[MarkBlack]

LabVIEWEnthusiast,

The video you are refering to can be found here. The cRIO tank was created by a group of NI Application Engineers at our UK branch. I will see if I can find the source code for this project as well as the source code for Nitro and post them to the community.

Some things to keep in mind is I will not to add any additional documentation to help explain the code for new users. Furthermore depending on what LabVIEW Toolkits and Module were used to create these demos some users will not be able to open the projects without some VIs missing.

Thank you very much for the feedback. This is exactly the type of information we are looking for!

-Mark

[Jon236]

1. a Drive Simulator: like the FRC toolkit provided a couple of years ago, you could specify chassis dimensions and weight, wheels, transmissions and motors. You would then be able to 'drive' and test under different conditions, evaluating motor output and current.

2. similarly, an Arm Simulator: specifying dimensions and motor selection.

3. integration of encoders and potentiometers with arms

just a start!

[cabbagekid2]

Depending on how we build our robot from year to year, sometimes it ends up not driving very straight (veers right or left) due to weight distribution and issues with placing heavy parts like the battery and compressor. We previously corrected this through programming by adding an offset to the motor speed based on trial and error depending on what the drive encoders read.

Can you come up with an example on how to use sensors (gyro and encoders) to automatically correct the robot when attempting to drive straight? For example, when going foward check sensors to see if robot is going straight, if not correct. Ignore if robot is not going forward or backward (when robot is turning). We would most likely implement this during autonomous mode.

As in the previous posts, controlling an arm with potentiometers and also a automatic tracking example using the camera would be helpful to us.

Look forward to seeing all the tutorials and examples! Thanks.

[Philbot]

I also echo the response about gyro based driving.

The most common implementation would be for a basic differentail style two-wheel drive system.

ie: Two rear wheels with independant control, and two forward omni-wheels (or casters).

Manual (straight) steering is quite difficult with this configuration but it provides great mobility.

Ideally a gyro is added to the robot to stabilze driving.

I'd recommend a single joystick control whereby the Y axis controls forward speed and the X axis controls turn rate.

Add a turning deadband to the joystick to make straight forward high speed driving easier to obtain.

I'm a FRC Beta tester, so this is the sort of thing I'll be trying to acheive myself... but just in case I fail... getting the experts to do it would be a blessing 🙂

[LabViewEnthusiast]

Actually, I think that the most common wheel configuration/drivetrain is the six wheel chassis. The right and left sides of the robot each have 3 wheels: one in back, one in front, one in the middle. The middle wheels have their own motors driving them, the front and back wheels oporate like castor wheels; they are not powered and can pivot/roll in any direction. Typically these front wheels are castors or omni wheels. It is driven in the typical "tank style" with one or two joysticks.

I searched Chief Delphi and I found that this was the most popular type of drivetrain, unless, the game design called for something specific, like macanum wheels or whatever. I also agree that it is the best type. The one explained above by Philbot was used by our team last year. It works, but the design that I mentioned is better because the drive wheels are in the middle, where the center of rotation is. Then the robot doesn't swing as much when it turns, the swinging/turning motion can be stopped easier, and it doesn't take as much power to turn it. The robot can also turn in place, which is a big positive note.

So, people at NI, just take note of that type of chassis design and steering/control method (tank style). Also take note that it is very popular.

[Philbot]

Usually if people use 6 wheel drive, I think that all 6 wheels are driven, and in this case the robots tend to drive straight with little help.

If they use a center drive, with casters/omni then the control problem is the same as rear wheel drive with omni, and so it's a moot point what the actual wheel configuration is.

The only significant variation might be in the Operator Control where either Tank or Arcade style driver input is used (2 joystick vs 1 joystick).

Since the two joystick approach is typically used for bang'bang control where it's either going straight or spinning, a single arcade style joystick input is more likey to be used with a gyro based system (where more refined control is desired).

[jaustin]

Our team has been using a modified version of Kevin Watson's autonomous code. Check that out to see the kinds of things we use.

http://www.kevin.org/frc/ We will be looking for examples of DAQ's like encoder readers, gyro readers, potentiometer and limit switch, ultra sonic or ir range sensors. Most importantly we will be looking for help with PID controlers for drives (that can help with the "going straight" issues noted above) and arm parts (shoulder, wrist, etc.) .

Thanks for all your efforts, looking forward to a great new season!