Go to Post PS: Sorry for derailing this thread even further. - Molten [more]
Home
Go Back   Chief Delphi > Technical > Programming > C/C++
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #11   Spotlight this post!  
Unread 06-02-2013, 12:35 PM
MrRoboSteve MrRoboSteve is offline
Mentor
AKA: Steve Peterson
FRC #3081 (Kennedy RoboEagles)
Team Role: Mentor
 
Join Date: Mar 2012
Rookie Year: 2011
Location: Bloomington, MN
Posts: 566
MrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond repute
Re: How much of WPILib is required for robot code to be legal?

I'd be interested in hearing more about the issues that you ran into with your robot code this year. While I have some "would have done it differently" moments with the command-based approach, we have not run into anything that prevented us from achieving our goals.

I mentally model WPILib as having several different subsystems, with important ones being:

. a class hierarchy that represents all of the physical devices that can be attached to the robot
. the NetworkTables abstracting, which is a state sharing mechanism between the DS and the robot
. A layered set of application-building frameworks that allow you to build a robot control system at one of three levels of abstraction:

Simple -- you handle the loop
Iterative -- loop abstracted out
Command-based -- event-driven

If you don't like the application-building frameworks that are provided, there's nothing in WPILib today that prevents you from building your own along side/above what is already there. In fact, if you build something new, it's adopted by teams, and you are careful about code ownership issues, you'd be in a good position to lobby to get your framework adopted into WPILib. The best model for this would be a library that is designed to work alongside WPILib.

If there are bugs in WPILib that you'd like fixed, the best approach is to report them with good repros attached, or a fix if you have one available. I've found the maintainers are very responsive to issues that I've reported. If you need the fix for your robot to work, bring the code for the class into your robot, give it a different class name, fix the bug, and run with that. No need to fork the whole thing in most cases.

Be sure you're ready to take on these issues with your fork:

. competition year updates (1-3) will need merging and resolving
. will need to quickly handle (1-2 days) any week 1 software updates (a la this year)
. harder for CSAs to provide support at competition (e.g., validating all required updates have been applied to the library)
__________________
2016-17 events: 10000 Lakes Regional, Northern Lights Regional, FTC Burnsville Qualifying Tournament

2011 - present · FRC 3081 Kennedy RoboEagles mentor
2013 - present · event volunteer at 10000 Lakes Regional, Northern Lights Regional, North Star Regional, Lake Superior Regional, Minnesota State Tournament, PNW District 4 Glacier Peak, MN FTC, CMP
http://twitter.com/MrRoboSteve · www.linkedin.com/in/speterson
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 09:36 AM.

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