![]() |
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 |
Re: Programmers: I Have A Challenge For You
Quote:
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. |
Re: Programmers: I Have A Challenge For You
Quote:
|
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 |
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
|
Re: Programmers: I Have A Challenge For You
Quote:
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? |
Re: Programmers: I Have A Challenge For You
Quote:
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. |
Re: Programmers: I Have A Challenge For You
Quote:
|
Re: Programmers: I Have A Challenge For You
Quote:
|
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?
|
Re: Programmers: I Have A Challenge For You
Quote:
|
Re: Programmers: I Have A Challenge For You
Quote:
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. |
Re: Programmers: I Have A Challenge For You
Quote:
|
Re: Programmers: I Have A Challenge For You
Quote:
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...) |
Re: Programmers: I Have A Challenge For You
Quote:
|
| 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