Help Me Decide Which Microcontroller
Scope
Posts: 417
Hello,
I have been developing an idea for a "complex" robotic project and I have limited experience with Parallax microcontrollers.
A couple years ago, or so, I enjoyed using the Stamp and programming it was fairly easy and intuitive. When I began programming with the Propeller, frankly, I was overwhelmed, often felt lost, and frustrated and confused (like being married - ha).
Brief summary of my project:
2 systems, initially fully functioning as separate, independent entities, then converted to wireless communication (very important)
__System 1 --> involves a microcontroller, two tactile sensors, one light sensor and one stepper motor, eventually receiving signals from System 2
__System 2 --> involves a microcontroller, one light sensor, four stepper motors, eventually capable of sending information to System 1
My questions:
#1 --> Should I stick with the Stamp or bite the bullet and make myself learn the basics of programming so I can take advantage of the Propeller?
#2 --> Of these two microcontrollers, does the Propeller seem like the only one that would have enough processing power to accomplish the tasks at hand? (apologies if I haven't explained my project with enough details)
#3 --> Should I also be considering other microcontrollers? (I also have good experiences with the Arduino)
Plethora of thanky's,
Brad
I have been developing an idea for a "complex" robotic project and I have limited experience with Parallax microcontrollers.
A couple years ago, or so, I enjoyed using the Stamp and programming it was fairly easy and intuitive. When I began programming with the Propeller, frankly, I was overwhelmed, often felt lost, and frustrated and confused (like being married - ha).
Brief summary of my project:
2 systems, initially fully functioning as separate, independent entities, then converted to wireless communication (very important)
__System 1 --> involves a microcontroller, two tactile sensors, one light sensor and one stepper motor, eventually receiving signals from System 2
__System 2 --> involves a microcontroller, one light sensor, four stepper motors, eventually capable of sending information to System 1
My questions:
#1 --> Should I stick with the Stamp or bite the bullet and make myself learn the basics of programming so I can take advantage of the Propeller?
#2 --> Of these two microcontrollers, does the Propeller seem like the only one that would have enough processing power to accomplish the tasks at hand? (apologies if I haven't explained my project with enough details)
#3 --> Should I also be considering other microcontrollers? (I also have good experiences with the Arduino)
Plethora of thanky's,
Brad
Comments
You could certainly use some other microcontroller. An Arduino could do the job, so could a Propeller. Again, without more information about what the systems do other than manage the sensors and motors, it's impossible to tell for sure what microcontroller would be "best".
In situations like this, the primary basis for deciding depends on support ... what you're familiar with ... what kind of help you can get ... what kinds of resources are available on-line like libraries or other collections of examples of what you want to do.
I know you said you were overwhelmed, which is understandable as things are a little different in Propeller land, but at the end of the day Spin is no harder than any BASIC and it's educational and fun to get into Propeller assembly should you feel the need at some point. PASM is about the nicest assembly language I have ever used.
You will probably find you don't need to go to PASM though as there is a vast array of ready made drivers and objects in the OBEX repository just waiting for you to plug together into your finished project.
With the Prop and it'a 8 cores and lack of requirement for interrupts it is easy to put together a bunch of drivers for various sensors and actuators. You never have to worry how processing time used by one may upset the timing of another.
As a bonus of using the Prop you get all the good folks on the Propeller forum able and willing to help out with any questions.
As naturally occurs during early stages of concept development, I received another "epiphany" this morning as I was adding details to my sketchbook, thus realizing how to reduce the system into one, thus eliminating the need for a wireless interface. Woo hoo!!!
My gut feeling tells me I should probably "bite the bullet" and rejoin the Propeller heads. 50% of the purpose of this project is to help me obtain a job I'm seeking with a targeted potential employer. I feel the Propeller experience, even though I'd still a green horn after project completion, would be more appreciated than programming with the Stamp (I am not dissing the Stamp - love it).
Now, I'll roll up the sleeves and make this thing happen. I am a bit leery of publishing my progress because I know virtually everyone out there (especially at the Parallax forums) could accomplish this project better, faster, more efficiently, more professionally, blah, blah, blah. Regardless, I've been looking for a project like this for a very long time and I'm very excited about developing it, learning how to solve the inevitable and highly numerous problems, and creating something that's not only useful but will be the highest contributing artifact in my professional portfolio.
Thanks again,
Brad
Whichever processor you choose, don't be leery about publishing results. Everyone likes to see project progress and new ideas (or various implementations of old ideas) ...when you get anything actually DONE, you've got me beat on faster and more efficiently!!
You are aware that most companies that do MCU work have a 'Holy platform' ?
Switching platforms, is considered expensive and timeconsuming. And since much work is done in teams, it would mean having to train others to also use that MCU.
(Having ONE person know platform X while everyone else works on platform Y means that if that one person quits/is fired/base jumped without a chute, they're left with no one that can support the products made with platform X: That is why they often work in teams; so that there's someone else who also knows the product, not just to speed development)
If you want to show them a Propeller-based product, consider also showing them WHY you found the Propeller a good choice for the job, and explain its advantages.
'No interrupts' may sound scary to someone working with Intel MCUs.
'Concurrent execution of multiple event handlers' is full of buzz and not really a lie...
(Everyone associates 'event handler' with interrupts)
'Generates video using built-in registers' sounds like a lot of work setting up...
'Only requires X number of resistors to generate VGA' sounds like a great deal.
'Capable of driving X number of stepper motors with no external logic' is good...
(MOSFETs aren't necessarily logic. Same with transistor arrays.)
Showing that you CAN develop something with their chosen platform is also good.
Yes. I'm not sure what they use and, it's probably a very remote possibility that I'll even be considered for an upcoming opening - if an opening becomes available - with the small but very stable and ultra-cool company.
I'm guessing a potential employer might think that if someone can show a reasonable level of success using the Propeller, then it would seem likely to them that the same person could also be expected to learn another system without too much difficulty. Again, I'm just guessing, hoping for a miracle.
I was fortunate enough to be able to spend a couple more hours on developing this machine today during work. This project helps me realize the magnitude of useless gray matter I possess. Still, it's a very fun project so far.
Is this correct:
Propeller board --> Motor Controller --> Motor
And, I'm assuming I'll need to have a motor controller that can control four stepper motors - or two motor controller boards, each controlling 2 motors in a --> 2 + 2 motor controller boards configuration?
To get the project underway, I can start out with just two stepper motors - that would allow me to create ~80% of the finished product.
This system will also need an interface to control distance, speed, and angles of the device preferably via input using an LCD. I could do this of course by manually changing parameter values in the program but I want my son to use this machine so he can set it up, make changes, and get the results he's looking for, given a wide variety of applications.
I'm going to have to figure out so many things like the power of the stepper motors, the power supply, programming and tons of other stuff. It can be done - I will do this - watch me.
Thank you,
Brad
Sniff around and find out. They may have more than one.
#6 is correct, and someone who has at least used their 'Holy platform', will have more of an inside running.
I can stop by there tomorrow or Thursday after work and ask.
They're 100% SolidWorks and I'm taking the S/W certification exam in two weeks (I used to teach Pro/E for advanced users).
Thanks again
'Teh 'Lax (Parallax) is not Propeller oriented, they're education oriented.
2 --> 4-Phase / 12 Volt Unipolar Stepper Motor #27964
2 --> Parallax (Futaba) Continuous Rotation Servo #900-00008
1 --> Propeller Servo Controller USB #28830
2 --> ULN2803A Darlington Array #500-00005
I'm guessing I could use the signal pins on the Propeller Servo Control board to send to the ULN2803A driver - yes?
I doubt I'll use these servos for this project and I realize the ULN2803A can handle two motors so I would only need one but having spares can be a good thing.
Thank you,
Brad
Will do - thanks MG.
And, getting a few more details worked out . . .
We're skipping the BS2 and going straight to Propeller. Here's why I can do it at this point: learn.parallax.com. There's a huge load of material finding its way to this web site which makes the Propeller simply easy to use. Our Education team has stuffed some of the "troublemaking" nuances into objects (WAITCNT, timing, I/O control) and it looks and feels like something else at this point. Something friendly, accommodating and easy.
How joyful is it to cast a cog off with managing servos, or to simply have a sensor value available in your top program? It's all just a matter of high-level integration for guys like you and me!
So come on over, it's about time. Certain things might frustrate you, like string handling, ==, := and forced indentation. But let's face it, is this any more difficult than eating tofu and spinach for lunch? Not really. Just do it once and it'll taste better next time.
Ken Gracey
Ironic, your words, as I offer my students similar information & encouragement.
You should run for President of the Universe - I'd eagerly vote for you!
--> And . . . I began cutting and assembling parts for my Proof of Concept prototype last night. Never fails, wife goes from wondering if I'm a bit off to having a secure grasp I'm toast.
Regards
Richard
I can't wait to see what this turns into.
Your drawings are fascinating and spark the imagination!
Thanks
LINK to project thread --> http://forums.parallax.com/showthread.php?140291-A-Three-Axis-Camera-Position-Tower&p=1100467#post1100467
---> AND ---> I added a blog to provide the summary of this build
Richard, I think it's the best choice. I've got three 1:20 classes through our first session today and it's going well. There's a certain amount of abstraction brought by multicore, but at great benefits of being able to accomplish things. Simply starting a sensor object and having access to the data is a huge boost to productivity. The benefit is the high-level stuff is easy to understand, but the drawback is that they won't really appreciate what's underneath the various objects that make it easy. For example, the students want to load and run wav files on their Propeller Boe-Bot. I can show them how to do this and they can make it work, but there's no way we'll get into the PWM audio output. In some way this is okay - those students who thirst for the real details (and quick reward) will get to it and can be tasked to do so, and along the way the ease of use means nobody with a primary interest of simply experiencing it is left out.
I think the fit of the Propeller in robotics is appropriate since the subject matter is becoming it's own elective, no longer an after school club or something for gifted students. This means it needs to be easy. And I think it is easy enough.
Let me know how it goes.
And Scope, I'd like to know more about your work as well in the schools.
Ken Gracey
Unfortunately, the new curricula won't be in place until Fall of 2013. The GREAT news is that one of the six new courses deals exclusively with robotics --> (wish there was a "link" button) http://archives.gadoe.org/DMGetDocument.aspx/Robotics%20and%20Automated%20Systems.pdf?p=6CC6799F8C1371F6EB2BCB0D004C3F0AEA479399C13681CEF29597178CAC3EED&Type=D
I would target the Prop as the 'main iron' but also include some small microcontroller, that can cover some areas the Prop does not do so well, like ADC.
Ideal part would be 12b ADC, Wide Vcc (1.8-5.5V), Student friendly package, and a real Debug Ability.
Arduino comes up a little short on ADC precision, and real Debug, but it is widely documented.
MSP430 are cheap, but lack a 5V model, and cheapest ones are 10b ADCs only
SiLabs C8051F have good debug, and some are wide Vcc and 12b ADC, but DIP packages are deprecated, but they do have cheap
ToolStick Daughter boards. So you could side step the package issue a little.
Zilog Z51F are moderate prices, good ADC and Wide Vcc, with Debug, but packages are SMD only. Debug prices seem to be falling.
Their 1mm pitch SSOP10 (SO8 size) may (just?) be student solderable ?
Microchip have a Microstick that is a tolerable price, but the parts are only 3V, and not much cheaper than a Prop.