Display warning when clock is not set

[Nanoseb]

It is a pain to correct the timestamp even with the adjust.py. It would be better if we remember to set it in the first place...
Having a warning on the PS1 when the clock is not set will help not forgetting that.

[takluyver]

I don't think the Pi knows when its clock is wrong, though it could have a flag that is set at boot and cleared when you update the clock.

It might also be worth looking into getting a real-time clock module - see previous discussion in #175. I think we found that the GPS unit has a RTC in it, but it needs a small battery attached. Then we'd also have to set up some service on the Pi to use it.

[Nanoseb]

What we've noticed I think is that we are never in the future. So something I thought about was to record in a file the time and do something like:

if current_time > stored_time:
    store current_time in stored_time
else:
    print warning time not set correctly

But the flag idea is good too and probably even better than that.

Concerning the RTC clock in the GPS, I didn't know that, worth looking into it too.

[takluyver]

My understanding is that it saves the current time on shutdown and restores it on boot - so the clock's not going backwards, it's just 'stuck' while there's no power. If that's the case, then your check wouldn't see a clock reading earlier than its saved time. Although maybe it would work when there's a hard shutdown - I don't know if the Pi can save its clock in that case.

[Nanoseb]

Ah indeed, in that case your solution is definitely better. I think it saves the clock only when you power it off cleanly (not unplug it), because for example in calshot, we set the clock correctly on thursday, but it was off again on friday.
Anyway your for now (without new hardware) your flag solution is better, I'll try to implement that if when/if I have time (anyone else can do it if I haven't done it already).

[smaria]

NTP sounds like the most elegant solution for this sort of thing, but at least I failed to set this up for delphin. May be worth adding an automated update via SSH, based on something like this: https://www.commandlinefu.com/commands/view/9153/synchronize-date-and-time-with-a-server-over-ssh

Catching up on issues, it seems several issues we have (checking that the time is set, maybe even setting it by trying to ssh to tabarly, getting everything named with the date as a prefix) could be solved by packing the ros script inside a bash script, which will check on a couple of things before actually launching anything.

[Nanoseb]

We have a similar command in time2pi.sh (https://github.com/Maritime-Robotics-Student-Society/sailing-robot/blob/master/piaccess/time2pi.sh).

Concerning NTP, in the special case of the sailing robot I don't think it is a particularly elegant solution. The boat will periodically ask for the time to a server (tabarly?) (and we can force a sync too). So this means that we need to set up tabarly as a ntp server, this also mean that if for any reason tabarly is not available during the setup then getting the time is harder. NTP is nice for system that are constantly connected to internet/an ntp server. The gain of NTP compared to the SSH command is just precision, but I don't think that is really relevant in our case.

How I see it for now:

• if GPS available we should get the time from there
• as a fall back we set the time from the SSH command in time2pi.sh or a reversed version of it (timefromtabarly.sh?)

And I agree that making this automatic would be a good improvement, maybe just wrapping roslaunch in a bash script that does a couple of checks and set up as you mentioned is a way to go. Then we still only handle and edit one file (the launchfile.xml) but there is automatic checks before actually running roslaunch launchfile.xml.