2
$\begingroup$

I've started tinkering with a Create 2, but I'm having issues reliably getting it to accept my commands. I can occasionally get it right, but sometimes, it just seems to ignore me. I'm guessing my cleanup code isn't getting the state fully reset or something. Is there a good pattern to follow for fail-safe initialization code?

Here's what I'm doing right now:

  1. Pulse BRC low for 1 second
  2. Wait 1 second
  3. Send 16x 0 bytes (to make sure if it's waiting for the rest of a command, this completes it - seemed to help a bit when I added this)
  4. Send 7 (reset)
  5. Wait 10 seconds
  6. Send 128 (start)
  7. Wait 2 seconds
  8. Send 149 35 (ask for the current OI state)
  9. Wait 1 second
  10. Send 131 (safe mode)

Sometimes I'm then able to issue 137 (drive) commands and have it work. Most times it doesn't. The times when it doesn't, I'm seeing a lot of data coming from the Create 2 that I'm not expecting, that looks something like this (hex bytes):

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f 2a ff 73 21 09 cc 0a 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f 2a ff 73 21 09 cc 0a

There's more, but my logging cut it off. I get the same pattern a couple of times, and it seems to be at least partially repeating. I thought maybe it's the 16 0-bytes I sent followed by 003f 2aff 7321 09cc 0a88, but I still don't know how to interpret that.

Sometimes it will make some noise for the reset command, but usually ignores the start/safe mode commands completely (I can tell because the green light stays on).

Improve this question
$\endgroup$
7
  • $\begingroup$ I should mention - communication is from a Particle Photon, a 3.3V device whose serial pins are 5V tolerant, and can handle the 115200 baud serial connection. RX/TX are direct-wired. $\endgroup$
    – Jonathan Rupp
    Commented Mar 10, 2016 at 7:40
  • $\begingroup$ You do not need to reset the robot every time as long as you properly exit the OI mode (173 if in passive mode, 173 173 if in the other modes). Also, does the pattern of data start after sending the drive command or before? $\endgroup$
    – Jonathan
    Commented Mar 11, 2016 at 14:53
  • $\begingroup$ I think the data was after the first drive command, but I'm not positive on that now that you mention it. I've been having crash-out issues from the microcontroller, so I'll try adding 173 173 to my startup sequence. Time for more experiments :) $\endgroup$
    – Jonathan Rupp
    Commented Mar 11, 2016 at 16:36
  • $\begingroup$ You should send the stop command after you are finished using the OI (say to let the robot charge or idle, etc.). If you do that, you should not need it at startup either. (173 is the stop command). What data bytes are you sending with the drive command? $\endgroup$
    – Jonathan
    Commented Mar 11, 2016 at 16:43
  • $\begingroup$ I was sending 137 1 0 0 0 (ie. about half-speed drive straight) for testing, but eventually was planning to drive it off of a gamepad input :) As for stop-when-done - completely get that. Like I said, my controller was crashing out sometimes, and I was looking for as "bullet-proof" of an initialization as I could that could deal with any state. Too bad I can't just pulse BRC in a certain pattern :( $\endgroup$
    – Jonathan Rupp
    Commented Mar 11, 2016 at 18:30

1 Answer 1

Reset to default
0
$\begingroup$

I figured out my problem - the '149 35' I was sending to ask for the current OI state (so I could confirm communication) was wrong. I should be sending '149 1 35'. From then on, it was all confused about what I was sending it, because it was expecting 35 sensor-id bytes.

Short version: make sure you follow the protocol right :(

Improve this answer
$\endgroup$
1
  • $\begingroup$ I should also mention - I was using this with a Particle Photon (a 3.3v device), and had a lot of issues initially with reliable communication, especially after working with it for 20 minutes or so. After adding a level-shifter to bring the 3.3V TX up to 5V, the reliability went up a ton. $\endgroup$
    – Jonathan Rupp
    Commented Apr 8, 2016 at 4:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.