Actually, I got the impression that bot is actually an Arduino based balancer. With a Pi added to run the vision stuff. Mind you, you can balance a bot like that with just transistors or op amps!
I've now got the vision system solving the mazes. Granted, depending on the maze it can take a very long time to find the path, so I'm keeping the resolution down at 80X60 at the moment.
To make the bot balance I am considering using an ActivityBot and removing the back roller ball, at least to start. In the future I may have to make a new chassis.
The CMU cam is neat.
At 70 dollars plus the price of a Propeller board that solution is as expensive as a Pi + camera module. Looks like about the same size to.
The Pi solution is a lot more flexible but the CMU cam is I guess a lot easier to work with in your application code.
The angst comes from this: Vision libraries for Windows are so common it's a constant tug to find some Windows solution. I think that's why running a Windows laptop with Eddie and a Kinect (with or without what's left of RDS) is still so compelling. People can just go out, write some very simple VB.NET code to connect up all these open source vision analysis filters, and go to town.
Yes. Much more powerful boards (than the RPi) are not that much more money, so why not leverage existing software solutions, even if it means an i7 onboard? That is exactly the strategy my nephew used on his autonomous multicopter that is part of his research in graduate school.
If you are going to spend 100's or 1000's of hours developing something spectacular, why be a piker when it comes to the platform? Perhaps that's why there aren't too many robotic examples that actually tap the RPi's capabilities.
Publison,
Sorry, I missed your post earlier.
Good old vacuum tube technology relied on heaters or "filaments" as we called them back in the mother land. Heaters warmed up the cathode and got the electrons flowing. Nothing worked without a heater.
Many times I thought about creating an avatar that was a heater. Usually an idea about something of a representation of a filament glowing hot.
Never occurred to me to just use the schematic symbol. Someone here suggested that (sorry I can't remember your name at this moment). Such a neat idea I just had to go for it.
That is indeed the 6L6 tube's pin out for it's heater.
Publison,
Sorry, I missed your post earlier.
Good old vacuum tube technology relied on heaters or "filaments" as we called them back in the mother land. Heaters warmed up the cathode and got the electrons flowing. Nothing worked without a heater.
Many times I thought about creating an avatar that was a heater. Usually an idea about something of a representation of a filament glowing hot.
Never occurred to me to just use the schematic symbol. Someone here suggested that (sorry I can't remember your name at this moment). Such a neat idea I just had to go for it.
That is indeed the 6L6 tube's pin out for it's heater.
Vacuum tubes were in my growing up years. Dad was an electrical engineer and we had everything electrical, down to Model T transformers to make Jacob's Ladders. He made me rewire a Shortwave Receiver to teach me in's and out's of high voltage. Big 19' rack rig. I received for 3 years.
70's stuff, I miss it.
I'm not using a PI (and mine is not real compelling as yet) but I did decide to head down the embedded Linux road. It's not without pain. A fair amount really. But the primary reason I ended going this way was for access to more processor power. My Bot was working on the Propeller and I was pretty pleased but when it came time to do any serious math functions my loop rate fell below what I wanted. There were ways to get that faster but then I was really kind of pushing the Prop into things it was not designed to do. I was poking around looking for ways to do it faster and it was suggested that I try to use a Beagle or RPi instead. After considering it I felt that it made sense to switch that direction instead of having to rip out a more complex program later when I decided to do even more.
Gordon hits on a good point. Lots of the examples shoe-horn Linux into a role it frankly sucks at. Running around bit flipping on GPIO pins 'that's not my bag baby'. I gave up on the Pi pretty quick. IT can be made to do it but it was not going well for me. I then tried the BeagleBone Black. Ran into similar headaches. But it had something that looked promising. 2 Onboard 32bit RISK microcontrollers to handle real-time tasks with access to main memory. The hard part has been waiting for tools and good documentation/examples to come along. That's starting to happen but it's been years now of "that's just around the corner".
Linux's other problem is that it hates to allow specialized fast access. Everything needs to be abstracted and trying to develop to these specialized devices has been like trying to balance on beam that keeps being shoved around. The way you access hardware is changed, moved, changed, moved again, eliminated, and re-introduced quite frequently. Several times I have come back to something 3 months later, updated, and found my stuff is all broken now.
If you want to make a line follower or wall-avoider and that's all, the Linux platform is like welding pedals on a Harley and going on a bicycle race. Yeah it will do it, but you have to haul around 600lbs of Smile you don't really want or need to do it. I carry on because I have more in mind than just wandering, but it's slowed my project down a lot for sure
I'm having success using the Prop to control the GPIO and I just have the Pi send the Prop serial commands. I've actually got the USB going from the Pi straight to the ActivityBoard FTDI. I haven't yet tried sending data back from the Prop to the Pi but eventually that will probably be necessary eventually.
Comments
I've now got the vision system solving the mazes. Granted, depending on the maze it can take a very long time to find the path, so I'm keeping the resolution down at 80X60 at the moment.
To make the bot balance I am considering using an ActivityBot and removing the back roller ball, at least to start. In the future I may have to make a new chassis.
At 70 dollars plus the price of a Propeller board that solution is as expensive as a Pi + camera module. Looks like about the same size to.
The Pi solution is a lot more flexible but the CMU cam is I guess a lot easier to work with in your application code.
If you look at the pinout for a 6L6 tube, you will see the heater connections are on pins 2 and 7:
https://en.wikipedia.org/wiki/6L6
Heater ways runs at a cool 6.3 VAC.
Yes. Much more powerful boards (than the RPi) are not that much more money, so why not leverage existing software solutions, even if it means an i7 onboard? That is exactly the strategy my nephew used on his autonomous multicopter that is part of his research in graduate school.
If you are going to spend 100's or 1000's of hours developing something spectacular, why be a piker when it comes to the platform? Perhaps that's why there aren't too many robotic examples that actually tap the RPi's capabilities.
Sorry, I missed your post earlier.
Good old vacuum tube technology relied on heaters or "filaments" as we called them back in the mother land. Heaters warmed up the cathode and got the electrons flowing. Nothing worked without a heater.
Many times I thought about creating an avatar that was a heater. Usually an idea about something of a representation of a filament glowing hot.
Never occurred to me to just use the schematic symbol. Someone here suggested that (sorry I can't remember your name at this moment). Such a neat idea I just had to go for it.
That is indeed the 6L6 tube's pin out for it's heater.
Sorry, I missed your post earlier.
Good old vacuum tube technology relied on heaters or "filaments" as we called them back in the mother land. Heaters warmed up the cathode and got the electrons flowing. Nothing worked without a heater.
Many times I thought about creating an avatar that was a heater. Usually an idea about something of a representation of a filament glowing hot.
Never occurred to me to just use the schematic symbol. Someone here suggested that (sorry I can't remember your name at this moment). Such a neat idea I just had to go for it.
That is indeed the 6L6 tube's pin out for it's heater.
Vacuum tubes were in my growing up years. Dad was an electrical engineer and we had everything electrical, down to Model T transformers to make Jacob's Ladders. He made me rewire a Shortwave Receiver to teach me in's and out's of high voltage. Big 19' rack rig. I received for 3 years.
70's stuff, I miss it.
www.animarobotics.com/
Gordon hits on a good point. Lots of the examples shoe-horn Linux into a role it frankly sucks at. Running around bit flipping on GPIO pins 'that's not my bag baby'. I gave up on the Pi pretty quick. IT can be made to do it but it was not going well for me. I then tried the BeagleBone Black. Ran into similar headaches. But it had something that looked promising. 2 Onboard 32bit RISK microcontrollers to handle real-time tasks with access to main memory. The hard part has been waiting for tools and good documentation/examples to come along. That's starting to happen but it's been years now of "that's just around the corner".
Linux's other problem is that it hates to allow specialized fast access. Everything needs to be abstracted and trying to develop to these specialized devices has been like trying to balance on beam that keeps being shoved around. The way you access hardware is changed, moved, changed, moved again, eliminated, and re-introduced quite frequently. Several times I have come back to something 3 months later, updated, and found my stuff is all broken now.
If you want to make a line follower or wall-avoider and that's all, the Linux platform is like welding pedals on a Harley and going on a bicycle race. Yeah it will do it, but you have to haul around 600lbs of Smile you don't really want or need to do it. I carry on because I have more in mind than just wandering, but it's slowed my project down a lot for sure