NOOB questions about propeller
bensmail
Posts: 3
I'm looking into making a robot. I have been collecting parts like the PING and say-it module. I want to make a robot that will avoid obstacles, follow people, respond to voice commands, and talk.
I've used the basic stamp but never really looked into the propellar. There are a lot of choices.
Can I use all the sensor modules with the propellar easily?
I was thinking about getting an MP3 player circuit for the voice but It seems like the propellar may be able to do this on it's own? Is it somewhat easy getting the propellar to talk either text-to-speech or playing 100+ audio files?
Which propellar chip/board should I be looking at?
Thanks for helping point me in the right direction.
I've used the basic stamp but never really looked into the propellar. There are a lot of choices.
Can I use all the sensor modules with the propellar easily?
I was thinking about getting an MP3 player circuit for the voice but It seems like the propellar may be able to do this on it's own? Is it somewhat easy getting the propellar to talk either text-to-speech or playing 100+ audio files?
Which propellar chip/board should I be looking at?
Thanks for helping point me in the right direction.
Comments
Look at this. --
RoboProp: Mikronauts Advanced Robot Controller
welcome to the propeller-forum.
You can interface all the sensors. Some of the sensors are satisfied with 3.3V as the propeller itself. Then you can connect them directly.
If the sensors needs to have 5V you need current-limiting resistors of 2 kOhm between the 5V-device and the propeller-IO-Pins.
Read this thread http://forums.parallax.com/showthread.php?85474-How-to-safely-interface-a-5v-signal-to-the-propeller-See-Post-Reply-104&p=585920
posting #4 is from Chip Gracey the developer of the propeller-chip.
Some propeller-heads are working on text-to-speach. But the voice is hard to understand yet.
Some people work on voice-recognition. Don't expect the abilities of Dragon-speak in an IPhone.
20 MIPS per cog and 32kB RAM is pretty small for voice-recognition. If voice-recognition is a key-feature for you I recommend switching to a MiniITX-PC.motherboard.
What's possible until now is recognising 5 to10 words if they really sound different
keep the questions coming
best regards
Stefan
For the MP3 functionality I'd recommend using a module like Daisy or Rogue Robotics uMP3. The Propeller can play WAV sounds but if you ask it to do the heavy lifting for playing MP3's you won't have much resources left for anything else.
Well, I'm looking at $50ish for a propellar board and $50ish for MP3 Trigger from sparkfun.
Would I be able to have the propellar play audio files (from an SD card) when it's not doing anything else or does just the ability to play audio take up too many resources?
I'm considering just using 1 or 2 BS2p chips I already have to save the $50... but I have no experience with larger complicated stamp projects or propellar of any kind. Would it be a huge advantage using a propellar over 2 BS2p?
so to say the propeller is a 8-core-chip (meant in the way like dual-core or quad-core-processors for PCs)
Playing WAV-files from an SD-card is doable with 1 cog. Meaning you have 7 cogs (cog=core=32bit processor) left.
1 cog is needed for your main program so netto 6 left over to do other things.
The WAV-fie format is uncompressed digital music-data. MP3 is highly compressed musical data that needs to be uncompressed to sound like music
This uncompressing needs a lot of calculation-power.
You can hook-up 2GB SD-cards to the propeller. So the WAV-files have to fit into this.
As you are building a robot and not a hifi-system I guess a lower sample-rate maybe 22kHz (instead of CD-quality 44,1kHz) and mono instead of stereo
will reduce the data to 1/4. Even lower sample-rates are possible and still sound quite good. especially for replaying voices.
IMO the advantages of the propeller over basic stamps are
higher execution-speed
32bits instead of 8 bit
bigger memory (don't know how much BS have) the propeller has 32kB
8 processors that can work independently from each other
example
reading in ping-sensor-data and at the same time
- turning the ping-sensor left/right with a servo
- driving two motors
- playing back a WAV-file
- send and receive at the same time serial data wireless over an Xbee
keep the questions coming
best regards
Stefan
P.S: Maybe I'm much too picky about that:
the name of the chip is propeller not propellar
I have a bit of experience with this having designed and coded the AP-16+ (Propeller-based WAV player). You need four cogs to play a WAV file cleanly:
* FSRW (file IO)
* Foreground buffer (reads data from file puts into local buffers)
* Background spooling (reads buffers, applies volume control, passes updated sample to StereoDuty
* StereoDuty (outputs sample to pins)
Some people leave out the last to save resources and then end up with mysterious noise in their audio. I went through this and consulted Chip Gracey, the creator of the Propeller; it was Chip who created StereoDuty to prevent noise in the audio (it has to do with IO pin interactions).
So... there you have it. If your application can run with just three support cogs (the main program needs a cog) then you can play audio without buying an external player. You'll need five (mono) or six (stereo) IO pins, plus a little support hardware. If you do a forums search you'll find a lot of information; many of us play WAV files with the Propeller.
Note: You may be wondering how Stephan can claim you need only one cog. If fact, you can, with these [impractical] restrictions:
* clip must be small; must fit into code space with rest of your app (in DAT section)
* no volume control
* could suffer from pin interaction noise issues.
So, you can play a WAV with one cog, but the restrictions make it impractical for normal applications.
In the end, if you only have one cog to spare and you want quality audio, use the Rogue Robotics uMP3. You can communicate with it using FullDuplexSerial. One caveat: the uMP3 reports its position while playing and this can quickly overrun your RX buffer; you need to manage this.
thank you very much for clearing up how much ressources are needed for playing WAV-files.
Maybe I should keep my mouth shut (=keep the hands off the keyboard) if I knew only less about a special theme.
I look up the OBEX almost every day to see what's new. There I saw Kyes KISS WAV Player Driver
The description says "running in one cog".
I thought "take this and you are done". Now that was a much too quick shot.
So to learn a little more about it (and still don't answer questions about WAV-file-playing until I have worked myself with it)
The description says includes changing volume. The WAV-Player-DACEngine comment says v1.3 - Added dither cog - 7/20/2011.
So if I count right this solution needs four cogs too.
Main-cog, FAT-engine, DAC-engine, dither-engine.
keep the correcting comments coming
best regards
Stefan
Any objections / suggestions?
I would like a lot of small sound files. Many will be short words that will play together. For example "seventy" and "four" put together to make "74"
Just to make sure... I will be able to select which file to play and put them together quickly to have word combinations like this sound half way decent, correct? I plan on using a robotic voice, text-to-speech to create all the sounds.
If you are open to using something pre-assembled, you might want to look at Hanno's TBot, its really polished and comes with 12blocks.
http://onerobot.org/products.html
Yes, you can do that. The great thing about WAVs is that there is no decompression required so they start very quickly. We EFX-TEK came out with the AP-16+ our customers loved that they could get it to go from one file to another with no perceptible delay. Your task is to create the logic that will play the files in order; you play the first, wait for it to end, lather, rinse, repeat as necessary.
I'm not buying it. You need an assembly cog for SD file access, plus at least one to split the samples and play them. Unless you want to be stuck doing nothing but playing audio (maybe his program does), then you need another cog (I use Spin) to read the file from the SD card and fill buffers. Then, of course, is the noise issue. Hmmm... we're back to four cogs!