Just wondering.. Have you found that the display is not as useful in practice as you thought it might be? Seems like the only time I even use the display on my robot controller is for feedback during bootup. I'm half tempted to just get rid of mine as it'll same some weight/volume/trouble.

Just wondering.. Have you found that the display is not as useful in practice as you thought it might be? Seems like the only time I even use the display on my robot controller is for feedback during bootup. I'm half tempted to just get rid of mine as it'll same some weight/volume/trouble.

You are hitting my major concern now: should I keep the display or get rid of it in favor of another adapter (sound or bluetooth).

The weight and size are not my main concerne. The Coby DP151 is working well and is only 46 x 33 x 9 mm and 11 gms.

The issue is I have only 4 usb ports available (sd card, wlan, webcam, lcd). If I want to connect both lcd and another adapter , I need a 2nd hub. The weight and space are not an issue (my hub is 2gms and 3x2 cm actually, not 3x4) but I am concern with the extra power needed as I want to keep an 1 hour play time with a 1300 mah single lipo (3.7 v).
I will do more power measurement to get some data.

The dislay is indeed extremely helpful for debugging and check what is going on. In particular to see if the system boot up correctly, the wlan link quality and some events.
With lcd4linux I can display any system values, messages or program variables.
I am working on some scripts to monitor and display the Bifferboard Nano batterie status and the Nano batterie status (done).
I will also use the lcd to display the I2c accelerometer and distance values.

However, I can now fetch all these data through a wifi socket connection and display them on my computer Flash interface .

I can also use 2 or 3 leds from the gpio to inform about some system events (boot up completed, link quality by blinking, ...) or play the messages with espeak.

Conclusion: I will keep the Lcd for debugging and will probably get rid of it when everything will be fine tuned.

You are hitting my major concern now: should I keep the display or get rid of it in favor of another adapter (sound or bluetooth).

The weight and size are not my main concerne. The Coby DP151 is working well and is only 46 x 33 x 9 mm and 11 gms.

The issue is I have only 4 usb ports available (sd card, wlan, webcam, lcd). If I want to connect both lcd and another adapter , I need a 2nd hub. The weight and space are not an issue (my hub is 2gms and 3x2 cm actually, not 3x4) but I am concern with the extra power needed as I want to keep an 1 hour play time with a 1300 mah single lipo (3.7 v).
I will do more power measurement to get some data.

The dislay is indeed extremely helpful for debugging and check what is going on. In particular to see if the system boot up correctly, the wlan link quality and some events.
With lcd4linux I can display any system values, messages or program variables.
I am working on some scripts to monitor and display the Bifferboard Nano batterie status and the Nano batterie status (done).
I will also use the lcd to display the I2c accelerometer and distance values.

However, I can now fetch all these data through a wifi socket connection and display them on my computer Flash interface .

I can also use 2 or 3 leds from the gpio to inform about some system events (boot up completed, link quality by blinking, ...) or play the messages with espeak.

Conclusion: I will keep the Lcd for debugging and will probably get rid of it when everything will be fine tuned.

I don't know how the bifferboard works, but my chumby board will spit out info over its serial port while Linux is booting. After it is booted I believe you can SSH into it as well.

What I'd like to do is to have some sort of wireless serial connection that talks to an ios or android device without requiring Linux booted. I'm guessing this might need to be bluetooth. A BlueSMiRF could work, but it's expensive and a bit large. Once Linux is booted my ios/android app could switch over to wifi.

With this setup I could have debugging information at all times without the weight and volume of an onboard display. I also gain a nifty way of controlling the robot.

I don't know how the bifferboard works, but my chumby board will spit out info over its serial port while Linux is booting. After it is booted I believe you can SSH into it as well.

What I'd like to do is to have some sort of wireless serial connection that talks to an ios or android device without requiring Linux booted. I'm guessing this might need to be bluetooth. A BlueSMiRF could work, but it's expensive and a bit large. Once Linux is booted my ios/android app could switch over to wifi.

With this setup I could have debugging information at all times without the weight and volume of an onboard display. I also gain a nifty way of controlling the robot.

I was inspired to look into a low cost bluetooth solution and think this could be it..
http://www.circuitsathome.com/mcu/bluet ... o-usb-hostWith this you could plug in a $3 bluetooth dongle. Of course then you'd need the usb-host shield, but a usb-host shield is nothing more than a MAX3421E which cost $12 at quantity 1.

Oh. One other benefit of supporting bluetooth is that you could control your robot with a wireless PS3 or Wii controller too. My Robovie supported the use of a PS2 controller and it more interesting than expected.

I was inspired to look into a low cost bluetooth solution and think this could be it..
http://www.circuitsathome.com/mcu/bluet ... o-usb-hostWith this you could plug in a $3 bluetooth dongle. Of course then you'd need the usb-host shield, but a usb-host shield is nothing more than a MAX3421E which cost $12 at quantity 1.

Oh. One other benefit of supporting bluetooth is that you could control your robot with a wireless PS3 or Wii controller too. My Robovie supported the use of a PS2 controller and it more interesting than expected.

I am currently working on properly installing a SRF-10 distance sensor and BMA180 accelerometer. I have some code working (in Python and C) and my concerns now are to decide where to install the SRF-10 (I will need to either make a new head or a new chest) and how to integrate these measurement to some (usefull) robot control (reading is quite slow in Python so I seriously need to improve my C/C++)

The GUI control is board is in Flash, it is quite simple: when pressed, a button send a string (for example “SON” when the button Servo ON/OFF is pressed once) to a socket server, in Python, running on the Bifferboard who then send the according serial command to the NANO controller (in this case W2009f60100\r\n which turn the servos on).

The master slave slides generate some variables that are , in the same way, directly converted to some servo positions.

These slides are more for debugging and testing the connection and respond now. My plan is to do some master slave control with some potentiometers or sensors (connected to an Arduino for which Flash communication is easy to setup).

The Flash (socket) also receive and display the variables (Battery level, I2c variable) and strings from another similar Bifferboard Python server (I am redoing it).

The green button on the right of the Speech Synthetiser text box, send the content of this box to the server which trigger flite and read it (cmd = 'flite -t %r &' %data2) on the Nano.

The Button Music start a webradio, I need to add a button to stop it .....

The Python Socket server and the Flash Adobe GUI can be downloaded here:

I am currently working on properly installing a SRF-10 distance sensor and BMA180 accelerometer. I have some code working (in Python and C) and my concerns now are to decide where to install the SRF-10 (I will need to either make a new head or a new chest) and how to integrate these measurement to some (usefull) robot control (reading is quite slow in Python so I seriously need to improve my C/C++)

The GUI control is board is in Flash, it is quite simple: when pressed, a button send a string (for example “SON” when the button Servo ON/OFF is pressed once) to a socket server, in Python, running on the Bifferboard who then send the according serial command to the NANO controller (in this case W2009f60100\r\n which turn the servos on).

The master slave slides generate some variables that are , in the same way, directly converted to some servo positions.

These slides are more for debugging and testing the connection and respond now. My plan is to do some master slave control with some potentiometers or sensors (connected to an Arduino for which Flash communication is easy to setup).

The Flash (socket) also receive and display the variables (Battery level, I2c variable) and strings from another similar Bifferboard Python server (I am redoing it).

The green button on the right of the Speech Synthetiser text box, send the content of this box to the server which trigger flite and read it (cmd = 'flite -t %r &' %data2) on the Nano.

The Button Music start a webradio, I need to add a button to stop it .....

The Python Socket server and the Flash Adobe GUI can be downloaded here:

The basic jist is that you take the YUV values for a pixel and you use it to index into a LUT that gives you back a quantized color for the pixel. You end up with a frame with the background masked out and only a few color values to deal with. From this data it is much easier to robustly track an object.

The basic jist is that you take the YUV values for a pixel and you use it to index into a LUT that gives you back a quantized color for the pixel. You end up with a frame with the background masked out and only a few color values to deal with. From this data it is much easier to robustly track an object.

Limor pointed out your post to me which, after reading it, is definitely very interesting.

We'll be receiving here on RoboSavvy some new products in the next weeks which I thought might be interesting in advancing your design.

One is a 1.44" LCD http://www.4dsystems.com.au/prod.php?id=120Despite the small size it's powered by a GOLDELOX chip which is very powerful and can do quite a lot.
Check out the GFX or SGC section on the page. The module can work over serial (not sure about I2C) but the onboard processor can be programmed and operate stand alone; maybe even co-process some of the tasks on the robot.
I know it is capable of doing for example sound output and has some GPIO pins usable if you choose to program it in GFX mode.

If you want to do a simple color tracking mechanism (such as the one suggested billyzelsnack), it's quite easy to do that instructing the CAM to take small resolution frames and looking for BLOBs pixel by pixel.
I think the Bifferboard is of implementing such an algorithm which is fairly simple.
Also, since the CAM and data travels over the Serial line all the overhead of the USB stack is eliminated, releasing some processing power.
One sample algorithm can be found here http://geekblog.nl/entry/24

The CAM can also take higher resolution JPEGs should you wish to do simple streaming.

Pedro.

Hi Zahcok

Allow me to jump in with a couple of suggestions.

Limor pointed out your post to me which, after reading it, is definitely very interesting.

We'll be receiving here on RoboSavvy some new products in the next weeks which I thought might be interesting in advancing your design.

One is a 1.44" LCD http://www.4dsystems.com.au/prod.php?id=120Despite the small size it's powered by a GOLDELOX chip which is very powerful and can do quite a lot.
Check out the GFX or SGC section on the page. The module can work over serial (not sure about I2C) but the onboard processor can be programmed and operate stand alone; maybe even co-process some of the tasks on the robot.
I know it is capable of doing for example sound output and has some GPIO pins usable if you choose to program it in GFX mode.

If you want to do a simple color tracking mechanism (such as the one suggested billyzelsnack), it's quite easy to do that instructing the CAM to take small resolution frames and looking for BLOBs pixel by pixel.
I think the Bifferboard is of implementing such an algorithm which is fairly simple.
Also, since the CAM and data travels over the Serial line all the overhead of the USB stack is eliminated, releasing some processing power.
One sample algorithm can be found here http://geekblog.nl/entry/24

The CAM can also take higher resolution JPEGs should you wish to do simple streaming.

ah one last comment, we'll also be getting another LCD (a larger one with 3.2") which has a resistive touchscreen. The processor is a different - PICASO - but works in the same manner as the GOLDELOX. The PICASO just has more horsepower.

ah one last comment, we'll also be getting another LCD (a larger one with 3.2") which has a resistive touchscreen. The processor is a different - PICASO - but works in the same manner as the GOLDELOX. The PICASO just has more horsepower.