Quote:
Originally Posted by Patrick Chiang
LV:
+ Click and drag. How much easier does it get? If you know "line-based programming" before you learn LV though, it can be a nightmare.
|
LabVIEW tends to get a bad rap for its graphical nature. When the cRIO was first introduced to FRC in 2009 I saw the choice of LabVIEW and C++ the same as I saw the choice between C and EasyC on the old controller. I told myself that 'I'm too good' for drag and drop. It turned out there is a lot more to it than that. LabVIEW has some powerful constructs which do take time to master, and the front panel features make tuning/debugging incredibly quick and easy.
I would actually say that LabVIEW has a
steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.
In the end I agree about using the language that you have a mentor/student with a good understanding in. When you have an instructor with a good understanding of how things work, it is easier to teach it, and more importantly prevent big design mistakes early on.
Quote:
Originally Posted by Arhowk
Maybe the algorithms are the same, but the raw speed is alot faster.
|
I would be interested in seeing the data behind this claim, or some type of metric. Do you have a side by side comparison of the raw speed for various algorithms? I would assume all three languages would be nearly identical since they all call the same functions. Honestly I would expect Java to be the slowest since it has to run on the JVM level compared to C++/LabVIEW which are both compiled to assembly with many optimizations along the way.
Quote:
Originally Posted by Arhowk
Knowing what algorithms you want to use and simply typing them out is alot faster than dragging them from a box. Imagine typing this response by dragging a list of 100 words from a box into the text area.
|
Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.
Quote:
Originally Posted by Arhowk
Personally, I've walked around Kettering and Traverse City and I didn't see a single LV team using a targeting system they built themselves.
|
Its all about iterative design. In reality nobody is building a vision system 'themselves'. All of the functions and ideas we are using are built from years of industry and academic research as well as learning from previous years.
Should every team be reinventing the wheel each year? Most teams use the same type of algorithm, which is what the targeting system has been designed for. The example vision code is a good starting point and having a working vision algorithm is a big accomplishment for many teams. We don't all have to dive into OpenCV on a BeagleBone to track the retro reflective tape.