29GBP / 34EUR / 43USD embedded linux, 320Mhz, wifi-N

Custom built or hacked Electronic boards and sensors
19 postsPage 2 of 21, 2
19 postsPage 2 of 21, 2

GPIO LED pins?

Post by gclaudiu » Tue Dec 27, 2011 2:17 am

Post 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).

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!
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).

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!
gclaudiu offline
Newbie
Newbie
Posts: 2
Joined: Mon Nov 22, 2010 6:26 am

Post by l3v3rz » Sat Jun 23, 2012 11:44 am

Post 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.

Image Image
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.

Image Image
Last edited by l3v3rz on Wed Aug 15, 2012 4:24 pm, edited 1 time in total.
l3v3rz offline
Savvy Roboteer
Savvy Roboteer
Posts: 473
Joined: Fri Jul 18, 2008 2:34 pm

Post by PaulL » Sun Jun 24, 2012 4:09 am

Post by PaulL
Sun Jun 24, 2012 4:09 am

Hi Limor, Just noticed this post via another...

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
Hi Limor, Just noticed this post via another...

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
PaulL offline
Savvy Roboteer
Savvy Roboteer
Posts: 423
Joined: Sat Sep 15, 2007 12:52 am

Post by limor » Sun Jun 24, 2012 9:55 pm

Post 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)
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)
limor offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Previous
Previous
19 postsPage 2 of 21, 2
19 postsPage 2 of 21, 2