I am working with a Create 2 and I am executing a simple sequence like (in pseudocode):
create serial connection from Macbook to Create start the OI with by sending the 128 code send a pause-stream command (just to be safe) initiate the data streaming with ids: [29, 13] every 0.5 seconds for 15 seconds: poll the streamed sensor data and print it send a pause-stream command before shutdown send a 128 to put the robot in "passive mode" (I have also tried 173) close the serial connection
The outcome when I run the above program repeatedly is that it works the first time, I see sensor data (that seems to not change or be reactive) printing to the screen, but on future runs no serial can be read and the program crashes (because I am throwing an exception because I want to get this problem ironed out before getting to far along with other things). If I unplug and replug my USB cable from my Macbook, then the program will work for another run, and then fall back into the faulty behavior.
I do not experience this issue with other things like driving the robot, I am able to run programs of similar simplicity repeatedly. If I mix driving and sensor streaming, the driving works from program run to program run, but the data streaming crashes the program on the subsequent runs.
I have noticed that if I want to query a single sensor, I need to pause the stream to get the query response to come through on the serial port, and then resume it. That is why I am so inclined to pause/restart the stream.
Am I doing something wrong, like pausing the stream too often? Are there other things I need to take care of when starting/stopping the stream? Any help would be appreciated!
EDIT: I should note that I am using Python and pyserial. I should also note, for future readers, that the iRobot pushes its streamed data to the laptop every 15ms where it sits in a buffer, and the data sits there until a call to serial.read() or to serial.flushInput(). This is why it seemed that my sensor values weren't updating when I read/polled every half second, because I was reading old values while the current ones were still buried at the back of the buffer. I worked around this issue by flushing the buffer and reading the next data to come in.
EDIT 2: Sometimes the above workaround fails, so if I detect the failure, I pause the stream, re-initialize the stream, and read the fresh data coming in. This seems to work pretty well. It also seems to have solved the issue that I originally asked the question about. I still don't know exactly why it works, so I will still accept @Jonathan 's answer since I think it is good practice and has not introduced new issues, but has at least added the benefit of the robot letting me know that it has started/exited by sounding tones.