-
Notifications
You must be signed in to change notification settings - Fork 0
/
part2-general-instructions.txt
181 lines (141 loc) · 6.41 KB
/
part2-general-instructions.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
This refers to the latest client base release, Version 2 2017-02-19
When working on my solution I found two serious errors in the client.cpp:
1 - There was no check that the number of waypoints sent from the server
would not overflow the memory on the client. So the signature of the
srv_get_waypoints() function had to be changed to include a maximum
number of waypoints to be stored. Note that the waypoints need to be
stored so that they can be redrawn if necessary.
2 - The interrupt handling for the zoom functions was broken, and you
could put the arduino into an infinite broken zoom loop.
The above are now fixed.
I also found that debugging the client was a pain, since it could not
simultaneously talk to the server and send diagnostic messages. This
meant you have to fake the interaction over the serial monitor. So
I added a cs_message module that enables client-server interaction along
with tunneling of diagnostic messages from the client to be printed
by the server. There is a dummy server that illustrates how to use this
in the client_soln_part2_base/dummy_server directory. See dprintf below.
Also, there are sscanf and strtol functions in the Arduino libc that
you can call directly to process output from the server. Check out the
man page at:
http://www.nongnu.org/avr-libc/
http://www.nongnu.org/avr-libc/user-manual/index.html
sscanf:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html
strtol:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html
* Set up the SD card:
You need to have a regular file system on your SD card.
Your SD card already has a file system on it, and that is where you will
place the set of map tiles needed for the client.
Copy the contents of yeg-lcd.zip onto the card. There will be 6 files,
each representing map tiles at an increasing zoom level:
yeg-1.lcd
yeg-2.lcd
yeg-3.lcd
yeg-4.lcd
yeg-5.lcd
yeg-6.lcd
Total is about 700 MB of data.
Install the card in your display.
* Wire up the Arduino
Follow the wiring instructions in the circuit-wiring.txt file. With this
new code, you probably will be able to get away with not debouncing the
zoom buttons. But as good practice you should, especially if you are
getting multiple presses when you think you are only pressing once.
* Upload the initial client
Next upload the client_soln_part2_base code to the arduino. You should
be able to move around the map, and zoom in and out, without actually
communicating with the arduino.
* Test with the dummy server
There is a dummy_server directory. Inside is an example of a server that
communicates with your client and actually sends over waypoints. You can
use this to test your client.
The most important part of this dummy server is that it uses the
cs_message module which implements client-server communication with a
tunneled diagnostic channel. This lets your client send diagnostic
messages to the server for printing on stderr. It makes debugging your
client MUCH easier.
Attach your arduino and then start the server with:
python3 dummy_server.py -s /dev/ttyACM0
Or whatever port your arduino is connecyed to. You should see output
something like this, where the L lines are log messages from ther server,
and D lines are diagnostic messages from the client.
L |Opening serial port: /dev/tty.usbmodem1421|
L |Starting...\n|
D SD card ready.\n
D Max 100 waypoints\n
D Free mem:5018\n
D Zoom re-enabled\n
and then when you press the joystick button twice you should see
something like this:
D Button press @ lat 5350594 lon -11349984\n
D Start point lon -11349984 lat 5350594\n
D Button press @ lat 5350972 lon -11350551\n
D End point lon -11350551 lat 5350972\n
D Request for path\n
D Requesting lat 5350594 lon -11349984 to lat 5350972 lon -11350551\n
D Got path_len of 8\n
D Got path, length 8\n
D Fetching 8 way points, keeping at most 100\n
D Got 0 ||\n
D Got 1 ||\n
D Got 2 ||\n
D Got 3 ||\n
D Got 4 ||\n
D Got 5 ||\n
D Got 6 ||\n
D Got 7 ||\n
D Waypoints (lat, lon):\n
D 0: 0 0\n
D 1: 1 1\n
D 2: 2 2\n
D 3: 3 3\n
D 4: 4 4\n
D 5: 5 5\n
D 6: 6 6\n
D 7: 7 7\n
Which of course is quite bogus. But will become more realstic as you
impleent your client.
* Add the serial port and cs_message capability to your server
Now you are ready to implement the communication between the arduino
and the python server. Use the dummy_server.py as a guide. It
shows how to set up the serial port as well as how to use the cs_message
facility.
* Working on your client
Step 1 - get some communication working.
It's worth beginning by putting in some dummy code in the client that
just talks to the server, for example, put this at the end of your
setup() code just to force an interaction with the server.
For example, put this in setup to send a real request to your server
to see what it does when hit with 4 requests in a row:
delay(1000);
for (int16_t i=0; i < 4; i++) {
dprintf("Sending dummy request %d", i);
Serial.println("R 5365486 -11333915 5364728 -11335891");
}
delay(1000);
Note the use of dprintf(). It stands for diagnostic printf and works
exactly like the normal c library printf function, except that messages
are sent to the server over the diagnostic channel.
You can enable and disable dprintf by calling dprintf_control(). Since
dprintf statements consume memory, you can completely remove them by
#undef __DPRINTF_ENABLE
in dprintf.h
Step 2 - Next you should actually use the code in the client to obtain
the selected start and stop points and really send them to the server.
Step 3 - The you should make sure that you are processing the points
coming back from the server. Don't forget that you can send messages to
the lcd display.
Step 4 - Once that is working, you will finally have to implement the
path drawing of the route that the server returns to you.
Step 5 - Then you should deal with cases of protocol errors, by
resetting on invalid messages or timeouts.
Other comments:
REALLY IMPORTANT the order of locations in the server is (lat, lon),
while the order in the client is (lon, lat) (like an x-y coordinate
system(). Not taking this into account when talking between client and
server can make debugging interesting!
NOTE: there are sscanf and strtol functions in the Arduino libc that
you can call directly to process output from the server. See the note
at the top of this document.