Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Programmers: I Have A Challenge For You (http://www.chiefdelphi.com/forums/showthread.php?t=84797)

Greg McKaskle 30-03-2010 20:36

Re: Programmers: I Have A Challenge For You
 
On the LV compilation topic, the LV source code is a dataflow graph of objects -- diagrams contain nodes connected by wires, with the occasional node containing other diagrams

The objects are visited over several passes in order to perform compilation tasks.
1. Data types are propagated after each edit.
2. Nodes are validated and syntax errors identified after each edit.
3. An algorithm performs what we call clumping -- coloring the graph based upon asynchronous operation.
4. Another algorithm improves inplaceness, reordering nodes to execute in an order which minimizes data copies.
5. Nodes allocate data storage.
6. Nodes emit code into clumps.

Clumps are blocks of memory that contain machine instructions in binary form. You can disassemble the instructions if you like and display them in text.

Of course the LV graph could be stored into a textual graph form, and internally, we experiment with such things as a save format. The compiler, however, does not operate on a sequential "tape" of characters.

On the robotic topic, instead of waiting for next years game and potentially interfering with the progress of the team, why not pretend that you just learned of this year's game. Start to automate the tasks given the current field and robot.

You state that the camera has lots of lag, but perhaps you should concoct a test to measure the lag. I did it last year, and it isn't that bad to the cRIO. If you test thoroughly, it isn't bad to the PC either. Anyway, try using different sensors and the camera to find the goal, find balls, find lines on the floor, find the edge of the field.

I'd consider it a huge step forward if robots in autonomous would detect the walls of the field and would do something other than barrel into them at high rates of speed.

If you have those elements, start trying to identify and track robots. Try to plan a path to the ball avoiding the robots...

This and all FRC games are built to challenge human drivers. There are more than enough challenges to keep SW people busy trying to navigate.

Greg McKaskle

Tom Bottiglieri 30-03-2010 21:14

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by Chris is me (Post 945952)
My #1 priority for alliance selection at CT is strength of back autonomous mode. It's that important to winning, in my opinion.

Don't box yourself into a corner. I believe you are exercising a bit of confirmation bias by believing autonomous is the end-all, be-all that makes a team successful. The teams that win are the teams who have the experience and expertise to build high quality machines and play well thought out strategies. If they have gotten to that point, they probably put the time in to make their autonomous mode work well.

For example, I could say that the only thing I will be looking for in a team is the ability to hang in under 3 seconds. Does that make a robot good? Not necessarily, but the teams who planned ahead enough and implemented this strategy are probably strong to begin with. The hanging is just an indicator of this.

The problem with this is that there are always corner cases. There is always going to be a team that has a strong auto, but has a bone-head driver who just racks up penalties. The same way there will probably be a team who hangs fast, but can't do squat for the rest of the match.

All in all, looking at a team's auto mode is probably a smart thing to do. But, there are a bunch of other aspects to what makes a team successful, and many of them are intangibles. If you want to pick like the pros, don't put all of your eggs in one basket.

Chris is me 30-03-2010 21:18

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by Tom Bottiglieri (Post 945987)
The problem with this is that there are always corner cases. There is always going to be a team that has a strong auto, but has a bone-head driver who just racks up penalties. The same way there will probably be a team who hangs fast, but can't do squat for the rest of the match.

I don't mean to say that robots with strong autos are invariably higher ranked than robots without them (or at least I don't now, after reading your post), but that of a list of qualities I want in an alliance partner, strong autonomous is probably the most important. I guess the best way to phrase how I intend to pick is like evaluating robots with a WOT; autonomous right now would have the highest weight, but not enough to offset other categories.

dtengineering 30-03-2010 21:19

Re: Programmers: I Have A Challenge For You
 
Perhaps an interesting way to implement the challenge would be to build it in as part of the Breakaway game simulation.

There are several "competitive coding" games of this nature... a simple one that I use to teach PIC assembly language is called PicBots, but there are many more complex ones. A list of some is at http://www.google.com/Top/Games/Vide...ames/Robotics/ I've used CRobots3D and AI Wars with junior students as a programming introduction.

The advantage, of course, is that the robots can compete in an ideal environment and can access all kinds of expensive "sensors", and the programmer can have access to the "robot" 24 hours/day at basically no cost.

Once the algorithms are worked out in the simulated environment, then they could be ported to a robot for real. Kind of like building a robot in CAD before cutting out the parts.

The added advantage, of course, is that by developing an AI for the Breakaway game simulation, it would be possible to play the game with fewer than 6 people.

Jason

davidthefat 30-03-2010 21:28

Re: Programmers: I Have A Challenge For You
 
All of you who are attempting this, how do you suppose you will get started? I am thinking of making an omni drove robot with 2 gyros, one in the main body and one on a little platform that a server will rotate up and down. 2 IR sensors mounted on a servo that will rotate it side to side will scan in front of the robot and the other 2 mounted on the platform will also scan side to side. they will take in an array of data regarding the objects inthe way

Tom Line 30-03-2010 21:59

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by davidthefat (Post 945995)
All of you who are attempting this, how do you suppose you will get started? I am thinking of making an omni drove robot with 2 gyros, one in the main body and one on a little platform that a server will rotate up and down. 2 IR sensors mounted on a servo that will rotate it side to side will scan in front of the robot and the other 2 mounted on the platform will also scan side to side. they will take in an array of data regarding the objects inthe way

I'm curious. Are you aware that a single hard collision can easily throw a gyro off by hundreds of degrees?

We removed our gyro from this year's competition bot - we were using it to measure inclination in order to automatically stop our winch - because each time we fired our kicker (it was a 300+ degree per second gyro) it would lose 30-40 degrees in a random direction. In fact, we tried 6 different gyros, all the ones we had in the build room, and they all showed the same results.

We used one in 2009 to make our turret field-oriented and had the same issue when we had a hard collision.

I'm also curious why you want a gyro on a platform when servos can be commanded accurately to any angle you want?

theprgramerdude 30-03-2010 22:06

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by davidthefat (Post 945995)
All of you who are attempting this, how do you suppose you will get started? I am thinking of making an omni drove robot with 2 gyros, one in the main body and one on a little platform that a server will rotate up and down. 2 IR sensors mounted on a servo that will rotate it side to side will scan in front of the robot and the other 2 mounted on the platform will also scan side to side. they will take in an array of data regarding the objects inthe way

Personally, I was thinking more along the lines or using two accelerometers mounted on opposing sides of the robot to measure motion and turn, as well as two front facing camera's for depth perception and (maybe) object recognition.

IMHO, we would need more processing power to develop complex strategy's that a human could think up, which is why I'm trying to figure out if <R50> means we can't use a DC-DC converter (I thought there was one powering the Crio) to power a mini-PC attached to the robot for image analysis.

Edit: something along the lines of this: http://www.mini-box.com/M4-ATX?sc=8&category=981

<R50> Custom circuits shall NOT directly alter the power pathways between the battery, Power Distribution Board, speed controllers, relays, motors, or other elements of the robot control system (including the power pathways to other sensors or circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S electrical system is acceptable, because the effect on the ROBOT outputs should be inconsequential.

davidthefat 30-03-2010 22:07

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by Tom Line (Post 946015)
I'm curious. Are you aware that a single hard collision can easily throw a gyro off by hundreds of degrees?

We removed our gyro from this year's competition bot - we were using it to measure inclination in order to automatically stop our winch - because each time we fired our kicker (it was a 300+ degree per second gyro) it would lose 30-40 degrees in a random direction. In fact, we tried 6 different gyros, all the ones we had in the build room, and they all showed the same results.

We used one in 2009 to make our turret field-oriented and had the same issue when we had a hard collision.

I'm also curious why you want a gyro on a platform when servos can be commanded accurately to any angle you want?

Gyro are cool... but seriously, I don't always want to rely on just one sensor, thats why multiple IR sensors are used, A sonar probably will be used. Its just being on the safe side I guess.

davidthefat 30-03-2010 22:15

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by theprgramerdude (Post 946023)
Personally, I was thinking more along the lines or using two accelerometers mounted on opposing sides of the robot to measure motion and turn, as well as two front facing camera's for depth perception and (maybe) object recognition.

IMHO, we would need more processing power to develop complex strategy's that a human could think up, which is why I'm trying to figure out if <R50> means we can't use a DC-DC converter (I thought there was one powering the Crio) to power a mini-PC attached to the robot for image analysis.

Edit: something along the lines of this: http://www.mini-box.com/M4-ATX?sc=8&category=981

<R50> Custom circuits shall NOT directly alter the power pathways between the battery, Power Distribution Board, speed controllers, relays, motors, or other elements of the robot control system (including the power pathways to other sensors or circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S electrical system is acceptable, because the effect on the ROBOT outputs should be inconsequential.

I was thinking of forgetting the cRio as of now and using a custom made microprocessor board, since its just experimental small prototypes

theprgramerdude 30-03-2010 22:22

Re: Programmers: I Have A Challenge For You
 
By ditch the Crio, do you mean just build an autonomous robot independant of any competition with the spare parts from FRC?

davidthefat 30-03-2010 22:29

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by theprgramerdude (Post 946036)
By ditch the Crio, do you mean just build an autonomous robot independant of any competition with the spare parts from FRC?

I guess, I just want to build a prototype robot that is not using the crio, since the crio and the power board itself will take up most of the space of the robot (2 x 2 feet) so why even bother? Just get the essential ideas working and then we can transfer it to the actual robot during the 6 week build period. I just have to just port the code, configure the sensors to work for the robot bigger size. I try to code so that its reusable and easy to understand. So I have to get in the habit to comment a lot, because I tend to forget what some of my code does sometimes, it looks so complex at times IDK how I even coded some stuff:ahh:

gvarndell 30-03-2010 22:34

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by Greg McKaskle (Post 945970)
On the LV compilation topic, the LV source code is a dataflow graph of objects -- diagrams contain nodes connected by wires, with the occasional node containing other diagrams

The objects are visited over several passes in order to perform compilation tasks.
1. Data types are propagated after each edit.
2. Nodes are validated and syntax errors identified after each edit.
3. An algorithm performs what we call clumping -- coloring the graph based upon asynchronous operation.
4. Another algorithm improves inplaceness, reordering nodes to execute in an order which minimizes data copies.
5. Nodes allocate data storage.
6. Nodes emit code into clumps.

Clumps are blocks of memory that contain machine instructions in binary form. You can disassemble the instructions if you like and display them in text.

Thanks for this. It is good information to know.

That said, it's not the compilation I was asking about.
Assuming that a node is what I was calling an icon and graphically represents some logical or computational operation, there must exist some sequence of machine instructions to implement that operation.
You referred to these as clumps.
An assertion was made that there is no traditional textual source code associated with clumps -- notwithstanding that that terminology was not part of the discussion.
My claim is simply that the machine instructions contained in those clumps almost certainly were produced by a traditional compiler using a traditional text-based programming language -- quite likely C.

For the record, this didn't start out as a Labview discussion and I didn't lead it here -- nor did I want to.
There was first a claim that iconic programming was replacing text based programming.
I claimed that, on the contrary, text based programming is the foundation upon which iconic programming is built.
Icons (nodes if you prefer) graphically represent machine code.
AFAIK, other than compiling and/or assembling text files, we have no spiffier way of producing the machine code.

davidthefat 30-03-2010 22:38

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by gvarndell (Post 946047)
Thanks for this. It is good information to know.

That said, it's not the compilation I was asking about.
Assuming that a node is what I was calling an icon and graphically represents some logical or computational operation, there must exist some sequence of machine instructions to implement that operation.
You referred to these as clumps.
An assertion was made that there is no traditional textual source code associated with clumps -- notwithstanding that that terminology was not part of the discussion.
My claim is simply that the machine instructions contained in those clumps almost certainly were produced by a traditional compiler using a traditional text-based programming language -- quite likely C.

For the record, this didn't start out as a Labview discussion and I didn't lead it here -- nor did I want to.
There was first a claim that iconic programming was replacing text based programming.
I claimed that, on the contrary, text based programming is the foundation upon which iconic programming is built.
Icons (nodes if you prefer) graphically represent machine code.
AFAIK, other than compiling and/or assembling text files, we have no spiffier way of producing the machine code.

Text based programming will NEVER go away, it will be used to code those programs that are iconic or whatever... The click and drop ones. and the text based programming will also code the operating systems. and I doubt there will be enough freedom in the drag and drop ones. They are all high level, which means you can't have pointers, you can directly mess with the memory, click and drag will never replace text based programming

mwtidd 30-03-2010 23:27

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by Tom Line (Post 946015)
I'm curious. Are you aware that a single hard collision can easily throw a gyro off by hundreds of degrees?

I'm just curious have you tried using a compass to re-zero the gyro? I haven't tried it but from what I've read it seems to create an almost drift less gyro as the compass doesn't have the issues of drift.

note: running a compass is an expensive operation so it should only be run to reset the gyro which is less expensive (or so I've read...)

davidthefat 30-03-2010 23:53

Re: Programmers: I Have A Challenge For You
 
Quote:

Originally Posted by lineskier (Post 946084)
I'm just curious have you tried using a compass to re-zero the gyro? I haven't tried it but from what I've read it seems to create an almost drift less gyro as the compass doesn't have the issues of drift.

note: running a compass is an expensive operation so it should only be run to reset the gyro which is less expensive (or so I've read...)

Its only about $30 for a compass, will think about it. Gyros are also about $30-$40 too, may be I will just try with 1 gyro, 2 IR and 1 sonar before adding more sensors


All times are GMT -5. The time now is 18:52.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi