Go to Post There can be only one.... - Koko Ed [more]
Home
Go Back   Chief Delphi > Technical > Programming > Java
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
  #12   Spotlight this post!  
Unread 13-02-2015, 15:04
cstelter cstelter is offline
Programming Mentor
AKA: Craig Stelter
FRC #3018 (Nordic Storm)
Team Role: Mentor
 
Join Date: Apr 2012
Rookie Year: 2012
Location: Mankato, MN
Posts: 77
cstelter will become famous soon enough
Re: What is the purpose of RobotMap.java in CommandBased?

Quote:
Originally Posted by MrRoboSteve View Post
That can be a valid approach, too, if the limit switch is exclusively part of one subsystem. In the past, we've gotten in situations where there's a tangle of subsystem references, only to get access to sensor state. The SensorSubsystem prevents that.

Having one subsystem referencing another also makes it easier to accidentally command the referenced subsystem. This breaks the "requires" model in the command-based framework, which is present to help you reason about where commanding might be coming from. You can certainly produce a correct program by doing so, but it is harder to think about. We deliberately design our robot program so that it is easy to think about.
I'm a C++ guy and I think one could solve the problem of subsystems driving other subsystems by making all motor driving functions non-const and all sensor reading functions const. This way one could provide only a const pointer to the other subsystems but non-const pointers to the commands allowing commands to drive the subsystems but not allow the other subsystems to, yet allow both access to sensor readings.

I did a quick look to see if Java provides similar, but it looks like perhaps not.

I'm trying to think if the idea of sharing a sensor between two subsystems perhaps indicates that a better subsystem configuration is possible. I'm not sure I like collecting *all* sensors into a globally accessible sensor class-- one subsystem may reset an encoder and mess up code in another for example.

I guess I prefer the idea of making access functions in a subsystem that owns a sensor better, but I think it could use further discussion.

I suspect perhaps that code in a subsystem that needs a sensor from another subsystem might better be coded in a command that requires both subsystems. But I think I can also think of counterexample where that won't work well.

Can you give a good concrete example where two subsystems require a single sensor so we can kick around various approaches to resolve it within the command based paradigm?
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 22: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