Raspberry Pi + 2x Arduino Nano V3.0
Filed under: Development, General, Hardware, Linux, Robots
Quick update, during my evenings I’ve been working with one of the Raspberry Pi’s I won on a local contest a few months ago, and it’s generally derailed into some kind of “let’s put as much stuff on it as possible”, meaning that I currently got my Raspberry Pi hooked up with:
- Slice of Pi
- Adafruit PWM driver
- Raspicam on a simple pitch/yaw servo gimbal that me and my 1,5 year old put together in 10 minutes. Controlled via PWM.
- MPU9150 sparkfun breakout board
- 2 Arduino Nano V3.0
The two Arduino Nanos have split functionality, where one will provide me with data that needs to be gathered frequently, and the other is used for slow processes such as reading out 1-wire temp sensors etc.
The first nano will have the following functions hooked up to it:
- 3x HC-SR04 ultrasound distance sensors
- Voltage measurement 0-20V circuit
- Control of 2 relays
- 3x line tracking sensors
- Reed switch
- 2x motor controls via L298P chip
The second nano has the following hooked up to it:
- MPX2200GP pressure sensor (will use something else soon’ish)
- 2x 1-wire DS18B20 temperature sensors.
- Others?
The general idea was to move timing critical stuff off the raspberry to the Nano and let the first one deal with quick sensor readouts, while the second Nano is dropped off with relatively slow sensors (DS18B20 takes very long time to read out for example). The two nanos will talk to the Raspberry via SPI I think, or possibly serial ports, but this is less likely as it would either require me to use one USB serial driver and the raspberry UART or get a 2 port USB hub of some kind and talk via USB UART’s.
I’ve meanwhile also played around with Eagle CAD for the first time in my life, making some electrical drawings of the hookups. I’m considering making a PCB layout of everything when I get there, not sure if there is any interest in this out there except for “the lols”. The image is still very raw and missing a lot of stuff that I know needs to be added at some point.
During christmas I spent some time making opencv haar cascade training on clementine detection and generally fooling around with it. I think I’m leaning towards making a robot (chassi on the way) which will travel around in the room looking for objects… I guess some of the sensors are a little overboard for this, but it’s all fun and games while it’s not work… 😉
Final thoughts on the embedded Linux seminar
The embedded Linux seminar was held last week, and in general I feel that it went pretty well in line with my expectations. It’s been a long time since I held any real presentations, so the first two presentations in Gothenburg I was very much nervous and lost myself a few times along the line. The two presentations in Stockholm and Oslo went surprisingly well however, and I don’t think I made any huge errors from a pure presentation point of view.
Licensing
Now, that said, we did run into a few snags and after pondering what we can learn from the whole presentation/seminar — and there are a few points I’d like to raise both for the attendees and anyone else who might be interested. Being an “engineer”, I like to consider what went wrong, etc. Most points are of minor interest, but one of the absolute major points that we really didn’t get across properly, licensing issues with open source, or rather, licensing issues are manageable, however this was not the main area that we (or at least me) where there to talk about. Our main error was simply that we forgot communicating properly with each other, and correlate what we where saying. Also, this seminar wasn’t really about licensing issues, Nohau has an entire seminar/course on that topic alone, and you could easily fill out an entire university course on open source licensing.
The main point I tried to get across was that, yes, you need to be wary about licenses and you need to look at what is required of you, but that’s nothing different from any closed source licenses either, and you should be putting policies as well as processes in place to handle it, and push knowledge on how to handle licenses must be disseminated throughout the project.
So, to address some of the main licensing questions we received:
- No you will not have to give away your code if you link the code properly.
- You will have to set up proper procedures to handle any third party sources.
- You will have to create processes for everyone to follow to get any third party sources “accepted”.
- You will have to adhere to third party licenses, if you don’t, be prepared to be forced to and receive some bad publicity for it. (A lot of companies/people do get away with it, but is it worth risking it?)
Reliability
The second large question we got was, when would you use Linux, and when wouldn’t you use it, in a life or death situation? Simply put, I wouldn’t put it in a system where a person or persons would die if the process/hardware/appliance crashes, but that’s me. I would generally speaking make the life supporting/critical system run on a separate hardware, and then make all the critical stuff run in that context/hardware, and then a second piece which communicates with the critical hardware and do the higher end “stuff” that might be interesting (communicate to centrals, user interfaces, settings, etc). This way, the critical stuff can be kept simplistic and reliable (in my experience, reliability is a function of complexity, the more complex, the higher the failure rate).
In most projects, this has to be decided on a case by case basis, and due diligence must most of the time be taken with the laws and standards of each area. What is possible and advisable to do in house and home automation is not the same as in airplanes or medical systems for pretty obvious reasons.
Presentation depth/breadth/focus
Finally, a minor point, I got some criticism for being too shallow, not going enough in depth. Well, I could have stayed on discussing tool-chains and how to make one for hours, or I could have talked entirely about Linux internal boot order and why it works the way it does, but that wasn’t the goal of the entire seminar. That stuff could be studied to death, in the end your better off “getting” the top-down structure of an embedded Linux project and then just experiment on your own rather than get everything served in forum that can not make justice to everyones requirements. Next time however, I will try to maintain a deeper focus on a bit fewer topics, or get more time to speak in.
Anyways, I think it was fun and a huge experience. I hope most people visiting found the seminar interesting and had something out of it.
embedded Linux seminar 25-27/11 2009
On the 25-27 of november I will be on tour with nohau.se and hold a embedded linux seminar. The entrance is free, but requires a registration, see the embedded linux seminar webpage. according to the following schedule:
- Göteborg 25/11, em 13-16. Plats: Centralhuset Konferens, lokal Orientkusten
- Stockholm 26/11, em 13-16. Plats: Kista Konferens, lokal Alfa
- Oslo 27/11, fm 8-12. Plats: Thon Hotel Vika Atrium, Munkedamsveien 45, Oslo
I will specifically do the Development using Embedded Linux track, which will be 50 minutes long. The presentation is still fairly crude and rough around the edges, but some of the bulletpoints I’m going to talk about is:
- When to use Linux/ When NOT to use Linux
- Pitfalls of open source vs closed source and vice versa
- Hardware vs Development time cost decisions
- Choosing the right hardware
- Choosing the right software
- Security.
I hope to see some of you at the seminars!