Moving to a point between lights with autonomous

[kaszeta]

Originally Posted by Donut

Indeed it is, and I know our team is going that route. We looked at trying to score on in between legs early on, but decided it really wasn't worth it unless we had alot of extra time to work on that.

We're counting on filling in the gaps between the other teams going for the ones under the lights...

[Daniel_LaFleur]

Originally Posted by minfranco

I was just wondering if anyone has discovered a way to get the robot to a column between lights while in autonomous. A pointer in the right direction would be very helpful!

I'm not the programmer for our team, but ....


In order to be able to place a keeper between the spider legs that have the lighted targets your camera needs to detect 2 targets (*note: that may not happen depending on initial setup).

Once you have 2 targets (since they have range data) you need to do some trig. You need to calculate the center of the line between the lights, then calculate the offset of the spider leg from that line. Then you need to plot a course from your current position to that position.


@ kaszeta

Since he specifically asked for the spider leg between the target lamps, how are you going to know which legs have target lamps and which ones dont without a way of detecting the lamp???

[kaszeta]

Originally Posted by Daniel_LaFleur

Since he specifically asked for the spider leg between the target lamps, how are you going to know which legs have target lamps and which ones dont without a way of detecting the lamp???

Several techniques, but we're basically counting on the other teams on our alliance going for the ones on lights, and avoiding them. We've got several coordination strategies that should take care of interfering with alliance partners in case they have different strategies.... Right now, only time will really prove how well they work.

[Andrew Schreiber]

How about, instead of constantly checking your position on the field using the camera you only check once and figure out where you need to go. if you have some sort of guidance system (more accurate then time) then it is very possible to dead reckon to a position on the field and place from there. Simply calculate the way the moved the rack based off what you SHOULD be seeing as opposed to what you ARE seeing. Think about how the deep space probes navigate, they have a star map so they know what they should be seeing and if they get something different they react accordingly. One huge advantage is the decrease in the amount of code the processor has to run so it can run faster because it doesnt have to run through the math library every time. Though I like what kaszeta has been saying, if you cant figure it out with the camera there are other options out there. Perhaps your scoring mechanism will automatically find the spider leg... just think outside the box. The idea i posted just now is what I intend on doing (for at least one of the approaches) this year. Hope that wasn't too cryptic and actually helped a little.

[dpick1055]

The problem with attempting dead reconing based off where the lights start is that it is very hard to account for slippage of your wheels and what other robots will be doing. If your alliance has 3 robots going for the rack at once and you hit another robot on your way without some sort of feedback you will have no way of correcting yourself and getting back on target.

[gnirts]

Originally Posted by dpick1055

The problem with attempting dead reconing based off where the lights start is that it is very hard to account for slippage of your wheels and what other robots will be doing. If your alliance has 3 robots going for the rack at once and you hit another robot on your way without some sort of feedback you will have no way of correcting yourself and getting back on target.

Dead reckoning doesn't mean just setting some motor outputs and waiting for a specified amount of time. Dead reckoning in this case refers to the process of estimating the position of your robot based solely on speed and direction of travel and time elapsed since the last known position. The "reckoning" part referes to the fact that you can't get new known position information based on the location of the rack. You can, however, account for wheel slippage by using accelerometers and a gyro, which track absolute--not commanded--speed and heading since you left where you know you were. This system can be very accurate if implemented correctly.

Robinson Levin

[lkdjm]

Thank you all for you suggestions so far. Damien1247, I think I am going to do something similar to what you suggested, however, dpick1055 does have a valid point about the inaccuracy. To solve both problems, why not use the camera to get close to the rack, and then do "dead reckoning" based on where the camera tells you you are at that point. Anyway, thanks again, keep the suggestions and ideas pouring in!

[mjbrauck]

I might be wrong about this but if you use the old camera code that dose not actually know when it sees 2 lights but thinks it is 1 big light, and you lower the confidence necessary to track it should track directly between the 2 lights almost acting like a 3rd light in the middle

[lkdjm]

Just in case someone hasn't seen this yet, check out this thread to see what I am talking about for tracking 2 lights: http://www.chiefdelphi.com/forums/sh...ad.php?t=52467

[ebowla]

Yea, Donut has a point. Our team started this year and I do most of the programming. I haven't been able to figure out a way to pin down the spot between lights due to the movement of the rack with a camera and encoders, but I can get a tube on any spot under lights, thats 12 spots we can get. So even if you can only get the ones under the lights, it doesn't mean that you're at that big of an disadvantage. (although if your team can get 3 keepers in a row horizontally you are in pretty good shape)

[CircularLogic]

Disclaimer: I do not have a robot, nor have I seen a robot the entire season (stupid graduating High School to go to college). However I have been thinking about this for quite some time.

Note: I fully thought it out around kick off. This is what I remember. Hopefully it can get you thinking in a good direction.


The first thing you need to have planned for in your autonomous is knowing your starting position, because that will make a difference later on.

When the autonomous period starts, have your camera track the closest light. Figuring out which light is the closest should be able to do be done relatively easily based off of the fact that you know all cameras are a constant distance apart. Then simply do an an angle check of the pan on the camera. If its too great, tell the camera to search the other way.

Now, once you have that target, you can make some reasonable estimates about the position of the off-light row. Using trig (specifically the law of cosines) you should be able to calculate the distance you need to adjust your robot in the X axis direction. That requires some ability to make reasonably accurate turns and movements (if you dont have some type of closed loop system, I would say go with the slowest viable speed to make those movements). Once you are aligned in the X direction, deploy your mechanism and drive forward the estimated distance that will get the ringer on the spider. I realize that you will be approaching the spider at an angle, but worst case scenario is about a 45 degree approach to it, which most arm designs should be able to handle.


Its not the best way. Its probably not fully thought out. It absolutely isnt tested. But the the thing it has going for it is that the math will work. There are a number of known things about the field when you first start the match, you have to use those to your advantage. It involved a lot of angle calculations. It involves creating lots of triangles to figure out distance accurately. When looking to make those triangles, remember a couple of things. Your robot will always be approximately the same distance away from the rack regardless of orientation but dependent on starting position.

The straight line distance is between spiders is a very useful thing for creating triangles.


Good luck.

[1768]

Our team can (probably) score between lights. I made a rom table of trig values and used that to approximate where each light is. Knowing two lights and their relative positions to each other, it can find the center of the rack and angle of rotation, and therefore where leg #3 is. Of course, this is still untested.