Robosavvy Chanllenge #2: attach an OLED to Robobuilder
Robosavvy Chanllenge #2: attach an OLED to Robobuilder
by PedroR
Tue Sep 23, 2008 6:32 pm
Hi all
This is the second challenge proposed:
Challenge #2:
Description:
Connect uOLED screen to Robobuilder, assemble it on the robot and document the full process.
Be the first to document pictorially how to attach a uOLED and have Robobuilder outputting status information or even robotic emotions!
Prize:
Voucher of 65 GBP for purchases at Robosavvy.
This is the second challenge proposed:
Challenge #2:
Description:
Connect uOLED screen to Robobuilder, assemble it on the robot and document the full process.
Be the first to document pictorially how to attach a uOLED and have Robobuilder outputting status information or even robotic emotions!
Prize:
Voucher of 65 GBP for purchases at Robosavvy.
Last edited by PedroR on Thu Jan 22, 2009 11:00 pm, edited 1 time in total.
by PedroR
Thu Sep 25, 2008 3:49 pm
hi all
regarding this oled challenge there is one question that I would like to discuss:
how to interfacethe robobuilder with the OLED?
ATMEGA128 has 2 UARTs: one is used for the servos and one for communicating with the computer.
What is the best option?
Should the OLED sit on the servo UART and emulate the protocol?
-- or --
Connect the OLED to the computer port and use some form of switch to change between the OLED and the computer?....
Input will be greatly appreciated
Pedro.
regarding this oled challenge there is one question that I would like to discuss:
how to interfacethe robobuilder with the OLED?
ATMEGA128 has 2 UARTs: one is used for the servos and one for communicating with the computer.
What is the best option?
Should the OLED sit on the servo UART and emulate the protocol?
-- or --
Connect the OLED to the computer port and use some form of switch to change between the OLED and the computer?....
Input will be greatly appreciated
Pedro.
by i-Bot
Thu Sep 25, 2008 7:10 pm
I don't think it is possible to state if one or the other is better, they are different and each has +/-.
If you program in C you can make either work, the larger difference is when you retain the standard RBC firmware.
You must decide if you are expecting the uOLED to perform a controller or a device role. As a device the uOLED would sit on the wCK bus and respond to the RBC. As a controller the uOLED could sit on the PC bus and send commands to the RBC emulating the PC or the IR remote.
Programming the device is slightly more difficult since you need to emulate another device, and the only one is a wCK. It a least has to perform enough of the protocol to follow the bus transacations and detect ones for itself. The ability to pass data all the way from motion builder or action builder scripts seems quite limited. The only clear channel from Motion builder script to servo are the data out bits. Position data is likely to be interpolated by the RBC unless you are very careful in the program. There is an alternative that the uOLED is aware of the commands for all servos and is fast enough to interpet all simultaneously ! All the transparent version LED on one screen, or responding to all servo positions.
I am not seeing any route back from uOLED to an action builder script.
Programming a controller allows the uOLED to emulate the the remote to invoke programmed motions, and also can set the RBC to the mode to control the wCK bus directly.
So which is best, all three.
Three ! Yes well the uOLED can be the direct master on the wCK bus
instead of the RBC.
All! Well what the point of having 8 COGS in the prop unless you do everything. and you have got 4 I/O pins
If you program in C you can make either work, the larger difference is when you retain the standard RBC firmware.
You must decide if you are expecting the uOLED to perform a controller or a device role. As a device the uOLED would sit on the wCK bus and respond to the RBC. As a controller the uOLED could sit on the PC bus and send commands to the RBC emulating the PC or the IR remote.
Programming the device is slightly more difficult since you need to emulate another device, and the only one is a wCK. It a least has to perform enough of the protocol to follow the bus transacations and detect ones for itself. The ability to pass data all the way from motion builder or action builder scripts seems quite limited. The only clear channel from Motion builder script to servo are the data out bits. Position data is likely to be interpolated by the RBC unless you are very careful in the program. There is an alternative that the uOLED is aware of the commands for all servos and is fast enough to interpet all simultaneously ! All the transparent version LED on one screen, or responding to all servo positions.
I am not seeing any route back from uOLED to an action builder script.
Programming a controller allows the uOLED to emulate the the remote to invoke programmed motions, and also can set the RBC to the mode to control the wCK bus directly.
So which is best, all three.
Three ! Yes well the uOLED can be the direct master on the wCK bus
instead of the RBC.
All! Well what the point of having 8 COGS in the prop unless you do everything. and you have got 4 I/O pins
by PedroR
Fri Sep 26, 2008 10:42 pm
Hi iBot and visitors 
After reading your suggestions something became more clear: if we want to use the OLED for debugging purposes then what one would need is to simply "spy" on what's happening on the bus, right?
Maybe starting with debugging and "spying" could be easier and then later evolve to a more complex approach.
This way if I want to know the status of the Acceleration sensor or what's going on in terms of input/reaction I would just need to spy on the commands being sent and be totally silent (basically just connecting RX in parallel with the some servo, right?).
What is your opinion about this approach?
Cheers
Pedro.
After reading your suggestions something became more clear: if we want to use the OLED for debugging purposes then what one would need is to simply "spy" on what's happening on the bus, right?
Maybe starting with debugging and "spying" could be easier and then later evolve to a more complex approach.
This way if I want to know the status of the Acceleration sensor or what's going on in terms of input/reaction I would just need to spy on the commands being sent and be totally silent (basically just connecting RX in parallel with the some servo, right?).
What is your opinion about this approach?
Cheers
Pedro.