Striving to learn more with Programming!

Technical NI LabVIEW
1

Hello all:

Entering my fourth year on a Robotics Team, and being my third year programming, I find myself a little upset with how much I truly know about programming with LabVIEW.

I see teams at competitions where their code is crisp, clean, and is 99% autonomous. Through the use of cameras and sensors they can target from anywhere, and in autonomous they shoot the frisbees then back up about 4 ft to prepare to go to the loading areas.

What I want to do is learn how perform some of these functions, not just your standard Drive, shooter, and basic Autonomous codings.

Think of it as a form of “This is your task, this is what you’ll do and how it’ll function” almost like a classroom being taught how to perform tasks through teaching, trial, and error. This thread is, I’m hoping, where users and programmers can come and try to learn something new.

In example: someone could post saying to make your camera work you’ll need a Begin, Teleop, and Finish vi with code to call the camera. See if you can get the camera to function!

Then someone who is rather new, unlike myself, would try to challenge themselves and see if they can truly figure out how to work the camera through this website, the tutorials on LabVIEW and other means of finding out.

I welcome any and all challenges/tips/advice/misc. information on this thread, as well as pictures of your code, wiring for specific functions, and anything else!

2

I’m not sure I understand how you expect this to work, but if you post questions or challenges that you are having difficulties with, myself and many others will be happy to help.

Greg McKaskle

3

The reason the same teams appear in the eliminations at internationals and at einstein is not because of their software, directly. It is because of their tactics. The robots on einstein might not be the best at what they do, but the robots on the alliance work the best together, does that make sense? You can be pretty certain that 868, 1986, 1114, and 2056 (and many other highly competitive teams the typically win multiple regionals per season) don’t just go into design. They analyse the game and decide how they want to play the game, then they design a robot to fit their style of play.

With that, they already know exactly what they want to do in the first week or so. 1986, the powerhouse from missouri, “only” had a floor pick up for the 7 disk autonomous mode. I put only in quotes because they did use it during tele-op, but the 7 disk auton gave them a HUGE advantage right from the start of the match, and the other team had to start behind, which can be very daunting starting a match 30 points behind in the finals of a regional.

The issue you have is no lack of skill, as you have said. It is lack of strategy. It’s what separates the good and the great teams. It is very hard to pick up these skills as a team. My team, 1706, has been a team for I believe 8 years now and don’t even think of going for extra disks in auton. We added moving backwards after we shot our 3 disks to get us closer to the feeder station to begin our fcs tactic. When we were blocked, we really couldn’t do anything. We were tall and slow. 2056 was a fcs and when they were blocked, they’d just cycle. and if a robot didn’t follow them to the feeder station, they’d continue being a fcs. This year 2056 and 1114 were unstoppable, winning 3 regionals together, I think I remember hearing that they work together, but I don’t know if that has any merit (but they do at least sign up for the same competitions, so…)

It isn’t difficult to program making the robot move back 4 feet after auton, or programming your robot to move forward, pick up two disks, repeat, move back and then shoot. Just takes timing of the motors, or vision (which an entirely different aspect of programming).

4

I’m also a little unsure what the intent of this thread is. Are you asking that we teach you new techniques, or are you suggesting that we create compendium of programming tips for programmers less experienced than yourself?

What do you consider “basic” autonomous routines? Have you successfully implemented complete autonomous routines for the last 3 years of FIRST games? If not, that would be a great place to start, especially since you’re already given example code as part of the LabVIEW distributions. Try to understand that example code, then write it again from scratch, perhaps adding any improvements you’ve thought of in the process. Hopefully your team has a programming “mule” robot that you can use to try out the routines.

If/when you’ve gone through this, check back and I’m sure we can help you brainstorm some more ideas for projects.

If you want something that’s more directly usable in the future, try coding a waypoint autonomous framework. It should work something like as follows: Accept a list of (x, y, angle) coordinates, where (0, 0, 0) is the center of the field, facing away from your team’s driver station. The first coordinate represents the starting position of the robot. The robot should then calculate the necessary movement to reach the next waypoint’s coordinates, and drive their using gyro and encoder feedback. Then, when you get the game, you can quickly try out autonomous routines by simply inputting lists of coordinates. Wildstang (111) had it working in 2003 (video is reposted on YouTube with 111’s permission).

Why don’t you start us out? Post up an example tutorial for some technique that you’ve already learned and found helpful, so we know what you’re intending with this thread.

5

The presentation gives very helpful insight into how StangPS works. There are some small math errors which may confuse some students viewing it. Worth discussing?

6

Perhaps. (I’m surprised it’s not been brought up before; that video’s been around for a while.) Is there one of your follower-wheel odometry posts that would be applicable?

7

If you are just interested in learning more about how to use LabVIEW to program your robot, including image processing, you could try this thread:
http://www.chiefdelphi.com/forums/showthread.php?t=120756

8

:slight_smile: … OK. Lets’ do it that way.

Question1: In the video, is the positive X axis pointing to the left or to the right?

9

Judging by the coordinate values given in the second half of the video, I would say the positive X axis is to the right, positive Y axis is up.

I think I see where you’re going with this though… in that the diagram showing angle theta as an acute angle doesn’t match the angle that would be calculated from delta-x and delta-y in the world coordinate system.

So to answer your original question, I think at this point it’s probably just worth noting that the video is meant to give an intuitive sense of how things work and the general types of formulae that will be needed instead of being mathematically rigorous.

My request for one of your odometry posts was meant to ask whether you already had a post somewhere that gave the correct mathematics, as it seems like something you might have covered before.

10

Yes. As I said in post 5, the presentation gives very helpful insight into how StangPS works.

My request for one of your odometry posts was meant to ask whether you already had a post somewhere that gave the correct mathematics, as it seems like something you might have covered before.

Aaron.Graeve did an admirable job of explaining the math in this thread. If anyone wants to explore this further, that would be a better thread to discuss it, so as not to hijack this thread.

11