Let's Make Robots!

Response time slow on Python pySerial, RPi, and Arduino orchestration

I'm working on learning Python and orchestrating my Raspberry Pi to be my bot's brain.  Currently, my plan is to develop an orchestration code between the RPi and Arduino+Motor Shield using good old UART and pySerial.  Right now, I've written rough code to cause the RPi to act as a fancy wireless shield.  It is suppose to capture key strokes and send them to the Ardy.  The trouble I'm having at this stage is with key presses not getting delivered to the Arduino quick enough.  Also, if the key is held down, the key is not repeated like hoped.  Note, I'm using pyGame, since I've already wrote this code once in Tkinter and tried porting to the RPi from a Linux laptop and got infinite errors.  Nevertheless, any input or downright mocking would be appreciated.

Code to go with this bot:


Fresh_1.5.py_.txt2.07 KB
FIXED_Fresh_1.8.py_.txt1.83 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Fixed it.

It seems the threading was causing the script to delay in sending keystrokes.  I fixed it by adding pygame.key.set_repeat.  I had a little more trouble figuring out that this function basically counts how many times the key was pressed, at the time interval you set, then bursts upon the KEYUP event.  Regardless, it works like I hoped. Allowing me to control my Arduino from my desktop, via RPi and dongle.  Now all I need, is my optoisolator chip and I'm in business.  (Hey, I'm not waiting another nth months for another RPi).


I think the RasPi speaks i2c fluently. Arduinos do as well --as both slave and master (caller or responder). I dunno man, it sounds like basically a main brain and a bunch of helpers. Sounds like i2c to me.

But you're right, I've been so focused on what I'm doing I forget there might be a better way to get to the goal.  I'll explore I2C.

I don't want the RPi to be the heart of the bot.  I want it to be the head.  There are many reasons for this:

  1. The Pi is freed to run other more complicated processes rather than actuators and gathering sensor data.
  2. In my opinion, the Pi is not reliable for time critical tasks.  And as I understand it, this is the primary separation between microcontrollers and processors.
  3. It seems to me, the more complicated the software, the more likely the Pi is to crash.  In the instance of Pi-Ardy cooperation, I can always place minimal autonomous code on the Ardy to take over if the Pi crashes.  
  4. Pi to Ard cooperation seems like it should be no more complicated than any other UART orchestration. Though, I feel many people shy away it due to the many moving parts.  And as I stated before, I'm challenging my mind: The uncofirmed lex parsimoniae is not above me--but efficiency is not the goal.
  5. I don't think I'm the only one with this perspective, I noticed few have faith in pcDuino type board's ability to handle GPIO, even sporting the Cortex-A8.
  6. And though I read your article, Mr. Maxhirez, I can't say I completely agree with your conclusions.  For instance, "Think about it-you need to be tethered to a monitor, or to put a small enough monitor on the bot that you can't read command lines and oh yeah, you'd have to follow it around with a keyboard and so on and so on."  This is actually one of the neat things I like about hooking up my RPi to the Arduino.  With my WiFi dongle I'm able to use SSH to control the bot directly from my desktop.  Makes me happy.

But, I should say, I just figured out yesterday how to work the amp setting on my multimeter.  So, what do I know? :)

Links regarding Ardy and RPi:

  1. http://www.quora.com/Arduino/What-are-the-differences-between-Arduino-and-Raspberry-pi
  2. https://www.sparkfun.com/products/11712 (Comments section)
  3. http://www.designspark.com/blog/arduino-or-raspberry-pi (The conclusion here is what got me.  Toolbox approach).
The RPi makes a great robot brain, but for the metaphor to hold, consider that you die when your brain doesn't control your heart, lungs, etc. Point by point though,

1. To be the "brain" your RPi still has to deal with in and output somehow, whether commanding an Arduino or something over i2c, UART or directly from its GPIO. Either way is going to take about the same number of cycles up, so all you're gaining with the Arduino is a red entry in the BOM balance sheet.

2. The Pi has a 700 MHz processor overclockable to 1Ghz without too much trouble. The Arduino is nailed down at 16Mhz. While that's not a perfect comparison (there is some threading in the Pi, not in the Arduino) the Pi definitely has the better reliability for time critical tasks. There is some confusion sometimes in the fact that it doesn't have a real-time clock, but that's not the same thing as having unreliable timing. The Pi can easily "bit bang" multiple PWM signals without sacrificing the ability to process high level software like openCV.

3. This is a good point, but I have yet to have my Pi crash. That means of course that it will happen the next time I fire it up...

4. The reason most people want to use the Pi through the Arduino is that you can put the Arduino IDE on the Pi and control it through the USB port as they've become accustomed to doing with their desktop/laptop machines. You can also use the GPIO UART access or as CtC points out, work with i2c pretty easily too (there are some setup dance steps if I recall, but once I had it running I kind of left off the links that guided me.)

5. The Pi GPIO is solid. I don't know where that doubt comes from, unless it's the fact that Arduino's is so dependable that nothing could seem to approach it.

6. I was writing with the assumption that the reader would want the Pi physically on the bot, as there seems to be a common unspoken prejudice that unless that criteria is met, what you really have is a remote controlled car with your computer acting as an expensive transmitter. I personally don't think a robot has to be completely autonomous by definition, but I often write on LMR with the stricter definition in mind just to avoid conflict. The Pi's small size and low power consumption make it platform mountable for most chassis kits, so it suggests itself as an obvious mode for many makers. (Indeed, one of the reasons I bought one was to put openCV on a small self-contained autonomous mobile platform.) If you want the RPi on your desktop and the physical apparatus separate then of course there's no need for an on board monitor or tether. If the RPi is your main computer that's sensible, but for many users it represents an ancillary device to their main workstation or laptop. I have ssh as an option for controlling Yubin Kun with my iPad as what they used to call a "teaching pendant" but I could hardly consider him autonomous in that mode. He was essentially one of those Pakbots they use for bomb disposal or nuclear disaster clean up-a mobile remote controlled camera with an arm when operated that way.

In any case, don't let me tell you what to do or how to do it. I was just pointing out that you may not need to allocate as many expensive resources to a project as it wcontrol the Arduino with the Raspberry Pi would seem at first. If you want to control the Arduino with the Raspberry Pi for the sake of controlling the Arduino with the Raspberry Pi then by all means go for it. Also, share what you come up with and learn. I've kind of lost site of where I was going with my Pi, so if I can learn from your experience I might find my path again.

I appreciate your time.  (And thank you for often making late night reading more pleasant with the encouraging gifs in the shoutbox.  That's you, right? :)

I'm also very glad to meet another using cost-benefit analysis when building.  

I wanted to add wifi to my bot since the beginning; after digging through many sources I noticed it was around the same price to equip a RPi with WiFi and add it to the Ardy.  As I posted under my bot build

"But, that wasn't good enough for me.  I had bought a Raspberry Pi that I desperately wanted to add on to the bot.  I had done the math.  I figured that it was almost as much to setup a RPi with a WiFi dongle as it was to buy a WiFly.

WiFly setup:

  • WiFly Xbee from SparkFun: $42.95
  • Arduino WiFi Shield: $6.98
  • Total for WiFly: $49.93

Basic Raspberry Pi and WiFi Dongle

  • WiFi Dongle: $6.17
  • Raspberry Pi: $35.00
  • SD Card (4g): $2.50
  • Total for Basic RPi: $43.67"

Of course, it was largely because I couldn't find a cheap and easy supplier of WiFi gear for the Arduino.  Even looked into making one by etching the board--yah, those blinkin integrated chips are pricey.

Regarding the plug-n-play nature of Pi and Ardy through USB.  I'll admit, that is how I have it now, since it is easy for prototyping.  But I'm concurrently designing a optoisolator board to go between.  So, in the end, it will be GPIO to TX/RX.  And you may say opto is overkill, but my wife told me I had to start galvanically isolating my boards.  I think her exact words were, "If you're so smart, why do you break so many of those things?"  Damn good question.

And I apologize for misunderstanding about the placement of the Pi.  That makes more sense :)  And I especially like your views on robotics; saying autonomous robot would be like saying autonomous human.  It sounds right in words, but in practice, it simply is improbable.

Thank you again, Mr. Maxhirez.

No worries about the misunderstandings here. And you are probably wise to isolate your boards (I am just learning how to isolate myself from the criticisms one faces-or more likely imagines he will face-when married!).

In any case, your enthusiasm for the project is refreshing and likely to bear fruit (sorry-I've gone about a year without making a Raspberry pun. It had to come out sometime.) Please stay active with LMR and share anything you make here. Our Pi offerings are thin, but I do think that this SBC is promising and could advance consumer robotics beyond amusement to the level of usefulness. Whatever you learn, teach us!

You don't need the Arduino in there.  It's a wasted Arduino. You're making things way too complicated.