Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCLK and PositionSensor get out of sync #5

Open
mo3pheus opened this issue Dec 18, 2017 · 4 comments
Open

SCLK and PositionSensor get out of sync #5

mo3pheus opened this issue Dec 18, 2017 · 4 comments
Assignees
Labels

Comments

@mo3pheus
Copy link
Owner

Problem: The SpacecraftClock and PositionSensor for the Rover can get out of sync ( a minute apart or more ).

Cause: The SpacecraftClock and PositionSensors run on separate threads and get kicked off at different times, Over a period of time due to thread synchronization and waits for lock acquisition, they can get out of sync. If the timeScaleFactor is 60 - these discrepancies can add up quickly.

Solution: There is a command you can issue to the Rover for clockSynchronization - this syncs up the spaceCraftClock and the positionSensor. Unfortunately right now the rover waits for this command to be explicitly issued from the commandCenter.

Ideally the rover would have a tune up thread that measures the difference between the spaceCraftClock and the positionSensor Clock and triggers a sync if that difference gets above a certain threshold.

Solution II - tried implementing this but it failed due to thread sync issues. But ideally you could have the PositionSensor as an observer to the spaceCraftClock - i.e. when the spaceCraftClock updates, so does the positionSensor. This makes a cleaner solution than having the positionSensor ticking on a separate thread and dependent upon periodic forced syncs. The clock Syncs are not without their cost - the pacemaker and roverGarbageCollector are both restarted when this happens. Also conceptually the spaceCraftClock should be the final word upon what time it is on the spaceCraft. This is the computer's internal clock and all components rely upon it for their time. Look to how the TelemetrySensor is tied to the trackingAnimationEngine to see how this could be done.

Things to learn from this issue:

  1. Thread synchronization.
  2. Usage of the marsConfig properties file in configuring the rover.
  3. Understanding of the timeScale factor that affects all rover communications.
  4. If SolutionII is selected, the observer design pattern.
@mo3pheus
Copy link
Owner Author

Matt - not to pressure you into doing something you don't want to - but if you decide you want an issue to look at - this could be a good start.

@mo3pheus
Copy link
Owner Author

roverDevel is where all bugFixes go to.

@mo3pheus
Copy link
Owner Author

2017-12-17 20:42:01,610 [pool-4-thread-1] INFO space.exploration.mars.rover.kernel.SpacecraftClock - Internal time::2016-01-01T03:03:00.000-06:00 sclk of::1/01210:06:41:14:91150
2017-12-17 20:42:07,691 [pool-4-thread-1] INFO space.exploration.mars.rover.kernel.PositionSensor - Houston - this is curiosityActual.ephemerisTime: 5.04889748183912E8
stateCuriosity: -2.21331994261E8
stateCuriosity: -1.12446652913E8
stateCuriosity: -4.1574799206E7
stateCuriosity: 28.484
stateCuriosity: -15.194
stateCuriosity: -7.162
owltMSLEarth: 839.632
stateEarth: 2.2136176861E8
stateEarth: 1.12461782101E8
stateEarth: 4.158039376E7
stateEarth: -28.492
stateEarth: 15.194
stateEarth: 7.163
owltEarthMSL: 839.745
positionEarthWRTCuriosity: 2.2136176861E8
positionEarthWRTCuriosity: 1.12461782101E8
positionEarthWRTCuriosity: 4.158039376E7
owltEarthMSL2: 839.745
angSepHGAEarth: 112.029
utcTime: "2016-01-01~03:08:00"
sol: 1210
sclkValue: " 1/01210:06:46:06:88479"

@mo3pheus
Copy link
Owner Author

for Sol 1210 - in a few seconds the computer clock and the positionSensor clock are 5 minutes apart. With a timeScaleFactor of 60, every second for us means 1 minute for the rover.

This was done so that we wouldn't have to wait 5 minutes for the messages to go back and forth.

@mo3pheus mo3pheus added the bug label Dec 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants