# Is there a way to disconnect and reconnect from a Create 2 that was streaming sensor readings without having to unplug/replug my USB-serial cable?

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.

## 1 Answer

I usually do this to disconnect and I've had no issues with it to date:

128 // To put in passive mode
173 // To stop OI


If you only do 128 or 173 on their own, I could see it potentially having issues since it may not exit OI depending on what mode you were in.

I do not request the stream to be paused, though I can't imagine that hurting.

• I attempted this solution, and I saw similar results (I still have to unplug/replug) except that the robot now beeps when receiving mode commands (high pitched for the 'safe' command, low pitched for the 'stop' command) with each attempted run of the program described in my question. I will continue to try and see if I can find anything out and report back. – Eric Nov 18 '15 at 22:05
• You could also go to the extreme and request the robot to reset (opcode 7) after doing the 128. I don't think that will help at all, but if it still doesn't work when you reset, I would guess that there is a bug somewhere in the serial drivers you are using or your code. – Jonathan Nov 19 '15 at 15:17
• I did not have to go to the extreme of resetting the robot, fortunately, see the edits in my question for an outline of may experience. I did incorporate your suggestion into my final solution. – Eric Nov 19 '15 at 19:36