Re: Autonomous Planning
 

You CAN think of it like that, but its like saying, want to use a nuke, a conventional missile or a machine gun? How much PWNage do you want?;)

Re: Autonomous Planning
 

No, I'm just giving you a bad time.
I really like the idea of giving higher-level methods of control to the drivers.
However, I think that could be used to supplement the robot, not as a primary form of making decisions.
Perhaps humans should simply be used as data acquisition devices.

Re: Autonomous Planning
 

Push a button on a score, tell the robot how many opponents are in each zone, stuff like that? It could be very useful information

Re: Autonomous Planning
 

So what you're actually thinking of is more like
My concern is that this might not give you enough precision. I'd personally go with
<seriousness>

Team 1678 has done some research on the kind of "operator as a data source" model that kamocat is describing, as well as a system for autonomous/hybrid action planning(hybrid refers generically to recieiving basic game information from an operator, not "hybrid mode"). Essentially the planning system consits of a component that "abstracts" input from sensors and/or an operator, "promotors" which respond to certain abstract conditions, and "payloads" which are instruction sets attached to the promotors which actually contain the robot's response to a certain condition. By altering "weighting factors" attached to the payloads and promotors, the overall tactics of the robot can be changed without needing to change the content of payloads(i.e.A robot can be made more agressive or more defensive by changing parameters that correspond to when agressive and defensive modes activate). In simulation(and potentially on an actual robot during the build season) a genetic algorythm can also be applied to the parameters to allow for machine learning.

Unfortunatley, we have never actually tested this system in competition due to the inherent risk(since we only go to one regional per year) and the opportunity cost of developing it, since we have a high rate of turnover in our programming team.

Re: Autonomous Planning
 

Neat!
I'll probably end up with some sort of weighting system, but it might use data that's a combination of the inputs. (Say, a ratio of gamepieces to robots.)
I like the idea of the weighting jitter, and the continuous scale from aggressive to defensive.

Re: Autonomous Planning
 

Highly unlikely, first the robot's camera needs to find the screen, second, even if it DID know exactly what the screen was showing, which would be extremely difficult, the screen is not always showing the whole field, it might be looking at a certain part of it or maybe not even looking at the field at all

Re: Autonomous Planning
 

Actually I was going to use an int for the variable not floats or doubles, It does not need to be that precise;)

Re: Autonomous Planning
 

needs to be an unsigned long. I don't want to be limited in how high it goes :P

What about reactions to sensors dying? If an encoder fails or something and starts returning bad values, what's the decision-making code going to do about it? Should it be the responsibility of the planning code to do sanity checks, or should that fall under the perception topic?

Re: Autonomous Planning
 

Thats when the driver flips the manual override switch:ahh:

Re: Autonomous Planning
 

I was saying that the robot can read the score off the screen. The score is always kept at the bottom of the screen, in white, against the same background, year after year.

Re: Autonomous Planning
 

How would an encoder fail?
I can see it getting wired backwards, but that wouldn't be a spontanious thing.
I could see it getting hit, expect that it's protected by the toughbox. Because of how quadrature encoding works, if an encoder is hit, the most that it can happen is it stops telling you it's moving.

Re: Autonomous Planning
 

There can be any number of things blocking the screen, especially with the score being on the bottom. Also, there is no guarantee within the FMS or the scorekeeper that the scoring display will always be showing. Also, it means dedicating a periodical scan of the arena for the score, stopping what you are doing to look for it. Having humans provide the data is so much easier and I doubt anyone would complain about something with that. Perhaps we can lobby the GDC to provide the score live to the robots for next year

With the encoder thing, if an encoder starts returning 0 speed constantly, any PID loop that uses that encoder spins out of control. A serious issue to think about.

Re: Autonomous Planning
 

How about a built-in self-test?
Do a short (~100ms) pulse on each of the wheels, each direction, to see if the encoders function?
This could also be used to test the state of the battery.
I'm thinking this is something that could be done while teams are waiting in queue.

Re: Autonomous Planning
 

The self-test is a good idea for the queue, but on the field I think a mid-match system in place. If something breaks in the middle of a match, a queue test will do nothing to help that poor robot driving around in circles on the field. Perhaps a slightly stronger version of the queue test to compensate for being on the field and the torque required to drive there (.5 second at 25%-50% speed?), activated by sanity tests (such as driving both sides but only one encoder spinning)

Re: Autonomous Planning
 

Have you ever seen an encoder failure?
I was under the impression that if the encoders are physically protected, and if they're wired up correctly, they won't fail.
They should be frictionless, because they are optical (the disk doesn't contact anything but the shaft).
The toughboxes protect them pretty well, as long as there's no dense objects that aren't fastened down.
Are the actually prone to failure?