I really wish that the Pi Foundation and Raspbian developers just added the URI's for the source packages!
I did a bit more digging, and due to proprietary binary blobs, there is no source package to some drivers.
Wifey insisted I take most of the weekend off (it was a long weekend here, courtesy of "BC Family Day") - but I did manage to get some more work done on the RoboPi documentation.
- I fixed the green text (thx David)
- added LED orientation (thx David)
- fixed the Table of Contents (known LibreOffice issue, fix is to select the text and "Clear Formatting")
- some more text
- added I/O map instructions
- added RoboProp compatibility information
- start of testing instructions
Next:
- add a block diagram
- finally clean up my ugly schematic, add to manual
- finish testing instructions
So the manual is almost finished!
I also built a second RoboPi based robot, made a copy of the previous SD card for the new bot, and copied all RoboProp libraries, demos, diagnostics into a new server folder so I can make RoboPi versions.
Servo March 2013 should be out around Feb.20 with the RoboPi and Pi Jumper announcement...
I also have to package up some kits, my next post office run is scheduled for tomorrow.
I have started porting the RoboProp diagnostics to RoboPi.
I use minicom running on the Pi for testing:
minicom -b 9600 -o -D /dev/ttyAMA0
You can also use Putty, "sudo apt-get install putty" is your friend
Here is a sneak peak at the current menu:
RoboPi Diagnostics v0.2
---------------------------------
1) Test Propeller
2) Test EEPROM
s) Servo Test
a) ADC Test
m) Motor Driver Test
---------------------------------
READY>
1) Test Propeller:
Shows INA (P0..P31)
Checks for shorts (P0..P29)
2) Test EEPROM
Hex dump of first 256 bytes contained in the EEPROM
s) Servo Test
Lets you select a servo, sets it to 1500us, lets you increase/decrease the setting in 50us steps
a) ADC Test
Displays AIN0 - AIN7 values every second
m) Motor Driver Test
The motor driver test requires that an external dual-hbridge be hooked up to P8 - P11, enabled, with P8&P9 being the IN1&IN2 for Motor 1, and P9&P10 being IN3&IN4 for Motor 2.
- Allows you to set the direction of Motor 1 & 2 individually
- Allows speeding up & slowing down Motor 1 & 2 individually
- Allows stopping both motors
More tests as I add support for RoboPi peripherals
For testing, I am currently using a generic L298 board I had kicking around.
Update: Schematic is now in decent shape, the manual is finally almost complete!
Remaining work for the manual:
- add a block diagram
- finish testing instructions
I really have to re-do my Eagle symbol for servo headers.
My next post office run is scheduled for Monday.
Sounds good. I've decided to wait for my remaining parts to arrive before finishing the build of my RoboPi board so I probably won't have mine done until after next weekend.
I am confused... I need more coffee... previous email indicated that you finished assembly except for the two missing 470R resistors and the missing 1uH/3A inductor, and you were not in a hurry as the board is functional (except for 8 servos) without those components.
Last week was insane busy, I did not have time to test the other board I am mailing to you. I was waiting to test it before sending it with the three missing components.
This week I have a couple of tight deadlines to meet, but I am hoping to make a post office run today; if not, tomorrow.
I emailed a new draft manual to you today, I forgot to click send yesterday, and I noticed in in Drafts today.
Sounds good. I've decided to wait for my remaining parts to arrive before finishing the build of my RoboPi board so I probably won't have mine done until after next weekend.
I did a bit more digging, and due to proprietary binary blobs, there is no source package to some drivers.
This is not quite true.
Everything you need to build an OS for the Raspi is open source and available. Linux drivers and all.
What is not open source is the firmware for the GPU.
This is the same situation as the fact that some hardware, like a WIFI dongle, needs firmware to be loaded before it is useful. That firmware is often a closed source binary blob.
It is not the same situation as the Nvidea Linux drivers, which require you to run a binary blob as a Linux kernel driver.
Everything you need to build an OS for the Raspi is open source and available. Linux drivers and all.
What is not open source is the firmware for the GPU.
This is the same situation as the fact that some hardware, like a WIFI dongle, needs firmware to be loaded before it is useful. That firmware is often a closed source binary blob.
It is not the same situation as the Nvidea Linux drivers, which require you to run a binary blob as a Linux kernel driver.
- test the API
- add a serial wrapper around it
- write C library for the Pi that exposes the RoboPi API
I based the API on Wiring/Arduino, however I integrated the Servo library directly and made some changes to it; I did not like the idea of having to create a Servo object for each servo, attaching etc.
KISS principle at work
I am thinking of adding a simple checksum to the serial wrapper around the API in order to avoid the (very unlikely) comm errors.
I am confused... I need more coffee... previous email indicated that you finished assembly except for the two missing 470R resistors and the missing 1uH/3A inductor, and you were not in a hurry as the board is functional (except for 8 servos) without those components.
That is all true but I ran out of time that weekend to test the board and then I decided that before plugging in the socketed chips I'd just wait for the extra parts. I'm still not in a hurry. Last weekend was filled with chores around the house so I didn't get to do any Propeller work at all. I might try powering up the RoboPi this weekend though.
Last week was insane busy, I did not have time to test the other board I am mailing to you. I was waiting to test it before sending it with the three missing components.
This week I have a couple of tight deadlines to meet, but I am hoping to make a post office run today; if not, tomorrow.
I emailed a new draft manual to you today, I forgot to click send yesterday, and I noticed in in Drafts today.
No rush. Whenever it is ready is fine. I have lots of other projects to keep me busy.
Earlier in the thread I also posted the pin assigments for hooking up a dual H-Bridge and an SD card in such a way as to be software compatible with RoboProp. It is easy to hook up L293D, L298 or equivalent modules, and any SD breakout.
I actually have a SD/uSD 10 pin module for my boards (including RoboPi); Sapieha did a nice job as usual to lay it out.
It's a 10 pin module, has a full size SD card socket on one side, and a uSD socket on the other.
(old photo showing a couple of SD/uSD's plugged into the unreleased qsBridge)
Unfortunately the SD card socket needs to be glued on (crazy or hot glue), as the mounting solder pads from the bulk shipment of connectors did not line up with three of the four PCB pads for them :-(
If you want, I'll see if I can find some of my 10 pin SD/uSD modules. I have uSD connectors for it, and I can dig up the Digikey or Mouser part number for the expensive SD connector should fit perfectly - I also have the connectors that need a bit of glue.
If you are OK with the gluing, let's say $5 for the kit (with both SD and uSD connectors, needs a bit of glue) - assuming I find them, I could add them to your order as I have not shipped it yet.
I got a chance to start soldering my RoboPI this weekend. I haven't finished yet, but I can confirm that the kits are very nicely laid out and the instructions are clear.
I am really excited to try this kit to combine the excellent IO of the prop with a unix board I can use for image processing or more complex navigation.
- Packetized, error checked, serial I/O established between Prop and Linux via GetPacket() PutPacket() functions at both ends
- started wrapping RoboPiObj.spin methods in packet wrappers
- expect all verified working RoboPiObj methods to have equivalent RoboPiLib.c wrappers functional tomorrow, some working already
Question
- Should I supply a downloadable robopi.eeprom with a propeller-load executable for RoboPi so Pi users don't have to compile the RoboPi.spin packet handler, and RoboPiObj.spin it includes?
- Should I supply a downloadable robopi.eeprom with a propeller-load executable for RoboPi so Pi users don't have to compile the RoboPi.spin packet handler, and RoboPiObj.spin it includes?
Something that just works, is always a good idea - useful for separate verify of pathways & HW from Tool chains.
Also good in case someone suspects they have Zapped some part of the system.
Something that just works, is always a good idea - useful for separate verify of pathways & HW from Tool chains.
Also good in case someone suspects they have Zapped some part of the system.
- 80% of 'RoboPiLib' is tested and functions 100% correctly
- some cleanup and I can publish it!
RoboPiObj / RoboPiLib API looks a lot like Wiring / Arduino, with a built-in servo and PWM handling (similar to, but simpler than Arduino servo library).
RoboPiLib - Pi side, uses /dev/ttyAMA0 to issue commands to RoboPi
RoboPiObj - Propeller object
RoboPi.spin - wrapper around RoboPiObj, implements serial communications layer, and serial command handling
FYI,
RoboPiLib (using /dev/ttyUSB0 etc) works just fine on Ubuntu on x86 boxes as well
Has the propellerload been modified to use GPIO to wiggle the reset on the Prop to program it? Would that be reasonably portable to the ARM7 BeagleBone? I will have no head with which to develop on SimpleIDE on the BBone. Is it possible to build only the loader? Then I develop on whatever system I want and the upload the file and push it out with the loader on the ARM host.
Do you guys think that should I keep servoAttach(pin) and servoDetach(pin)?
After thinking about it, they seem totally superflous, as they are exactly equivalent to
pinMode(pin,SERVO) and
pinMode(pin,INPUT)
Going with the"Keep Is Simple" philosophy, why give me two ways to do the same thing. If you have the servo wrappers, then they should add value to the pinMode rather than just wrap it.
{This statement is made not having looked at your library yet, just on basic principles}
Bill, I've just read through your very well done build manual in anticipation. The only suggestion I have would be to mention the electrolytics are polarized and need to be installed properly. You did that with the LEDs but not the caps....and I don't remember if you called it out with the diode.
If people haven't built a lot, they may forget those things along with how IC sockets and ICs go (you can tell that from your great pictures).
Earlier today, Broadcom announcedthe release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD license. The source release targets the BCM21553 cellphone chip, but it should be reasonably straightforward to port this to the BCM2835, allowing access to the graphics core without using the blob. As an incentive to do this work, we will pay a bounty of $10,000 to the first person to demonstrate to us satisfactorily that they can successfully run Quake III at a playable framerate on Raspberry Pi using these drivers. This competition is open worldwide, and you can find competition rules here which describe what you have to do, and how to enter.
This is indeed amazing news. People have been complaining about the closed nature of the Raspi GPU for a long time. Only a week or two ago one of the Raspberry Pi foundation insiders, who also works for Broadcom, was explaining to me that this would never happen!
Still, even with this, there is a lot of closed source code in use between applying power to the Pi and having Linux loaded. I don't worry about it much. It's rather like all the closed source code in a PC BIOS that has to run before the Linux boot loader starts.
We live in hope of an opensource world where we have control of what the machines we own are doing. We are not there by a long chalk but progress is being made little by little.
Comments
I did a bit more digging, and due to proprietary binary blobs, there is no source package to some drivers.
Wifey insisted I take most of the weekend off (it was a long weekend here, courtesy of "BC Family Day") - but I did manage to get some more work done on the RoboPi documentation.
- I fixed the green text (thx David)
- added LED orientation (thx David)
- fixed the Table of Contents (known LibreOffice issue, fix is to select the text and "Clear Formatting")
- some more text
- added I/O map instructions
- added RoboProp compatibility information
- start of testing instructions
Next:
- add a block diagram
- finally clean up my ugly schematic, add to manual
- finish testing instructions
So the manual is almost finished!
I also built a second RoboPi based robot, made a copy of the previous SD card for the new bot, and copied all RoboProp libraries, demos, diagnostics into a new server folder so I can make RoboPi versions.
Servo March 2013 should be out around Feb.20 with the RoboPi and Pi Jumper announcement...
I also have to package up some kits, my next post office run is scheduled for tomorrow.
Remaining work for the manual:
- add a block diagram
- finish testing instructions
I really have to re-do my Eagle symbol for servo headers.
My next post office run is scheduled for Monday.
I use minicom running on the Pi for testing:
You can also use Putty, "sudo apt-get install putty" is your friend
Here is a sneak peak at the current menu:
1) Test Propeller:
Shows INA (P0..P31)
Checks for shorts (P0..P29)
2) Test EEPROM
Hex dump of first 256 bytes contained in the EEPROM
s) Servo Test
Lets you select a servo, sets it to 1500us, lets you increase/decrease the setting in 50us steps
a) ADC Test
Displays AIN0 - AIN7 values every second
m) Motor Driver Test
The motor driver test requires that an external dual-hbridge be hooked up to P8 - P11, enabled, with P8&P9 being the IN1&IN2 for Motor 1, and P9&P10 being IN3&IN4 for Motor 2.
- Allows you to set the direction of Motor 1 & 2 individually
- Allows speeding up & slowing down Motor 1 & 2 individually
- Allows stopping both motors
More tests as I add support for RoboPi peripherals
For testing, I am currently using a generic L298 board I had kicking around.
I am confused... I need more coffee... previous email indicated that you finished assembly except for the two missing 470R resistors and the missing 1uH/3A inductor, and you were not in a hurry as the board is functional (except for 8 servos) without those components.
Last week was insane busy, I did not have time to test the other board I am mailing to you. I was waiting to test it before sending it with the three missing components.
This week I have a couple of tight deadlines to meet, but I am hoping to make a post office run today; if not, tomorrow.
I emailed a new draft manual to you today, I forgot to click send yesterday, and I noticed in in Drafts today.
This is not quite true.
Everything you need to build an OS for the Raspi is open source and available. Linux drivers and all.
What is not open source is the firmware for the GPU.
This is the same situation as the fact that some hardware, like a WIFI dongle, needs firmware to be loaded before it is useful. That firmware is often a closed source binary blob.
It is not the same situation as the Nvidea Linux drivers, which require you to run a binary blob as a Linux kernel driver.
I thought there were more binary blobs, happy to hear there are not.
The fact is, Raspbian is pretty much "THE" standard OS for the Pi, so that's what I will concentrate on.
Next:
- test the API
- add a serial wrapper around it
- write C library for the Pi that exposes the RoboPi API
I based the API on Wiring/Arduino, however I integrated the Servo library directly and made some changes to it; I did not like the idea of having to create a Servo object for each servo, attaching etc.
KISS principle at work
I am thinking of adding a simple checksum to the serial wrapper around the API in order to avoid the (very unlikely) comm errors.
Thanks,
Dave
http://forums.parallax.com/showthread.php/153275-Propeller-add-on-for-Raspberry-Pi-RoboPi..-the-most-advanced-robot-controller-for-Pi?p=1241246&viewfull=1#post1241246
I actually have a SD/uSD 10 pin module for my boards (including RoboPi); Sapieha did a nice job as usual to lay it out.
It's a 10 pin module, has a full size SD card socket on one side, and a uSD socket on the other.
(old photo showing a couple of SD/uSD's plugged into the unreleased qsBridge)
Unfortunately the SD card socket needs to be glued on (crazy or hot glue), as the mounting solder pads from the bulk shipment of connectors did not line up with three of the four PCB pads for them :-(
If you want, I'll see if I can find some of my 10 pin SD/uSD modules. I have uSD connectors for it, and I can dig up the Digikey or Mouser part number for the expensive SD connector should fit perfectly - I also have the connectors that need a bit of glue.
If you are OK with the gluing, let's say $5 for the kit (with both SD and uSD connectors, needs a bit of glue) - assuming I find them, I could add them to your order as I have not shipped it yet.
FYI,
http://www.mikronauts.com/proto/minipro/
was made for prototyping 10 pin modules.
Can't find SD/uSD PCB's. Spent an hour looking.
Will look more tomorrow.
- digital output works (P0..P23)
- digital input works (P0..P23)
- pwm output works (P0..P23)
- servo output works (P0..P23)
- analong input works (AIN0-AIN7)
Next:
- clean API up
- add serial packet handling
- write C library for Raspberry Pi that communicates with RoboPi using the serial port
- document API
(and continue looking for SD/uSD pcb's)
The RoboPi Build Manual is now available at
http://www.mikronauts.com/raspberry-pi/robopi/
towards the end of the page.
The Spin RoboPi API will be available shortly; it is tested, I just have to clean it up a bit and post it.
I will also be posting soon (planned for this week):
- Raspbian, SimpleIDE etc installation instructions
- RoboPiObj.spin
- RoboPiLib.c (for the Raspberry Pi)
- RoboPiDiag.spin
- RoboPiDemo.spin (stand-alone Prop version)
- RoboPiDemo.C (Pi version)
Bill
I am really excited to try this kit to combine the excellent IO of the prop with a unix board I can use for image processing or more complex navigation.
Please keep us updated with your progress... I for one would love to hear what people are doing with RoboPi.
I am plugging away at the packet wrapper for the RoboPi API... should be usable RSN!
- Packetized, error checked, serial I/O established between Prop and Linux via GetPacket() PutPacket() functions at both ends
- started wrapping RoboPiObj.spin methods in packet wrappers
- expect all verified working RoboPiObj methods to have equivalent RoboPiLib.c wrappers functional tomorrow, some working already
Question
- Should I supply a downloadable robopi.eeprom with a propeller-load executable for RoboPi so Pi users don't have to compile the RoboPi.spin packet handler, and RoboPiObj.spin it includes?
Something that just works, is always a good idea - useful for separate verify of pathways & HW from Tool chains.
Also good in case someone suspects they have Zapped some part of the system.
I'll make the eeprom image & loader zip
- 80% of 'RoboPiLib' is tested and functions 100% correctly
- some cleanup and I can publish it!
RoboPiObj / RoboPiLib API looks a lot like Wiring / Arduino, with a built-in servo and PWM handling (similar to, but simpler than Arduino servo library).
RoboPiLib - Pi side, uses /dev/ttyAMA0 to issue commands to RoboPi
RoboPiObj - Propeller object
RoboPi.spin - wrapper around RoboPiObj, implements serial communications layer, and serial command handling
FYI,
RoboPiLib (using /dev/ttyUSB0 etc) works just fine on Ubuntu on x86 boxes as well
I have a version of the loader that is adapted to work with the Raspberry Pi UART on the GPIO header and use a GPIO to wiggle the reset.
I would post it but I have not had a chance to test it.
Sounds like that is something I should do ASAP.
It is a stand alone replacement for the loader in SimpleIDE.
In theory this should also work on the Beagle Bone with very slight modification.
I've uploaded a pdf documenting the RoboPiObj API to the RoboPi product page at
http://www.mikronauts.com/raspberry-pi/robopi/
(towards the bottom of the page)
As you might notice, it is quite Wiring/Arduino like, and it integrates the equivalent of the Servo library.
Do you guys think that should I keep servoAttach(pin) and servoDetach(pin)?
After thinking about it, they seem totally superflous, as they are exactly equivalent to
pinMode(pin,SERVO) and
pinMode(pin,INPUT)
Going with the"Keep Is Simple" philosophy, why give me two ways to do the same thing. If you have the servo wrappers, then they should add value to the pinMode rather than just wrap it.
{This statement is made not having looked at your library yet, just on basic principles}
If people haven't built a lot, they may forget those things along with how IC sockets and ICs go (you can tell that from your great pictures).
I'll get rid of servoAttach() and servoDetach()
I will also add notes about the orientation of electrolytic caps and IC sockets to the next revision of the manual.
It was one of those things that was hard wired to me and I did not even think about others not knowing it! My bad.
(I am spending time with family today, but sneaking in some work on my new linux box in the living room... but alas, I can't sneak off to my lab)
I did get the header file for my Raspberry Pi C library cleaned up, will post that tomorrow. It is basically identical to the Spin API.
http://www.raspberrypi.org/archives/6299
This is indeed amazing news. People have been complaining about the closed nature of the Raspi GPU for a long time. Only a week or two ago one of the Raspberry Pi foundation insiders, who also works for Broadcom, was explaining to me that this would never happen!
Still, even with this, there is a lot of closed source code in use between applying power to the Pi and having Linux loaded. I don't worry about it much. It's rather like all the closed source code in a PC BIOS that has to run before the Linux boot loader starts.
We live in hope of an opensource world where we have control of what the machines we own are doing. We are not there by a long chalk but progress is being made little by little.