|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
Re: Optical sensors getting tricked
Quote:
For position PID is great. Though we haven't used it before, I have heard that limiting the controller to PD or just P is still a pretty darn effective motion controller. To sum up, sensors don't have to be complicated. Even with complex code(like vision code) teams like 341 have made it much simpler and easier for the rest of us. Last edited by MichaelBick : 28-10-2013 at 21:47. |
|
#17
|
||||
|
||||
|
Re: Optical sensors getting tricked
Quote:
|
|
#18
|
|||||
|
|||||
|
Re: Optical sensors getting tricked
Quote:
...And reducing the variables (very few of the ones mentioned actually apply in closed-loop control). Actually, I'll start out with: The only variables listed that would have ANY effect at ALL on, say, a shooter, would be the battery voltage (which really only affects open-loop controls--unless it's totally dead) and the load on the motors (they do have to take a bit of load when the disc goes through--but that's why you have closed-loop control). All of the others have no effect on the control system, or should have been dealt with in the design of the robot (like bearing stress--just get a bearing rated for the load, don't worry about the bearing stress). Closed-loop control goes something like this: The cRIO sends a command to the speed controller to have the motor go speed X. The controller boosts the motor to speed X (as the controller sees it) by boosting power. A sensor on the shooter wheel indicates speed and sends a signal to the cRIO indicating the actual speed. The cRIO then compares the actual speed to the set speed and then tells the controller to increase power, decrease power, or keep the same power. cRIO->Controller->Motor->Sensor->cRIO->Controller... The program could look something like: speed = 100 if (sensor < 95) //speed increase else if (sensor > 105) //speed decrease An open-loop control, by contrast, goes: cRIO->Controller->Motor and looks like: speed = 100 in code. |
|
#19
|
|||||
|
|||||
|
Re: Optical sensors getting tricked
Quote:
![]() |
|
#20
|
|||
|
|||
|
Re: Optical sensors getting tricked
This thread is starting to smell of a simplicity VS. complexity argument.
|
|
#21
|
||||
|
||||
|
Re: Optical sensors getting tricked
Only problem with this is that mechanical problems are harder to fix at competition. At competition it is much quicker to fix a sensor or fix a peice of code than it is a mechanical part. Though if I may ask what sensor have the mechanical parts replaced?
|
|
#22
|
||||
|
||||
|
Re: Optical sensors getting tricked
http://www.chiefdelphi.com/forums/sh...8&postcount=25
These with the polarizing filter are very tough to fool. |
|
#23
|
||||
|
||||
|
Re: Optical sensors getting tricked
Quote:
Last edited by Sparks333 : 04-11-2013 at 22:30. |
|
#24
|
|||
|
|||
|
Re: Optical sensors getting tricked
Our team has used many different sensors and controllers over the years. My favorite still is the organic analog computer coupled with a organic analog visions processor. Each year we put 2 of them behind the driver station physical connected to the driver station computer. Being an analog system the programming is very difficult. Training a neural net is very time consuming. This year we have devoted allot of resource to train our analog system. We went to ever off season competition we could. Got to train those nets.
|
|
#25
|
||||
|
||||
|
Re: Optical sensors getting tricked
I have no idea what you're talking about, but the words 'neural net' have piqued my interests... You mean that you have a neural net managing your vision tracking, and that you have to endlessly test to train it?
|
|
#26
|
|||||
|
|||||
|
Re: Optical sensors getting tricked
I think he's referring two a couple of students.
|
|
#27
|
||||
|
||||
|
Re: Optical sensors getting tricked
whoosh
You have no idea how relieved I am :P I thought that FIRST programming had just sailed over my head and continued to evolve while I wasn't looking. My team was considering using an ANN last year, but we figured that the costs outweighed the benefits. |
|
#28
|
||||
|
||||
|
Re: Optical sensors getting tricked
Quote:
|
|
#29
|
|||||
|
|||||
|
Re: Optical sensors getting tricked
Quote:
Our Ultimate Ascent robot was designed to not require sensors, it just does it's thing based on it's design. Autonomous just requires the robot to be placed where it belongs, and it shoots into the goal. Shooting during a match works by driving the robot into position and shooting...position being determined by parking the robot against the pyramid. Angles and positions are fixed by design, and the actuation is pneumatic, it's either up or down, no "in between" positions that would require sensor feedback to control. We've spend days, make that weeks, trying to get sensors to deliver useful information to control robots over the years, and generally failed miserably at it. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|