Re: Autonomy: How Did You Guys Do It?
 

Wait... I'm not sure this is true. The encoder is plugged into the Digital Sidecar, which is plugged directly into the cRIO. There are no signals or math about the encoder being sent to the FPGA, the only thing that reads the values is the code. In fact, the FPGA only acts as a middle man between the driver station and the cRIO.

At least, this was my understanding.

Re: Autonomy: How Did You Guys Do It?
 

Incorrect. The FPGA is the middleman between the Crio's CPU and the majority of it's IO's. The FPGA can be directed in it's actions by the CPU, as the CPU is the boss, but everything on the sidecar runs through the FPGA, including encoders. David, if you claim that the FPGA is doing everything wrong, then why would you use encoders? As far as I can tell, the only thing it's doing wrong is deriving rates, which can be worked around. It can also give the CPU the value's the FPGA is reading at any instant, allowing you to completely write your own code from scratch. The FPGA CAN be accessed, just not directly; sometimes, you have to be sneaky in doing so.

http://decibel.ni.com/content/docs/DOC-1750
Figure 3 on this page may help clear things up.

Re: Autonomy: How Did You Guys Do It?
 

I really had no say in this. It was like: heres what we have and do something amazing with it. All I can use is encoders and timers. If the worst comes to worst, I will just use a timed system. My early tests have shown that there is too much noise coming from the encoders (just from the raw data). I think that is due to the chains on the drive train jerking around.

Re: Autonomy: How Did You Guys Do It?
 

It's harder then it seems, isn't it?

Re: Autonomy: How Did You Guys Do It?
 

No, we just flicked the wrist because my mentor did not authorize me to do anything else in autonomous. It was because we had a truck load of mechanical and electrical problems that I did not have time to actually go and test...

Re: Autonomy: How Did You Guys Do It?
 

The WPI lib's encoder class works great! Things have really come a long way since when I started in 2005 with the IFI stuff. The CRio, the language options and the libraries you have access to are great. I really encourage you to use some of this stuff rather than assuming you need to rewrite it or bypass it.

Re: Autonomy: How Did You Guys Do It?
 

I had originally planned on using the camera, but after about two weeks spent trying to get it to work found it just wasn't accurate or fast enough and even crashed sometimes. After this, I spent most of the time (whenever I wasn't programming the other aspects of the robot) working on a dead reckoning auton with just timers. This turned out to be super hard considering the rotational drift with mecanum wheels and the change in distance due to battery voltage. On the bag n tag day, I eventually just tried line tracking and we slapped on the three photoswitches to the front of our robot. Because of the time crunch (we literally got them on and calibrated at like 6 pm) and the fact that I couldn't figure out how to change the speeds in the pre-supplied line tracking code quickly enough, I just made my own, all it is is a bunch of cases, one for each possible combination, that outputs either straight, left, right, or stop which are then interpreted based on time.
Whaddya know, it actually worked. After the line tracking to get to the pegs, it was just a matter of timing a sequence of raising the arm, tilting the tube and lowering the arm.
But srsly, line tracking is amazingly simple and effective. I didn't even have to do any special programming for the Y, I just have two different modes, one for tracking the left edge and one for the right edge. It was pretty consistent at DC (after some last-minute time calibration on Friday to get the tube on just right) only failed us twice (one of which was during our second quarter match :mad:).

Re: Autonomy: How Did You Guys Do It?
 

The class is great! Now only if it's functionality was negated by the FPGA image...

Re: Autonomy: How Did You Guys Do It?
 

Something NI should have fixed long ago. As in, they shouldn't have touched the Counter/Encoder code since it worked perfectly fine last year. (then they decide it's too risky to fix during build season so they won't fix it at all....)

Re: Autonomy: How Did You Guys Do It?
 

Wished a lot of things were fixed beforehand. 2CAN for an example, thought it was working until it was found to be buggy again. :/

Re: Autonomy: How Did You Guys Do It?
 

Hmm, now I'm curious what functionality is negated?! I guess we're just using the count which is working fine.

Re: Autonomy: How Did You Guys Do It?
 

KOP line sensors, an ultrasonic mounted on the front, a 10 turn pot on our telescope, and a 3 turn on our wrist. We use a state machine on the line following. The line sensors are mounted close enough together that at some points two sensors will be read at the same time, and if that happens it will make fine corrections, while if only the outside sensors detect, it will make a coarse correction. The state machine will remember what state it was in last if no lines are detected, so we can start almost 90 degrees off from the line and once it reaches the line, it will track it, even if inertia carries the sensors across the line, because it will keep correcting back until it finds the line again. It detects a fork if it sees both outside sensors are lines but the center one is not. If it finds one, it drives straight ahead for a short time, then turns either right or left and goes straight until it meets up with a line again. It requires the middle sensor to be ground so that it doesn't try a fork at the foot of the line or if the driver come at the line at an extreme angle. The entire line following sequence is built into a LineFollower class, an object of which is passed to both the autonomous code and the teleop code, so the driver can use it any time during a match. The LineFollower keep its own state machine, so the auto code doesn't have to deal with finding forks or whatnot, and if a fork isn't registered, the auto code doesn't even care. The auto code just calls FollowLineStraight or FollowLineFork until the front ultrasonic sensor reads about two feet,at which point the scoring sequence is executed. At the beginning of auto, a PID loop puts the telescope and wrist to the correct positions, and once the robot gets close enough, the wriswrist tilts down, the telescope drops, and the rollers outtake simultaneously, and the robot backs off. The score sequence constants are held in a config file available to both teleop and auto, so an identical sequence can be called via the codriver's trigger. Our alliance had three robots with line following, and so we took the fork while our partners took straight. We got triple ubertubes in a couple elim matches.

TL;DR: our auto pwnz.

Funny story about pregame checklists: one match, we started off in high gear accidentally, which the constants were never tuned for. At the beginning of autonomous, we were alarmed to see our robot hurtle at us at nearly full speed (14 fps). At the scoring distance, it neatly stopped, hung the tube, and daintily pulled away. This all took about four seconds, which was far faster than the regular low gear attempts. After the match, our team captain demanded of me a two tube autonomous, now that I blew the "not enough time" excuse.

Re: Autonomy: How Did You Guys Do It?
 

Our robot uses mecanum drive with encoders on each wheel and a pot on the shoulder to tell us where the arm is. The code has a built-in script language for autonomous code so we can FTP a new script to the robot for every match (if needed). We also have code that records operator input and replays it. Both work pretty well though we've not tested as much as we'd like to this year. The weather-related delays during build season left little time.

We played with line following and with the camera. Our robot pretty much goes where you tell it to so the line following was not necessary and slowed it down. The camera consumes a lot of CPU (for analysis) and communications bandwidth and did not seem worth it this year.

Re: Autonomy: How Did You Guys Do It?
 

I believe our first autonomous was merely timed commands to different motors and solenoids. However, that was quickly scrapped when we also found out the effectiveness and simplicity of line tracking.

Equipment: 2 "eye" sensors, KOP
4 US Digital quadrature encoders, KOP (wheels)
1 "string" linear potentiometer, not KOP (not sure of manufacturer) (arm height)
2 solenoids, probably KOP (telescoping arm, aka "extendorizer")

We have two "eye" sensors tracking the line, simply dragging one side of the robot to stay on track. While the robot is moving along the line, at timed intervals (I believe), our arm moves up, stopping at a certain "string" pot value. At another time interval afterward, we "power" (not entirely sure of the terminology) our pneumatic telescoping arm to reach up to the top row.

The robot is stopped by reaching a certain encoder value. Two rollers on the bottom and top of our claw eject the tube, while a "jaw" to our tube lowers, allowing a quick ejection. Simultaneously, the arm is retracted, to lower it out of the way.

Once this operation is complete, the robot lowers the arm to a certain pot value, simply backs up to another encoder value, and then stops.

Commands can be sent to the robot via FTP with a text file, which is parsed. In the text file, available commands are vector or strafe driving (we have mechanums), retraction of arm, and arm position. You can also determine the encoder value you want to stop at, and motor speed.

Our last Ann Arbor District (last week) match, with the autonomous working perfectly (nearest red robot):
http://www.youtube.com/watch?v=TfGzUebFtfM

Re: Autonomy: How Did You Guys Do It?
 

it's a problem with rate calculations. I don't remember the details (I think only even numbered allocations of encoders can calculate rate), since we wrote our own rate functions, but NI has acknowledged the bugs and won't be fixing it until the offseason. I'll post a link to a more detailed explanation as soon as I find it again.

EDIT: see this thread, specifically this post and thispost.