Or would the pi be running some kind of "upper level brain" program that would interpret the surroundings and then send commands the propeller board?
You got it.
I expect the primary usage of RoboPi will be as a low level, hard real time controller for robots wanting to use the Raspberry Pi for vision, GPS, and high level control, and using RoboPi for very precise motor and servo control, other hard real time I/O, and analog to digital conversion.
As Heater pointed out, it can also be used for non-robotic applications, and RoboPi has three of my 10 pin module sockets, as well as two I2C headers for expansion. Almost every previous Mikronauts board, including all 10 pin modules, will work with RoboPi by design.
Or is the propeller running autonomously and just dumping "log data" to the pi?
It could do that. I could see some applications where the propeller was in charge, with the Pi acting as a WiFi/Bluetooth interface, and development system for the propeller.
Frankly it makes sense to place the overall control logic on the Pi due to its larger memory space and higher performance, and use the propeller where it shines - precisely timed I/O.
Right now I am looking into what would be the best approach to achieve my goals; currently I am evaluating:
A) Firmata (see firmata.org, simple to implement) WiringPi (I am in touch with its author, this would give Python/C/C++ support)
C) writing my own simple ASCII based protocol
D) writing my own robust error-checked binary protocol
I have just over a week before the production boards arrive to get something running
Fortunately my RoboProp diagnostics and software work just fine with RoboPi (except for uSD and L298 which RoboPi does not have, but can be added to RoboPi via my headers)
I think this is a neat combination of boards, and I am simply trying to understand potential use cases for this "micro-system", and also what problems this combination is meant to be a solution for, and finally how a combined platform like this would likely be programmed to address the problem domain.
Thank you!
This combination is meant for:
- developing interesting robots with vision capabilities
- giving the Raspberry Pi hard real-time I/O capabilities
- a "smart" I/O add-on for the Pi
This combined platform would be programmed one of two ways:
- an I/O controller/slave for the Pi, controlled with a pre-defined protocol
- an intelligent peripheral for the Pi, whose software can be developed on the Pi
Basically, the "sky is the limit", and I have not even begun to scratch the surface of what it may accomplish.
The Pi has a UART interface on it's GPIO connectors. Which this board mates to. That is how you load the Propeller programs from the Pi. Of course this can be used as a communication link when your Propeller is running, just as we do when working from the PC via PropPlug or whatever. Not just commands but status back from the Prop/hardware, whatever.
I believe it would also be possible to use the I2C/SPI on that GPIO as well with a bit more work.
Interesting idea. There is no reason not to link one or more of the Pi GPIO pins to the Prop for such signalling. The signals could be used on the Pi either by the same program that is normally driving the Prop or by some other "watchdog" process.
Heater... you figured it out!
I was not going to mention the possibility of one Raspberry Pi controlling a number of RoboPi's over I2C until I got it running; I already found an I2C slave object in OBEX.
RoboPi has two I2C headers, one connected to the Pi's SDA/SCL, and one connected to the Prop's SDA/SCL.
The idea was that a simple four pin female-female jumper cable could be used to connect a second RoboPi to the one stacked on top of the Pi, and more could be connected if needed with a "daisy chain" cable, or small breakout board with a star configuration.
Of course this could also be used to add additional I2C peripherals.
Looks like a great board for lots of interesting projects. Self contained programming enviroment for the Prop esp with Adafruits TFT board for the Pi. Anything that promotes the Prop and Pi is a good thing IMHO.
Do you have any provision for the power button problem on the Pi? One BIG gripe I have with them is no provision to power on and off in a safe way. Pull the plug on the running OS enough times and you will frag the SD card. Who wants to open a shell, elevate to root, and then issue commands to shutdown, wait till it shuts down, and then pull the plug.
That's actually where I am right now on a custom BeagleBone project. Arch Linux broke it's response to the power button signal so now I'm back to needing to create an external power switch and connect it to GPIO with a service running to watch it.
Note to single board SoC designers and OS coders: Power buttons! Everything that anyone makes with one of these is going to want a simple power button to go with it without having to write their own daemons.
Do you have any provision for the power button problem on the Pi? One BIG gripe I have with them is no provision to power on and off in a safe way. Pull the plug on the running OS enough times and you will frag the SD card. Who wants to open a shell, elevate to root, and then issue commands to shutdown, wait till it shuts down, and then pull the plug.
There's always the method we sometimes used in the past.. make a 'halt' user account, and set the shell to /sbin/halt (or whatever's the shutdown command on the particular *nix variant).
Then at the login: prompt just enter 'halt' and press return, and you shut down. Maybe add a 'reboot' account with a similar setup.
Admttedly this was more practical back when graphical UIs and window managers weren't invented.. you just had a terminal and a 'login:' prompt.
But you could start from there: Make some kind of user-space driver, for example, which monitors a particular GPIO pin or something. Let it execute /sbin/halt or /sbin/reboot when it sees something. Or use some other kind of signalling mechanism, you just need a simple driver or script which exectures /sbin/halt.
I'll PM as soon as I have the final numbers. PM me your snail mail address, I am hoping to make a run to the post office tomorrow.
TinkersALot:
You are welcome! "app-stacks" - making it easy for educational users - will be very important. I'll post updates here as they happen
KMyers:
Thank you!
photomanck:
The shutdown issue bugs me too. I have thought of "solving" it by hooking up one of the Pi GPIO's to a push button, setting an interrupt on it, then have it issue a sudo'd "shutdown now -h" when pressed. (Edit: I see that Tor also posted essentially the same trick while I was typing)
I have not played much with my BeagleBones, other than designing a prototype board for them (EZasBone, see http://www.mikronauts.com/proto/ezasbone/)... I initially got them for the greater number of I/O's and to play with the PRU's, however support for the PRU's appears to be waning, apparently they are no longer in the latest OMAP datasheets (or so the rumour goes).
Sorry, yes, so you did. I don't know how I got a "not" in there. So we agree they are a bargain.
They do have this annoying feature that you have to use I/O pins in groups, or "ports". Ports can be defined as 1, 2, 8, 16 bits wide. In each such defined port all the pins have to be set either input or output together. There are restrictions on which pins can be members of what ports. All this means you can't just use pins willy-nilly as you might on a Prop.
There's always the method we sometimes used in the past.. make a 'halt' user account, and set the shell to /sbin/halt (or whatever's the shutdown command on the particular *nix variant).
Then at the login: prompt just enter 'halt' and press return, and you shut down. Maybe add a 'reboot' account with a similar setup.
Admttedly this was more practical back when graphical UIs and window managers weren't invented.. you just had a terminal and a 'login:' prompt.
Those are are practical ways to go but I think better suited to a stationary system than something that is moving around on it's own. It does save a step or two though so I may do that.
But you could start from there: Make some kind of user-space driver, for example, which monitors a particular GPIO pin or something. Let it execute /sbin/halt or /sbin/reboot when it sees something. Or use some other kind of signalling mechanism, you just need a simple driver or script which exectures /sbin/halt.
I was curious if Bill's board included any built-in way to deal with doing that? My previous solution did all that but it also used an MCU to manage a power MOSFET. Here we already have an MCU so if it had a header for a momentary switch and two (maybe just one) GPIO attached we could easily implement this in the Prop. A latching push on/off switch could bypass the transistor for switching the MOSFET to allow for dumb on/off in absence of programming for the smarter switch. Well....... thinking about it though the Prop is a bit too heavy-weight to keep powered while off so you would need some way to have the momentary switch power the prop up long enough to take over holding the MOSFET on. So maybe more complication than is really appropriate for his board.
It's just an area that seems to be glaringly be missing in these boards so far. A power switch and a seamless way to integrate to it. I've just spent way more time making a solution for it myself than I think most people are willing to do. Maybe if my little power switch board pans out when OSH Park delivers it I'll see if there is more interest. Kinda similar to the Polulu power switch but sends an interrupt when the power button is pushed and does not turn off until a falling edge on the power off signal line. Problem right now is that it's pretty heavy weight at around 60 or 70uA when off and a couple mA when on.
Bill,
Nice boards!
Since Leon and others have successfully derailed your nice thread, why don't you start a fresh one and rename this thread as derailed. Perhaps one of the moderators could lock this?
Bill,
Nice boards!
Since Leon and others have successfully derailed your nice thread, why don't you start a fresh one and rename this thread as derailed. Perhaps one of the moderators could lock this?
Nah, that's like playing whack-a-mole. We are just getting started.
I'm busy building the latest propgcc, openspin, SimpleIDE etc for the Raspberry Pi as we speak. Mostly spurred on by this announcement.
One little detail I would like to have seen on such a board is a real time clock chip. Basically because the Pi board does not have one. When the Pi starts up it has no idea what the time is if it is not connected to an NTP server.
Nah, that's like playing whack-a-mole. We are just getting started.
I'm busy building the latest propgcc, openspin, SimpleIDE etc for the Raspberry Pi as we speak. Mostly spurred on by this announcement.
One little detail I would like to have seen on such a board is a real time clock chip. Basically because the Pi board does not have one. When the Pi starts up it has no idea what the time is if it is not connected to an NTP server.
Sorry if my posts came across as a derail, just something I have been brooding about of late and if you can manage to work it into a revision or stack-on I think it would be helpful to others too. I'm looking forward to seeing how you get the SimpleIDE integration going. I just re-worked my custom board to tie into the programming serial pins on my Prop. Why I was not doing that to start I don't know.
There was not enough room on the board to add a clock chip, however it would not surprise me if I had an RTC solution on the way...
There's another big win that most Pi users have to kludge together! Will be waiting to see what you come up with.
I guess it was more of a question if you plan to support propeller-load as well as SimpleIDE. I usually use the former. But in any case, I'm excited. This is something that is long overdue, especially since I have my free RaspberryPis from Adafruit just waiting to be used
I guess it was more of a question if you plan to support propeller-load as well as SimpleIDE. I usually use the former. But in any case, I'm excited. This is something that is long overdue, especially since I have my free RaspberryPis from Adafruit just waiting to be used
SimpleIDE uses propeller-load to load programs so if SimpleIDE is working then propeller-load must be as well.
And how did you manage to get free RaspPis from Adafruit? :-)
The 0-8-4 version is a bit old but works. The loader included also works using the UART on the Raspi GPIO headers and so should work on a Raspi with Bill board mated to it.
The 0-9-43 version is newer but does is no able to use that UART. You will need a propplug or such.
I am just now building a current version of propgcc and SimpeIDE. It takes about a day to build on the Pi!
It is intended that when I post the package it will have UART loader capability back in again.
And how did you manage to get free RaspPis from Adafruit? :-)
Adafruit gives a free RaspberryPi with orders over $350 (link). They also seem to be a major place to host RPi stuff. Maybe RoboPi can be sold there as well?
Adafruit gives a free RaspberryPi with orders over $350 (link). They also seem to be a major place to host RPi stuff. Maybe RoboPi can be sold there as well?
Thanks! I guess I don't spend enough at Adafruit to get any free RaspPis but I did buy mine there.
Thanks & no worries! A Pi works great as a PropPlug replacement
I'll post a link here when my Pi product with an RTC is ready.
SRLM
Thank you. FYI, even my EZasPi prototype board for the Pi can be used as a prop plug. For some reason, it has a connector for that usage, plus an I2C connector as well. Fortuitous non-coincidence...
I finished calculating my parts costs, and have determined the pricing I can offer RoboPi kits at.
The following pricing is for 1-9 kits per order. Please contact me for educational or distributor quantity pricing.
RoboPi Lite Kit: $24.95USD + s/h
This package is intended for hobbyists who already have the IC's, or schools/clubs/distributors who prefer to source their own integrated circuits.
- printed circuit board
- extra tall stacking header
- nylon spacers, screws, nuts for the two mounting holes
- 6.250MHz crystal
- all the parts EXECPT for Propeller, MCP3208, 25LC512 (Digikey.com pricing for this line was $21+s/h yesterday)
- DOES NOT INCLUDE A RASPBERY PI
RoboPi Full Kit: $49.95USD + s/h
- everything included in the Lite Kit
- Propeller P8X32A-D40 chip
- MCP3208 12 bit ADC
- 24LC512 EEPROM
- DOES NOT INCLUDE A RASPBERY PI
Shipping & Handling
for one only RoboPi Lite Kit s/h is $8.00USD to the continental US, no insurance, no tracking
for one or two RoboPi kits (Lite or Full) s/h is $16.50 to the continental US, $100 insurance, tracking number provided
Please contact me for shipping quotes for other destinations or for a larger number of kits with your address, as for larger quantities I use "Expedited Post" for which I need the destination and number of kits. At three kits and up, Expedited ends up costing less on a per-kit basis than the options above.
Shipping to Canada is a bit cheaper (as I am based in Canada), shipping outside of North America costs more.
Availability
I expect the production boards to arrive at the end of the month, so I expect to be able to ship kits in the first week of February.
I will announce it when the production boards arrive.
Comments
Hi Bill,
Please send me a PM telling me how much you want for the prototype board kit and the details for ordering it.
Thanks,
David
The Raspberry Pi's serial port is permanently connected to the serial port on RoboPi - so the two boards are intimately connected
GPIO #17 is connected to the propeller's reset line, so SimpleIDE running on the Pi can program RoboPi
There is a PropPlug compatible header on RoboPi, so it can also be used independent of a Raspberry Pi.
You got it.
I expect the primary usage of RoboPi will be as a low level, hard real time controller for robots wanting to use the Raspberry Pi for vision, GPS, and high level control, and using RoboPi for very precise motor and servo control, other hard real time I/O, and analog to digital conversion.
As Heater pointed out, it can also be used for non-robotic applications, and RoboPi has three of my 10 pin module sockets, as well as two I2C headers for expansion. Almost every previous Mikronauts board, including all 10 pin modules, will work with RoboPi by design.
It could do that. I could see some applications where the propeller was in charge, with the Pi acting as a WiFi/Bluetooth interface, and development system for the propeller.
Frankly it makes sense to place the overall control logic on the Pi due to its larger memory space and higher performance, and use the propeller where it shines - precisely timed I/O.
I am looking into support software right now.
My goal is to support:
1) Scratch (for young users)
2) Python (for quick prototyping)
3) C/C++ (for advanced users)
Right now I am looking into what would be the best approach to achieve my goals; currently I am evaluating:
A) Firmata (see firmata.org, simple to implement)
C) writing my own simple ASCII based protocol
D) writing my own robust error-checked binary protocol
I have just over a week before the production boards arrive to get something running
Fortunately my RoboProp diagnostics and software work just fine with RoboPi (except for uSD and L298 which RoboPi does not have, but can be added to RoboPi via my headers)
Thank you!
This combination is meant for:
- developing interesting robots with vision capabilities
- giving the Raspberry Pi hard real-time I/O capabilities
- a "smart" I/O add-on for the Pi
This combined platform would be programmed one of two ways:
- an I/O controller/slave for the Pi, controlled with a pre-defined protocol
- an intelligent peripheral for the Pi, whose software can be developed on the Pi
Basically, the "sky is the limit", and I have not even begun to scratch the surface of what it may accomplish.
Great job! Really looking forward to being able to order some of these boards for our children's robotics groups I am working with.
Bob
Heater... you figured it out!
I was not going to mention the possibility of one Raspberry Pi controlling a number of RoboPi's over I2C until I got it running; I already found an I2C slave object in OBEX.
RoboPi has two I2C headers, one connected to the Pi's SDA/SCL, and one connected to the Prop's SDA/SCL.
The idea was that a simple four pin female-female jumper cable could be used to connect a second RoboPi to the one stacked on top of the Pi, and more could be connected if needed with a "daisy chain" cable, or small breakout board with a star configuration.
Of course this could also be used to add additional I2C peripherals.
Less than two weeks until the production boards are supposed to arrive...
I am working on sourcing parts and figuring out the BOM costs today.
I would appreciate any and all feedback on how it works out for you and your group (and everyone else that gets one)!
It is even more interesting that you are considering the "app-stacks" (you heard it here first!) to go along with your "board stacks"
I will be watching this space -- and as I said, if the price is right may be compelled to jump into the pi too (finally)
Looks like a great board for lots of interesting projects. Self contained programming enviroment for the Prop esp with Adafruits TFT board for the Pi. Anything that promotes the Prop and Pi is a good thing IMHO.
Good work!
Do you have any provision for the power button problem on the Pi? One BIG gripe I have with them is no provision to power on and off in a safe way. Pull the plug on the running OS enough times and you will frag the SD card. Who wants to open a shell, elevate to root, and then issue commands to shutdown, wait till it shuts down, and then pull the plug.
That's actually where I am right now on a custom BeagleBone project. Arch Linux broke it's response to the power button signal so now I'm back to needing to create an external power switch and connect it to GPIO with a service running to watch it.
Note to single board SoC designers and OS coders: Power buttons! Everything that anyone makes with one of these is going to want a simple power button to go with it without having to write their own daemons.
Then at the login: prompt just enter 'halt' and press return, and you shut down. Maybe add a 'reboot' account with a similar setup.
Admttedly this was more practical back when graphical UIs and window managers weren't invented.. you just had a terminal and a 'login:' prompt.
But you could start from there: Make some kind of user-space driver, for example, which monitors a particular GPIO pin or something. Let it execute /sbin/halt or /sbin/reboot when it sees something. Or use some other kind of signalling mechanism, you just need a simple driver or script which exectures /sbin/halt.
-Tor
I'll PM as soon as I have the final numbers. PM me your snail mail address, I am hoping to make a run to the post office tomorrow.
TinkersALot:
You are welcome! "app-stacks" - making it easy for educational users - will be very important. I'll post updates here as they happen
KMyers:
Thank you!
photomanck:
The shutdown issue bugs me too. I have thought of "solving" it by hooking up one of the Pi GPIO's to a push button, setting an interrupt on it, then have it issue a sudo'd "shutdown now -h" when pressed. (Edit: I see that Tor also posted essentially the same trick while I was typing)
I have not played much with my BeagleBones, other than designing a prototype board for them (EZasBone, see http://www.mikronauts.com/proto/ezasbone/)... I initially got them for the greater number of I/O's and to play with the PRU's, however support for the PRU's appears to be waning, apparently they are no longer in the latest OMAP datasheets (or so the rumour goes).
Totally agreed about power buttons.
Sorry, yes, so you did. I don't know how I got a "not" in there. So we agree they are a bargain.
They do have this annoying feature that you have to use I/O pins in groups, or "ports". Ports can be defined as 1, 2, 8, 16 bits wide. In each such defined port all the pins have to be set either input or output together. There are restrictions on which pins can be members of what ports. All this means you can't just use pins willy-nilly as you might on a Prop.
Those are are practical ways to go but I think better suited to a stationary system than something that is moving around on it's own. It does save a step or two though so I may do that.
I was curious if Bill's board included any built-in way to deal with doing that? My previous solution did all that but it also used an MCU to manage a power MOSFET. Here we already have an MCU so if it had a header for a momentary switch and two (maybe just one) GPIO attached we could easily implement this in the Prop. A latching push on/off switch could bypass the transistor for switching the MOSFET to allow for dumb on/off in absence of programming for the smarter switch. Well....... thinking about it though the Prop is a bit too heavy-weight to keep powered while off so you would need some way to have the momentary switch power the prop up long enough to take over holding the MOSFET on. So maybe more complication than is really appropriate for his board.
It's just an area that seems to be glaringly be missing in these boards so far. A power switch and a seamless way to integrate to it. I've just spent way more time making a solution for it myself than I think most people are willing to do. Maybe if my little power switch board pans out when OSH Park delivers it I'll see if there is more interest. Kinda similar to the Polulu power switch but sends an interrupt when the power button is pushed and does not turn off until a falling edge on the power off signal line. Problem right now is that it's pretty heavy weight at around 60 or 70uA when off and a couple mA when on.
Nice boards!
Since Leon and others have successfully derailed your nice thread, why don't you start a fresh one and rename this thread as derailed. Perhaps one of the moderators could lock this?
Hmm... interesting idea.
On the other hand, I think Leon's comments were sufficiently addressed
I'm busy building the latest propgcc, openspin, SimpleIDE etc for the Raspberry Pi as we speak. Mostly spurred on by this announcement.
One little detail I would like to have seen on such a board is a real time clock chip. Basically because the Pi board does not have one. When the Pi starts up it has no idea what the time is if it is not connected to an NTP server.
When I next take a break from P2 I'd like to have a look at RP and your board.
Sorry to see the "XMOS" attack.
Brian
Thanks Heater, newer software will be much appreciated.
There was not enough room on the board to add a clock chip, however it would not surprise me if I had an RTC solution on the way...
Of course that will be posted!
Sorry if my posts came across as a derail, just something I have been brooding about of late and if you can manage to work it into a revision or stack-on I think it would be helpful to others too. I'm looking forward to seeing how you get the SimpleIDE integration going. I just re-worked my custom board to tie into the programming serial pins on my Prop. Why I was not doing that to start I don't know.
There's another big win that most Pi users have to kludge together! Will be waiting to see what you come up with.
I guess it was more of a question if you plan to support propeller-load as well as SimpleIDE. I usually use the former. But in any case, I'm excited. This is something that is long overdue, especially since I have my free RaspberryPis from Adafruit just waiting to be used
And how did you manage to get free RaspPis from Adafruit? :-)
There are builds of two versions of SimpleIDE available here:
https://dl.dropboxusercontent.com/u/81267937/SimpleIDE-0-8-4.armv6l.raspberrypi-linux.tar.bz2
and here:
https://dl.dropboxusercontent.com/u/81267937/SimpleIDE-0-9-43.armv6l.raspberrypi-linux.tar.bz2
They both contain propgcc and propeller-load.
The 0-8-4 version is a bit old but works. The loader included also works using the UART on the Raspi GPIO headers and so should work on a Raspi with Bill board mated to it.
The 0-9-43 version is newer but does is no able to use that UART. You will need a propplug or such.
I am just now building a current version of propgcc and SimpeIDE. It takes about a day to build on the Pi!
It is intended that when I post the package it will have UART loader capability back in again.
Adafruit gives a free RaspberryPi with orders over $350 (link). They also seem to be a major place to host RPi stuff. Maybe RoboPi can be sold there as well?
Thanks & no worries! A Pi works great as a PropPlug replacement
I'll post a link here when my Pi product with an RTC is ready.
SRLM
Thank you. FYI, even my EZasPi prototype board for the Pi can be used as a prop plug. For some reason, it has a connector for that usage, plus an I2C connector as well. Fortuitous non-coincidence...
Heater
I never tried the loader in 0.8.4, I found the one you posted in the SimpleIDE for the Pi thread in the PropGCC forum and used that. See http://forums.parallax.com/showthread.php/141469-SimpleIDE-for-Raspberry-Pi-Raspian?p=1235583&viewfull=1#post1235583
RoboPi Pricing
I finished calculating my parts costs, and have determined the pricing I can offer RoboPi kits at.
The following pricing is for 1-9 kits per order. Please contact me for educational or distributor quantity pricing.
RoboPi Lite Kit: $24.95USD + s/h
This package is intended for hobbyists who already have the IC's, or schools/clubs/distributors who prefer to source their own integrated circuits.
- printed circuit board
- extra tall stacking header
- nylon spacers, screws, nuts for the two mounting holes
- 6.250MHz crystal
- all the parts EXECPT for Propeller, MCP3208, 25LC512 (Digikey.com pricing for this line was $21+s/h yesterday)
- DOES NOT INCLUDE A RASPBERY PI
RoboPi Full Kit: $49.95USD + s/h
- everything included in the Lite Kit
- Propeller P8X32A-D40 chip
- MCP3208 12 bit ADC
- 24LC512 EEPROM
- DOES NOT INCLUDE A RASPBERY PI
Shipping & Handling
for one only RoboPi Lite Kit s/h is $8.00USD to the continental US, no insurance, no tracking
for one or two RoboPi kits (Lite or Full) s/h is $16.50 to the continental US, $100 insurance, tracking number provided
Please contact me for shipping quotes for other destinations or for a larger number of kits with your address, as for larger quantities I use "Expedited Post" for which I need the destination and number of kits. At three kits and up, Expedited ends up costing less on a per-kit basis than the options above.
Shipping to Canada is a bit cheaper (as I am based in Canada), shipping outside of North America costs more.
Availability
I expect the production boards to arrive at the end of the month, so I expect to be able to ship kits in the first week of February.
I will announce it when the production boards arrive.
(Click on the thumbnail for a larger image)
Soon I'll also be offering an L298 motor driver add-on module that I import.