Go to Post I think there is much to be learned from working in teams, and team projects, but even more when you go out on your own some time for something you are truly passionate about. - paul_v [more]
Home
Go Back   Chief Delphi > FIRST > General Forum
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #13   Spotlight this post!  
Unread 12-06-2015, 18:05
Ari423's Avatar
Ari423 Ari423 is offline
LabVIEW aficionado and robot addict
AKA: The guy with the yellow hat
FRC #5987 (Galaxia)
Team Role: Mentor
 
Join Date: Mar 2015
Rookie Year: 2012
Location: Haifa, Israel
Posts: 540
Ari423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant futureAri423 has a brilliant future
Re: On the quality and complexity of software within FRC

I'm afraid I have to agree with OP. I am the head (and only) programmer on my team, and have been so for the past 3 years, so I have a lot of experience with programming for FRC.

I will be the first to admit programming is hard to do well, but I think some teams just aren't putting enough effort to make their code efficient. Just today on CD I saw a piece of code (which I will leave unnamed) that almost brought my eyes to tears in its inefficiency. Even without a programming mentor and with a 6 person team, I have always put an emphasis on code efficiency and design as well as effectiveness. Sometimes I feel as if the FRC community has taken all of the focus from programming and moved it to mechanical, and left programming as an afterthought: something that you just throw together in a few hours to make it work and then never look at again. I understand that there are multiple ways to do a single task, but some ways ARE better than others.

A good example of this is dashboards. I cannot speak to programming a Java or C++ dashboard, but I know that making a dashboard in LabVIEW is easy to do, relatively speaking. Every year, after I finish the robot code and control panel, while I am waiting for the robot to be ready to test on, I program a dashboard that shows the important information coming from the robot, and adds other inputs than those on the control panel (trims, resets, etc). It usually looks something like this:
Click image for larger version

Name:	Robot Dashboard.JPG
Views:	194
Size:	67.1 KB
ID:	19123
It doesn't take long to make, makes debugging much easier, and generally looks nice. We don't always use all of the displays, but they is at least one display for every aspect of the robot code. However, I often see much larger and more advanced teams who use LabVIEW but either don't have a dashboard, use the default dash, or make a custom dash with only a few numerical outputs. I don't understand; maybe someone can explain this to me. With the customizability given to you, why not make a dashboard suited to your needs that is easy to read and looks nice?

tl;dr Why is programming becoming an afterthought in the FRC community?
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 04:26.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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