As my previous posts may suggest, I've been a long-time fan of the Arduino platform. Among other things I use it as the basis of a demonstration to showcase a variety of MathWorks' tools that includes driving a motor to rotate a camera to track an object. The Arduino works great for doing closed-loop position control of the camera, but falls short when it comes to actually processing the camera video to detect the object. So currently the video processing is relegated to my laptop which prevents me from creating a completely embedded solution.
Enter R2013a which introduced support for a number of new target platforms which Jiro pointed out earlier this year. I was drawn to Raspberry Pi in particular because it is a similar price and form factor to the Arduino, but has built-in support for USB webcams:
Looking at the blocks that are included with the target, however, you'll notice that there is nothing included for sending voltages to a DC Motor like you can do with the Arduino PWM Output blocks. Because of that I had initially planned to use both the Raspberry Pi and Arduino for my demo until I ran across Joshua's submission the other day. His model uses S-Function Builder blocks to take advantage of the new WiringPi support in the Raspberry Pi image that is used in the support package. Here's the top-level of Joshua's model:
After some breadboard work, I built and downloaded the model and I was controlling my motor in minutes by simply changing the Input Volts value in External Mode. Now I just need to decide on the best way to read the motor's potentiometer then the whole system can run on the Pi. Or perhaps I should bite the bullet and switch to an encoder. If anyone has any suggestions, leave a comment!
I was happy to see that Joshua was inspired by Giampiero's Device Driver guide that explains how to create custom drivers for the hardware support packages. Joshua has also recently uploaded several other related submissions. I'm looking forward to seeing what Joshua and others come up with in the future to increase the I/O options for the different hardware platforms.
One minor suggestion I would have for Joshua is to include the pin numbers that correspond to the PWM outputs for this model. I had to do a bit of hunting to track that down (it's 7 and 11 on the P1 header for those that are interested). But other than that, this submission has been a big help, thanks Joshua!
Let us know what you think here or leave a comment for Joshua.