Arduino or Raspberry Pi?

In 2016 I will be instructing some courses at the Kre8now Makerspace in Lexington, introducing people to the Arduino and Raspberry Pi microcontrollers. While I would certainly recommend taking both courses for the full picture, the reality is that you have a project in mind, and would like to decide whether to realize it with the Arduino, or with the Raspberry Pi. The problem is, how do you know which one to use without experience with both?

A lot of different online resources seem to have different measures to help you choose which one to use. Make Magazine, for example endeavors to number the amount of tasks for the project, and if

I personally think that a lot of the measures are bit far-fetched, so the natural thing to do is to add my own far-fetched measures of which board to use. And here's the first:

1) Consider your ports.

Now if you don't have much computer/AV know-how, that may have been a confusing bit of advice, but what I mean to is to carefully consider the inputs and outputs of each board-- they tell you a surprisingly amount about its capabilities and the simplicity in carrying out those capabilities. To make this more apparent, let's consider the ports on both devices:

Raspberry-Pi

• HDMI output
• direct 1/4 inch audio jack
• ~4 USB ports
• Camera port/display port
• Ethernet port
• micro-SD slot
• ~40 GPIO pins

Arduino

• ~10 digital I/O pins
• ~5 Analog input pins

Right now this may sound like a commercial for the Raspberry-Pi, but I assure you it's not!

Sure, the Raspberry Pi has more options, but that's because it's a full-fledged computing system and needs these services! The Raspberry pi runs a version of Linux which is very similar to any desktop/laptop version-- you can install the same programs and more from the same set of commands.

So why not just choose the Raspberry Pi for every project? Well, for applications that are primary electrical and autonomous (self-controlled) I'd choose the Arduino nearly every time, because it is far more idiot-proof when it comes to electricity, and far more flexible. Without going into too much detail, the Arduino is far more foolproof to higher voltages, whereas if you give the RPi anything beyond it's recommend 5v... expect your RPi project to be placed on hold.  Also, the Arduino very simply handles analog input/output, whereas you must "trick" the Raspberry-Pi into doing analog signals, by either simulating them or buying additional equipment. Even when working on Raspberry Pi I often "sketch out" my designs in the Arduino because it's so easy to work with!



My second and last comparison would be this:

2) Appliance vs. Computer System

When I say appliance, you probably have some clear pictures in your mind: A toaster, a refrigerator, and even smaller appliances like a blow dryer, a cat feeder,  or an alarm clock. Whereas with computing systems, more complicated systems should come to mind: video game consoles, robotic systems, and anything with the prefix "smart". From what I've already described you should be able to see more clearly why the two boards paint these distinctions. The Pi allows for easier networking, processing and display, whereas the Arduino is a simple wizard of electricity.

As a last measure of helping you decide, here's a pool of 5 projects each that best suit one board over the other, along with some helpful links!

Arduino:
Guitar Pedal, Small and simple autonomous robot, door-lock system, Plant waterer, motion alarm

Raspberry-Pi:
Media Center, Retro game emulator, Multi-core cluster, security camera,
internet radio

However, if you're dead-set on accomplishing a project with a board in mind, I encourage you to do so! There's truly only a few impossibilities that prevent you from crossing the streams, and often times doing so leads to new discoveries for you about your project and your board. Give it a try!

If you're interested in finding out more about Arduino and Raspberry-Pi projects, I recommend checking out instructables, and the two boards' subreddits. It also doesn't hurt to check out selections at shop sites to see what they offer. Adafruit in particular often has tutorials for both boards.

Electric Mortar Board featured on Adafruit's blog!

I'm happy to announce that the folks at Adafruit thought my mortar board was so cool, that they decided to share my recent video of the cap in action on their wearables blog. I'd like to thank them so much for their support and promotion. Here's the video that was featured in case you missed it:

Electric Mortar Board Update:

As promised, here are some more up close shots of the circuit. It performed well at graduation despite the battery concerns. Many thought it was the best graduation cap there, and netted me a few cat calls from Naomi Judd, as well as compliments from the President and Registrar. As promised I will make a fritzing diagram and some code for github.

Side view of circuit.

More vertical view of circuit.

(attempt at) other side of circuit.

A bigger picture of the circuit.

Here's how it looks from the front with the lights disabled.

A close look at the safety pin job that held it in place.

Lastly, a video of the programmed sequence.

Here is the cap in action when I walked.
Angelic.

Electric Mortar Board Finale!

So, after some initial ups and downs, I completed my full graduation outfit!
Here's a short video preview of the headwear:

What you see here is the full package: the mortar board modified with a LED sequence using Adafruit Neopixel and an Arduino Uno, a feathered tassel, aaand some sunglasses. While the last two are a bit more self-explanatory, let me explain how I made the cap possible-- I'll try to get some pictures of it tomorrow after the big rodeo... maybe even some of my college's footage, if I can find any.

While it's not exactly the best practices for a project like this I working under the pressure of only having a few hours in the lab, so I had to work quickly. The first and most important thing, which you may want to keep in mind with your own Neopixel adventures is the fact that the strand I got was actually wired in reverse. That is to say, the wires for input were actually on the output side. I read that this occasionally happens, but I thought I would mention it as it set me back for a while. Of course, you can always just read that one said says "digital in" or DI, and the other says "digital Out" or DO... 

Other than this, it should as (possibly) simple as wiring the digital in to a selected digital pin, the 5v to 5v and the ground to ground. Next comes the programming!

Working with neopixel is a great way to experience iteration in a very 'real' environment! I see this because of course your code will be driven make the lights change. Luckily, if you're working with the Adafruit modded Arduino 1.6 install, the Neopixel library will be right there to use, which, while it does not contain many useful example codes, has some great built in functions for making your own sequences, namely setPixelColor(), show(), and clear(). Using all three of these, along with the numberOfPixels() qualifier should be all you need to right successful iterating sequences! While I will make the ones I made available on github after graduation, I implore you to write your own functions, because, even if they go wrong, you might produce something awesome! For example, I accidentally fed in a uint16_t instead of a uint32_t for a color, and instead of white, it was this eery blue. If you do something too far fetched, the sequence just won't occur, so there's nothing to worry about! Start simple, and get more complex. Play around with delay speeds, the size of the pixels you work with and what colors you change them too, and you're guaranteed to have a great time! I look forward to applying neopixel to more things, like my instruments.

For powering the arduino, I got some 9v adapter wires and fed them into one of the dc adapters that goes into the arduino. I modified the circuit to include an on/off switch for when I don't feel like parading my funk. I've been told that 9vs are really efficient, but for the scope of this particular project it was beneficial in that it took up much less space, and complimented the parts I had on hand. I would have rather used my flora, but I didnt have any batteries to satisfy the pinout, so I ended up using just an Arduino Uno. Thankfully I don't think my audience will be too critical.

As I mentioned once I get some free time I'll upload my functions to github, as well as a fritzing diagram. Thanks for all your support! I look forward to graduating tomorrow.

Drone Following Project #14: Updated Arduino sketch

I'm feeling better, so I went ahead and fulfilled all of my improvements for modifying the Arduino sketch, along with some new features. Here's a quick overview of the new features:

• Two publishers (Uint8 for state, and Bool for new state)
• Consistent "/Lakitu/Device" name scheme
• 3 LEDs (blue, yellow, green)
• 4 states (Landing, DronePosition, Takeoff, Calibration)

The two publishers were already explained, but why did I add a whole new state? Well, again, I was thinking ahead at the steps that need to be taken when GPS is implemented. We've taken it for granted so far that the Drone is going to translate its position from the device, however, I failed to addressed how the Drone would receive its initial distance from where the device will be. There are a few sensing and distance ways to go about this, but I worry that many of them limit the set of scenarios greatly. I currently have it in mind that you will be able to press a button to generate a GPS location for the Drone that will change as the Drone moves. Whether this method is successful or not, I feel that it's good to secure a state where the user can can safely move around and find the initial distance from the drone without the danger of it moving.

Anyways, you can can see the changes made on Github. Enjoy!

Drone Following #10: Added ROS capabilities to sketch

Tonight I added ROS functionality to Arduino sketch. It's just a few lines of code, but they have great implications! The LED state machine is now a Publisher and sends its information via the serial port, so now anything connected to ROS on my laptop can read what state the device is in. Logically, the next step is to start working with the Drone. Here are some screenshots from it in action:

 

As you can see, rosserial got a little upset at my procedure... and I'm not sure why. All 3 states still work in action, but I get lots of mean text as opposed to the approval you get from other message types. A lot of threads seem to indicate this is due to the relative message size and buffer size for the particular board, but I seem to be well within the limits of my ATMEGA32 board. I'm investigating it currently, but as it works, I'll also be moving on to something a lot more exciting.

Drone Following #9: Soldering, State Machine, Github.

I've been quite productive since my finals (finally) ended.

First of all, my chips arrived! I was quite impressed with how small they were! The LSM9DS0 is about the length of half your thumb, and the level converter only a third of that. Not long after they arrived, I snuck out to the school's tech lab and soldered them together. It was nice to get back in the saddle and sit down with the ol' soldering iron. It feels like knitting, but with heat. My work isn't what it used to be, but I think it's enough to get the job done.

Next, I enjoyed my break exactly as envisioned. Tonight I spent the night doing some programming, the beginning of the drone following project. This consisted of creating an 3 state finite state machine. Right now it doesn't do much other than turn on LEDs in a sequential order and via the serial port tell you what state it's in.

But this is very important! After all, when I integrate this with the Drone controls, you don't want it ever going to the wrong state at the wrong time... This could mean taking off or landing at the wrong time. That being said, there was also some fool-proofing to be done-- for example, the Arduino reads super quick (sometimes), so you need to put a time delay in for the button press, or it may quickly transition between states. I handled this by having it hold for a second in a loop if the button is held. Right now all of the states are working as intended, so the next move will be ROS integration-- sending the state to ROS. From here, the Drone will read it, and respond accordingly. The states are as follows: Landing Mode, Takeoff Mode (indicated by a yellow LED) and Calibration Mode (indicated by a green LED). Calibration is where the Drone begins to follow movement.


Finally, I've made myself available on Github. It's been a while since I used it consistently, but I've realized that if I want to show people what I'm made of, I have to... show people what I'm made of. Therefore, I'll try to be consistent in uploading any code changes for your own viewing at my own github profile, Gariben. Here you can find the code for the state machine mentioned, as well as handy Fritzing diagrams and schematics. I'll usually include those in the blog, like so:

Currently, the code is housed under the "AirCat" repository. I didn't quite know what to name the project, since "Drone Following" will properly get me a pitchfork mob from an uneducated following, so I thought I'd just mimic the AirDog project that features the Drone remote, since the ideas are similar. Anyways, I hope to continue work on this project along with work to those I've dedicated myself too, so I'll try to keep everyone updated. Be sure to stay tuned to my Github for the latest-- it always comes at least a little before the blog.

Drone Following #8: LSM9DS0 chip and sensor research

So I was in a position where I could make a Youtube video about Physics for some extra credit, so I took the opportunity to do some research on LSM9DS0, and all of it's components. In the video you'll also found how these components physically work.

The chip actually arrived today, and I have to say, I'm surprised at how small it is! I probably should be, but I can't help but be excited that that much information comes from a board small than my thumb.

This is finals week, so I'm going to desperately try to hold back from toying around with it, but I do need to go ahead and solder it next weekend before the lab closes. Then I can spend my break getting my Drone off the ground, and using the IMU. If I get where I want to go, I might try asking for a GPS shield for my birthday in January... Unfortunately I also need a wifi shield to communicate with the computer or the drone. : (

Building Robots #2: The Turtle

I believe it makes sense that the first robot I try to develop is a turtle robot. Turtle robots are simple in nature, not to mention I have a lot of experience with factory made ones, such as the Pioneer 3-DX. I think parts wise it will be the most simple as well.

What I have in mind will basically a smaller version of the Pioneer, using smaller motors. I think all I would need in terms of locomotion would be two small DC motors, and then a caster wheel. I would like the bot to be roughly the size of like a waffle iron, with two tiers of circular plates. the first housing the microcontroller and a little breadboarding room for sensors and the like, and the top being like a plate with a lip for storing anything external, or placing anything on top of it. I would like the top layer to be screwed on or hinged, so that you can easily access the microcontroller. I know this design is bizarre, but this is only an idea. I'll try to gradually get this on paper as I go along.

Programming wise, I will try to first make it teleoperated, of course. I would like to gradually implement autonomous controls, but only once I have a better understand of what's going on. I'll be using ROS for this of this, and I would like to start by connecting to it with different controllers, and then create a unique message system for it, modeled after the pioneer. The teleoperation may require a wi-fi shield, unless I want to use a giant serial cord.

I think I would enjoy stress-testing the payload. One of my favorite features of the Pioneer 3DX was the fact it can carry up to 23kgs, but I always (secretly) wanted to test those limits in the upward direction. I think if I ever seriously develop a full-size turtle, I would like to make one of it's key points a massive payload. As I've said time and time again, I've always considered the Pioneer a roaming footstool, with the purpose of carrying other accessories. So I think that will be my focus for future designs.

Anyways, next time I'm at it, we'll talk about making a DC motor go both ways, and cutting down that circuit to be as efficient as possible, and containable.

Drone Following #5: Getting ROS onto the Arduino.

Sorry for no updates in a while. If you haven't heard, I founded a robotics club, and I have a Differential Equations exam this week.

However, in my electronics course, I had some success uploading ROS onto the Arduino, which is certainly a step forward. I expected it to be a lot more difficult than it actually was, but their were a few tricky elements. I find that the stage of just getting everything installed is FAR more frustrating than actually programming and compiling.

The most confusing thing, which I'll be sure to specify here, is that, in Ubuntu, the Arduino's 'libraries' and 'tools' directories are not in the sketchbook directory like every other OS I can think of. It is instead in

/usr/share/arduino

 so don't let that trip you up if you want to add anything to your IDE.

With that out of the way, it's time to set sail for rosserial. Here you'll find a great set of tutorials as well as a good video explanation of why you would want to use ROS on an Arduino project:

In short, it's one of those many "reinventing the wheel" moments that comes as part of being a programmer. Also, if ROS supports whatever else you're working with, just think of ROS as the dinner party both of these members will attend. Now, I have a means of making the Drone communicate with the Arduino, my "sensor stick".

After getting through the installation bores, you can check the first tutorial, a sample publisher. You should find that it's pretty easy. When you finish you should have a new topic, "chatter", that contains a "Hello World" message from the Arduino!

This may not be impressive in itself, but imagine if we modified this a little bit. Imagine a theoretical sensor running from the arduino and writing that data to ROS. You now have valuable, instant information at your fingertips. So now it's time to get the Drone talking and order a sensor. I'll make a separate post about that arduous process.

Drone Following #4: Possible Hardware, Possible Expansions

I seem to have a lot of ideas whenever I'm biking. Perhaps it's that it just puts me where I would be when the project finally comes together. That, and I really enjoy pretending I'm on a lightcycle.

I've been thinking about the device to use more and more. The device we choose will be important, because it needs to guide the drone. The drone will essentially have no native information about it's orientation, and we want to supply that from the human being via a device. I believe I've settled on using an Arduino for the time being. They happen to be something I have in abundance and I have an upcoming project for one in an electronics class.

However, an Arduino alone won't do it. I was thinking about what kind of shield would be most appropriate for the situation. I thought a little bit about maybe a GPS shield,  but for the time being I think that's a bit overkill. I was thinking actually of using a gyrometer shield. The idea of wearables excites me these day, so I was considering having the target wear the the arduino on his/her back, and having the drone figure its angle from the information on the Arduino. I was worried that this might be concern, with too many axes and too much sensitivity for extreme sports and the like; however, I saw that you can get a decent, low sensitivity two-axis gyroscope for a good price. This may be the key to acquiring information from the arduino. It may even need lowered sensitivity yet, but it only really needs to perceive the angle at which the person is facing. The extra axis can perhaps be used to better to connect the camera to the user.

The Math: So we have three basic factors we need to keep in mind here: distance from the user, and the angle the user is facing. Sounds like a job for Polar Coordinates! The reason I mention Polar Coordinates, is that as the user rotates, we want the drone to 1) change degrees to face camera at user, and 2) physically move behind the user in an arc. The change in degree is simple enough. If we imagine the gyroscope as facing the drone, then we the drone to maintain a -180 degree relationship to it. Perhaps before this adjustment is made, the drone can take this change in degree to calculate the arc to form, and then perform them simulatenously!

However, how to track movement has not yet been decided. It doesn't necessarily have to be true movement, in that it's constantly monitored and applied for us, but rather relative movement, similarly to how the gyrometer works: The Arduino just needs to know the amount of change, so it may be applied to the drone.

Possible Expansions: I should be getting this far ahead of myself, but when you're excited it's inevitable. It's what keeps projects interesting, and helps you seperate yourself from the rest of the pack. So, imagine this. Imagine if we applied all of the rules of the first arduino, to a second, head-mounted, arduino that affected the camera's movement: your eye in the sky. You're riding your bike, the drone is following. You tilt your head because you swear you spotted a wild sasquatch. The drone, maintaining it's following pace, tilts the camera to face the same direction, capturing 720p footage of the sasquatch and making you famous. I've got it all figured out. But really, this could be quite a useful feature! Additionally, if you were mathematical about the velocity, acceleration and time, you could have the camera only angle itself as the same theoretical time that you did, so almost like a transformation of you riding your bike, to a drone in the sky.


Understood limitations: It dawned on me right now that since this is ROS based I need to somehow have a laptop available during testing. I will be considering ways around this once I get to the point where everything is communicating properly (hint: it may involve a Raspberry Pi and a router).

Stay tuned for more updates!

------------------------------------------------------------------------------------------------------------