search

Maritime-Robotics-Student-Society / sailing-robot

Southampton sailing robot
http://www.sotonsailrobot.org
Other
87 stars 46 forks source link

Display warning when clock is not set #259

Open Nanoseb opened 5 years ago

Nanoseb commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

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.