Autonomous Planning

[davidthefat]

Originally Posted by kamocat

Hey, isn't that semi-autonomous?

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?

[kamocat]

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.

[Radical Pi]

Originally Posted by kamocat

Perhaps humans should simply be used as data acquisition devices.

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

[nathanww]

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

So what you're actually thinking of is more like

void Pwn(float pwnLevel) {

My concern is that this might not give you enough precision. I'd personally go with

void Pwn(double pwnLevel) {

<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.

[kamocat]

Originally Posted by nathanww

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.

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.

[MattSr]

Originally Posted by ideasrule

The robot can get this info the same way a human can: by looking at the big TV screen. Possible?

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

[davidthefat]

Originally Posted by nathanww

So what you're actually thinking of is more like

void Pwn(float pwnLevel) {

My concern is that this might not give you enough precision. I'd personally go with

void Pwn(double pwnLevel) {

<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.

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

[Radical Pi]

Originally Posted by davidthefat

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

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

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?

[davidthefat]

Originally Posted by Radical Pi

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

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?

Thats when the driver flips the manual override switch

[ideasrule]

Originally Posted by MattSr

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

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.

[kamocat]

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.

[Radical Pi]

Originally Posted by ideasrule

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.

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.

[kamocat]

Originally Posted by Radical Pi

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.

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.

[Radical Pi]

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)

[kamocat]

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?