-
Notifications
You must be signed in to change notification settings - Fork 0
/
NOTES.txt
247 lines (178 loc) · 11.9 KB
/
NOTES.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
########## General and user notes are in this file. ##########
########## Code development notes are in DevelopmentNotes.txt. ##########
########## Common OS setup (development) notes are in OSsetup.txt ##########
########## Raspbian and Raspberry Pi setup notes are in Raspbian.txt ##########
########## Armbian and Orange Pi setup notes are in Armbian.txt ##########
########## GPS notes are in gpsNotes.txt ##########
########## Venue specific details are in venue files (not on github) ##########
############################ Overview ############################
The program Gcheckout runs on a computer at the regatta registration desk.
It handles the process of configuring gizmos, assigning them to boats,
and checking them out and in (each day?). It also handles some related things like
moving boats between fleets or removing them. The Gcheckout program has a
graphical interface (GUI).
RC refers to Race Committee. The program RC runs on a computer (laptop) on the race
committee (signal) boat. This computer could also run a wifi hotspot for boats to connect,
but here are better options for the wifi. The RC program has a graphical interface (GUI).
BT refers to a boat. The program BT runs on a "computer on a chip" (e.g. Raspberry
Pi Zero W) which has LEDs for signalling sailors. It needs to be
configured to connect to the wifi hotspot and contact the RC. The only
interface used by the sailors is the LEDs. For lack of a better name, this
device is referred to as a gizmo. The gizmo has a hostname associated with
it, typically BT-# with "#" replaced by a number. When configured it also has
a boat identifier (sail number) associated with it.
On the gizmo the program CallOutRespond runs to communicate with Gcheckout and
make configuration changes for the BT program. This is a background process which
causes the LEDs to blink for acknowledgement and gizmo identification, but has
no other user interface.
BT, RC, Gcheckout and CallOutRespond programs need a path to the program lib:
export PYTHONPATH=/path/to/Vcourse/lib
These programs need to be started in a directory where their configuration files (more
below) are located. This typically is not the location of the executable program itself,
so the program directory needs to be on the PATH or the program needs to be referred to
with a full pathname. Since CallOutRespond may change BT's config files and restart it,
it is important that BT is found on the PATH of the process running CallOutRespond.
##################### Gcheckout User notes #########################
-The Gcheckout program is used to do the daily check out/in of gizmos. It cam be used
to assign a gizmo to a boat (sail numer), move boats between fleets, and remove boats.
It ...
-ADD MORE NOTES ABOUT TYPICAL Gcheckout STEPS.
-The Gcheckout program can be configured for different regattas by using a different
startup directory for each regatta. It looks for various configuration files (some json)
in the startup directory:
o A json file REGconfig with the IP address and port of the computer run the
Gcheckout program. The address for the Gcheckout computer should be the wifi
that gizmos can be reached on. (Most settings can be broadcast from the
subnet Gcheckout program to gizmos, but if the wrong subnet is indicated then
broadasts will not go to the gizmos.
o A directory FLEETS/ with a subdirectories for each fleet. These directories
should each have a file BoatList.txt as described for the RC program. These files
should be created using pre-registration information if that exists.
The Gcheckout program will modify the files if new boats are added,
sail numbers changed, or boats moved between fleets.
Gcheckout uses the same file structure as RC for FLEETS/*/BoatList.txt.
These files should be used by RC when Gcheckout is complete.
o The file unassignedGizmos.txt with one gizmo hostname per line. When no
gizmos are assigned this file will be identical to gizmoList.txt. Lines are
removed from it by the Gcheckout program when a new boat is registered,
and added if a boat is removed. In a batch setup of pre-registered boats
this file will need to be generated.
o FleetListRC.json for the list of fleet names with associated RC IP and port
information for each fleet. This is a different structure from the RC file
fleetList.txt, but it is important that the fleet names are the same in
both files. THIS JSON FILE CURRENTLY NEEDS TO BE MANUALLY CREATED.
o The file gizmoList.txt with one gizmo hostname per line. This file will not
change unless hardware gizmos are added or removed.
o The Gcheckout program will record check out/in information in a file
checkedOut.txt in each fleet directory. This is created and used
internally by the program.
-Configuration of gizmos is done with this utility, but much might typically be
done before the regatta begins using pre-registration information.
The Gcheckout program
o maintains a list of boats that have checked out/in their associated gizmo.
o maintains lists of boats registered in each fleet.
o configures gizmos with boat specific information ("FLEET" and "BT_ID" ).
o configures gizmos with RC information for the fleet("RC_PORT" and "RC_IP").
o configures gizmos with GPS hardware specific information for the gizmo.
###### Gcheckout program Errors ######
On start up:
... OSError: [Errno 99] Cannot assign requested address
probably means the REGconfig file indicates an address which is not correct, eg,
"REG_HOST": "192.168.43.xxx" instead of "10.42.0.xxx"
############################ RC User notes ############################
-RC will look for various configuration files (some json dict) in the RC
startup directory:
o FleetList.txt for the list of fleet names. (text, one fleet name per line)
o RCconfig for RC host IP address and port. The host IP address should be the
one available to BTa by wifi. RCconfig must match BTconfig for RC host IP
and port. Example:
{"RC_IP": "10.42.0.254", "RC_PORT": 9001}
o GPSconfig (optional) for GPS host and port . Example:
{"GPS_HOST": "127.0.0.1", "GPS_PORT": 2947}
If the GPS is not accessible then automatic GPS position of RC will not
be available.
o gpsList.txt (optional) with lines of 3-tuples for each GPS that might be
accessed on the network. "extra > other GPS" in the RC panel will then use
this list to try to obtain GPS positions over the network. The lines in the
file have lines with an arbitrary name, hostID, and port, separated by
spaces, for example
RC 127.0.0.1 2948
pin 10.42.0.250 2947
M1 10.42.0.251 2947
(gdps can be used to contact remote devices and serve them from a local
deamon. I have had better luck with that appoach. See gpsNotes.txt.)
If it does not already exist, a directory FLEETS/ will be created with
subdirectories for each fleet listed in FleetList.txt. These directories will be
checked for files:
o BoatList.txt a text file with one boat identifier per line (i.e. sail number).
Each boat identifier should be exactly as indicated in the BTconfig "BT_ID".
"Update Status" in the RC panel uses this list to indicate boats which have
not received course updates, so if the file does not exist then it will only be
possible to see what boats have received a zoneObj update (new course / change
of course) but it will be impossible to know which ones do not have the update.
o activeBTzoneObj.json with the zoneObj which was last active. This is primarily
for the case of recovery when the RC program is restarted for some reason.
(The BTs check against this to know if they need a new course.)
o active.raceParms with the last active race parameters (on the RC management
screen) for each fleet. These may not have been distributed and this is only
for convenience in the case the RC program is restarted for some reason.
The directory FLEETS/ also contains a subdirectory DISTRIBUTEDZONES/ with the historical
record of distributed zoneObj.json files.
-My USB GPS dongle seems to be relatively "plug and play" for getting
RC GPS. If there are problems, considerations are the same as for BT. See
gpsNotes.txt and OSsetup.txt for more details on that.
-See gpsNotes.txt regarding using GPS2Net on a phone to provide GPS for RC.
(The phone needs to have real GPS. I have only tested on Android.)
-If RC is mobile (not anchored) the "get RC GPS" button can be used and the
RC position copy and pasted. This could be useful, for example, to find the
actual start line center, rather than that calculated using assumed RC
position at the starboard end of the line.
-Fleet, description, and target start time are purely descriptive, but parts are used in saved files of distributed courses.
-The start line length, stadium width, , warning width, and center width must
all be specified.
-Other fields can all be specified, or some calculated on the basis of others
in one of three ways:
If start line center and mark 1 are specied then other fields can be
calculated by clicking "calc using start center & mark",
If RC and mark 1 are specied then other fields can be
calculated by clicking "calc using RC & mark",
If RC, axis, and course length are specied then other fields can be
calculated by clicking "calc using RC & axis",
-"distribute" distributes the fields as they appear, no additional calculation
of the displayed fields is done, so all calculations should be done before
clicking "distribute". Boats will be updated with the new course when they
contact the RC, and the update will be indicated by flashing red and
green lights. This can be used at the start of a race or for a course change.
A boat moving at 10 knots => 5.1 m/s. Reading gps about 8 times/s => almost a
meter between readings, more at higher speeds.
So, adjust border warning widths accordingly.
0.00001 degrees latitude is approximately a meter.
-ADD MORE NOTES ABOUT SETTING AND DISTRIBUTING THE RACE ZONE INFO.
############################ BT User notes ############################
For the sailor, the BT (boat gizmo) should be completely automated. Power-up
and it works. However, some configuration will be necessary before the sailor
gets the gizmo:
-The battery needs to be charged (every night).
-At the start of the regatta the /home/bt/BTconfig file needs adjustment to
o identify each boat
o the boat's fleet
o the RC host IP address and port
For example
{"RC_IP": "10.42.0.254", "RC_PORT": "9001", "FLEET": "fleet 1", "BT_ID": "boat1"}
where the boat identifier string "boat 1" could be replaced by a sail number and
"fleet 1" by a class name. The fleet string must correspond to the fleet name as
specified in the RC configuration file FleetList.txt. The boat identifier string
should be as specified in the RC configuration file BoatList.txt.
The RC IP address and port need to correspond to those set in RCconfig and the wifi.
-At the start of the regatta the BTconfig must be set to match RCconfig
for RC host IP and port.
-The gizmo configuration needs the proper wifi ssid and psk (password). This will
need to be fixed if the wifi details change.
See OSsetup.txt, Raspian.txt/Armbian.txt for details on building gizmos.
##################### CallOutRespond User notes #########################
-The CallOutRespond program reads and may re-write BT configuration files
so it needs to run in the same directory as BT. For its own configuration it
reads an address for the Gcheckout computer from the json file REGconfig,
similar to that used by the Gcheckout program. On the gizmos the address
can be reset by a broadcast from the Gcheckout program as long as it is
on the same subnet.