29GBP / 34EUR / 43USD embedded linux, 320Mhz, wifi-N
GPIO LED pins?
by gclaudiu
Tue Dec 27, 2011 2:17 am
Merry Christmas to all!
Just wanted to share on my experience with this board: I did play a bit with the board and using the stock firmware (got it this month) can go to 20 fps @ 640x480 using Logitech 210 webcam and removing the "-y" with CPU bellow 50% (using "-y" CPU will go very high even at 320x240).
Also, did you guys considered using one of the 3 GPIO LED for RESET? I mean, if you want to use this as a solution for live firmware update for an arduino board, can install "ser2net" (which works pretty well on OpenWRT), use one GPIO LED as DTR (RESET) and another one to enable the serial link once the system is up and running...
Anyway, is a lovely board, wish was just a little bit smaller and there were some GPIO pins available.
Happy holidays!
Just wanted to share on my experience with this board: I did play a bit with the board and using the stock firmware (got it this month) can go to 20 fps @ 640x480 using Logitech 210 webcam and removing the "-y" with CPU bellow 50% (using "-y" CPU will go very high even at 320x240).
- Code: Select all
mjpg_streamer -i "input_uvc.so -d /dev/video0 --resolution 640x480 --fps 20" -o "output_http.so -w /webcam_www/"
Also, did you guys considered using one of the 3 GPIO LED for RESET? I mean, if you want to use this as a solution for live firmware update for an arduino board, can install "ser2net" (which works pretty well on OpenWRT), use one GPIO LED as DTR (RESET) and another one to enable the serial link once the system is up and running...
Anyway, is a lovely board, wish was just a little bit smaller and there were some GPIO pins available.
Happy holidays!
by l3v3rz
Sat Jun 23, 2012 11:44 am
Thought I'd give an update on progress.
With help from robosavvy I have the board communicating with the Robobuilder RBC unit - sat inside their 3D printed custom back. I have mjpg_streamer running with a Microsoft webcam attached (pictured is a different cam I managed to fry first ) I also have my own Basic (http://code.google.com/p/robobuilderlib/wiki/Omnima) compiled and running controlling the robot. All works fine. I also have a couple of example programs that control the robot head running in basic using a helper app that converts the jpeg file into a list of numbers for easy importing to basic.
Here's a picture of robobuilder with head, camera. The omnima card sits in the modfied RBC on the back - you can see the USB socket. Will sort some video soon.
With help from robosavvy I have the board communicating with the Robobuilder RBC unit - sat inside their 3D printed custom back. I have mjpg_streamer running with a Microsoft webcam attached (pictured is a different cam I managed to fry first ) I also have my own Basic (http://code.google.com/p/robobuilderlib/wiki/Omnima) compiled and running controlling the robot. All works fine. I also have a couple of example programs that control the robot head running in basic using a helper app that converts the jpeg file into a list of numbers for easy importing to basic.
Here's a picture of robobuilder with head, camera. The omnima card sits in the modfied RBC on the back - you can see the USB socket. Will sort some video soon.
Last edited by l3v3rz on Wed Aug 15, 2012 4:24 pm, edited 1 time in total.
by PaulL
Sun Jun 24, 2012 4:09 am
Hi Limor, Just noticed this post via another...
I could not agree more, and not just in the context of robotics, but in many embedded versus PC scenarios. There is a fact that few seem to want to acknowledge: the PC as a platform is ubiquitous, and as such, is in itself a standardized hardware platform, one that can be applied to embedded applications.
Embedded processors (PIC, Atmel, etc) support a world of per-application software development. Using a PC in what once was an embedded application changes things: software is suddenly capable of being repurposed, enhanced, and expanded much more easily. Compatibility and communications with other systems improves dramatically. Access to useful things like databases becomes trivial, higher level programming languages result in greater levels of productivity.
If you build custom hardware such as proprietary embedded controllers, you'll fight tooth and nail to stake your claim as time marches on, but if you're a software developer (and hardware doesn't do squat without software), you'll find a much more powerful and compatible world in a PC-based controller.
YUP! Definitely agree. As much horsepower (CPU speed, instructions per clock cycle, ram, etc) as I can pack on my bot's back, the better!
Absolutely agree. It's nice to have a base to start with, but at some point, controllers had to do more than just move servos. An oversimplification, but point being that the trend was fairly obvious: start with an embedded controller (MRC-3024 or whatever), and eventually bluetooth it to a PC, and then finally realize one can slap a PC on the bot instead. 
Yes, embedded controllers DO have a place, but it is a small place that consists of otherwise CPU-hungry tasks (the "in hardware" versus "in software" problem). IMHO, high level control software doesn't belong in an embedded processor. It can be (and has been) done to some extent, but there's a better way.
There is a world that parallels hobby robotics more than anyone might realize: industrial automation. There are a number of big players in this billion dollar industry, some of which have been doing what they do (ex: embedded controllers running "ladder logic") for some time now. A bot with over a dozen servos walking around and looking at things with vision processing code (and many other types of sensors) is representative of industrial systems that cost MANY times more than such bots do. Software-wise, what we're doing is functionally no different than what big companies like Omron, Allen Bradley, Siemens, and Cognex have been doing. Clearly, there are differences in the hardware itself, but the functional aspects of software are the same, ex: move this to there, check some sensor, do something else, continue, etc.
There is a reason as to why what we want from our bots is often not easy to come by: many engineers have been developing control systems for decades, and they STILL haven't developed a standardized approach to control system software, or even hardware for that matter. Some claim standardization on one aspect or another, but step out onto any production floor and you'll see a number of "standards" in action - a potpouri of hardware and software brutally hammered into something that serves a singular purpose (production), usually at great cost, particularly when the word "integration" (read, connecting two incompatible systems) is used in the design meetings.
My point is, if someone designs a control system flexible enough to easily run any bot hardware configuration with n desired features, that person will surely shake up more than just the bot world. And, I have a sneaking suspicion that the way to do that is with PC-based controller hardware.
Take Care,
Paul
limor wrote:This is the only way forward for many reasons
I could not agree more, and not just in the context of robotics, but in many embedded versus PC scenarios. There is a fact that few seem to want to acknowledge: the PC as a platform is ubiquitous, and as such, is in itself a standardized hardware platform, one that can be applied to embedded applications.
Embedded processors (PIC, Atmel, etc) support a world of per-application software development. Using a PC in what once was an embedded application changes things: software is suddenly capable of being repurposed, enhanced, and expanded much more easily. Compatibility and communications with other systems improves dramatically. Access to useful things like databases becomes trivial, higher level programming languages result in greater levels of productivity.
If you build custom hardware such as proprietary embedded controllers, you'll fight tooth and nail to stake your claim as time marches on, but if you're a software developer (and hardware doesn't do squat without software), you'll find a much more powerful and compatible world in a PC-based controller.
- The fun in this hobby is about innovation and cutting edge technology.
YUP! Definitely agree. As much horsepower (CPU speed, instructions per clock cycle, ram, etc) as I can pack on my bot's back, the better!
- PIC and Atmega have had their run as robot brains.
Absolutely agree. It's nice to have a base to start with, but at some point, controllers had to do more than just move servos.
An oversimplification, but point being that the trend was fairly obvious: start with an embedded controller (MRC-3024 or whatever), and eventually bluetooth it to a PC, and then finally realize one can slap a PC on the bot instead. They are great at doing real-time stuff and digesting loads of sensor input but if you take the DARwIn software framework as a glimpse of where the future is heading, then the small microprocessors have a minor role in that future. DARwIn runs on linux with 10x the megaherz of an atmega.
Yes, embedded controllers DO have a place, but it is a small place that consists of otherwise CPU-hungry tasks (the "in hardware" versus "in software" problem). IMHO, high level control software doesn't belong in an embedded processor. It can be (and has been) done to some extent, but there's a better way.
There is a world that parallels hobby robotics more than anyone might realize: industrial automation. There are a number of big players in this billion dollar industry, some of which have been doing what they do (ex: embedded controllers running "ladder logic") for some time now. A bot with over a dozen servos walking around and looking at things with vision processing code (and many other types of sensors) is representative of industrial systems that cost MANY times more than such bots do. Software-wise, what we're doing is functionally no different than what big companies like Omron, Allen Bradley, Siemens, and Cognex have been doing. Clearly, there are differences in the hardware itself, but the functional aspects of software are the same, ex: move this to there, check some sensor, do something else, continue, etc.
There is a reason as to why what we want from our bots is often not easy to come by: many engineers have been developing control systems for decades, and they STILL haven't developed a standardized approach to control system software, or even hardware for that matter. Some claim standardization on one aspect or another, but step out onto any production floor and you'll see a number of "standards" in action - a potpouri of hardware and software brutally hammered into something that serves a singular purpose (production), usually at great cost, particularly when the word "integration" (read, connecting two incompatible systems) is used in the design meetings.
My point is, if someone designs a control system flexible enough to easily run any bot hardware configuration with n desired features, that person will surely shake up more than just the bot world.
And, I have a sneaking suspicion that the way to do that is with PC-based controller hardware.
Take Care,
Paul
by limor
Sun Jun 24, 2012 9:55 pm
btw: If you haven't yet played with it, the ROS.org system is not bad as a framework for robot control.
the ROS framework provides a clean way of viewing a complex robot system as individual services. each node in a ROS system provides services and sends messages. This may be seem like an overkill for a simple robot such as RoboBuilder but if you add embedded linux and camera then using ROS allows behavior creation to be a piece of cake. (see intro to ROS)
the ROS framework provides a clean way of viewing a complex robot system as individual services. each node in a ROS system provides services and sends messages. This may be seem like an overkill for a simple robot such as RoboBuilder but if you add embedded linux and camera then using ROS allows behavior creation to be a piece of cake. (see intro to ROS)
