|
COMMENTS.
More specifically, the os_fstat(clock_fd) call at the beginning of the loop in square_raw, and likewise within CartFS Sensor class does an implicit wait, blocking the caller until the beginning of the next SyncFS cycle. This is accomplished by a modified version of the standard Linux fstat() file operation.
Within the while loop:
f1 = open("latlng.txt", "a"); f2 = open("serror.txt", "a");
... When I run this code in the simulator for one lap, I always get incomplete data in my log files, about 80 records (gps points) for one lap. However, when I just use print() function to standard output, the problem is gone, and I get around 370 records (gps points) per lap. So is this because of some real-time constrains inside that while loop? Is the file.write() function is too resource consuming?
try: while True: ...... f1.write(str(gps['lat']) + " " + str(gps['lon']) + "\n"); f2.write(heading_error + "\n");
COMMENTS.
I cannot be sure without additional experimentation, but the special file-I/O protocols in /tmp/cartfs may cause missed writes. In any case, creating data files in this area will result in dynamic memory allocation, which is highly undesirable.
f1 = open("/u/userid/square-log.txt", "a");
f1.write(clock['clock'] + " " + str(gps['lat']) + " " + str(gps['lon']) + " " + str(heading_error) + "\n");
You can re-direct this to a file, and use the Linux tail By the way, did you know that you can suppress the new-line by addint a comma at the end of the print-list? command to watch it. Or at the end of the run, copy-paste the term window into a file.
print clock['clock'], gps['lat'], gps['lon'], str(heading_error)