PDA

View Full Version : Microprocessor Control



alsinaj
06-19-2010, 01:20 PM
Greetings! I would like to get in touch with someone who has up-to-date microprocessor skills. The product I am developing will give craftsmen in a traditional mechanical art the ability to measure what they are doing, instead of relying only on "feel."

The project involves 1) a small robot arm that moves a sensor through a data acquisition cycle and stores the data from ~100 such cycles in memory; and 2) a small portable display that displays the data for each cycle as an X-Y graph. I would like the display to have the ability to animate a sequence of graphs, enabling the user to quickly pick out any differences among them.

My microprocessor skills date from the '80s and early '90s. I need help to select hardware and software components that will 1) do the job, and 2) be within my ability to learn how to develop the software. Alternatively, I would be glad to work in tandem with a programmer/systems designer. This will be a zero-pressure, fun project of limited scope.

Suggestions? Volunteers?

Dragons_fire
06-19-2010, 01:22 PM
Where are you located? i do some basic hobby stuff that may be able to do what you want..

Black_Moons
06-19-2010, 01:41 PM
If you wish to do graphs and LCD display, id definately recommend something bigger then the typical avr/pic hobbiest microcontroller. Maybe looking into the ARM line or similar higher end UC's that are closer to single board computers then hobbiest microcontrollers.

While it might be doable on an avr/pic, it would require MUCH optimisation IMO.

CountZero
06-19-2010, 01:57 PM
While I prefer AVR's myself and one could do the job without too much difficulty, I would too recommend looking in to ARM's. The main reason being the display which possibly will require a bit of more memory than found in the smaller AVR's and possibly faster update of the display. Price wise the difference between a higher end AVR and lower end ARM is not great and the development tool costs can be about equal too (close to 0 :)) the main difference is that ARM's are a bit more complex to get started with but you can find lots of help for that too.

alsinaj
06-19-2010, 02:34 PM
Dragons, I'm located in the Adirondacks near Lake Placid, NY.

ldn
06-19-2010, 02:42 PM
I was in your position in 2002, with older digital skills. Then I found myself in charge of updating a modern FPGA based design and had to get up to speed in a hurry. Not much important has changed. You've got ROHS of course, and denser footprints. BGA's look intimidating but are really no big deal if you know how to deal with them. Discrete processors come with a lot more built in peripherals. FPGA's and CPLD's are much more mainstream than they used to be. A little time spent learning VHDL can really open up a lot of possibilities.

Do you have a schematic/board design program already? If not, Eagle is cheap and quite capable, if a little clunky. Their auto-router works pretty well too.

I like to use Xilinx and Microblaze for this sort of thing. You can run the microblaze up to 100MHz and the chips aren't too expensive. Also you get the benefit being able to make up whatever extra logic you might need in the FPGA fabric. Look at the Spartan 3AN series -- they have integrated flash which keeps the cost down. I also like the fact that is relatively easy to add external RAM to a microblaze, something that is frequently an issue with the average highly integrated microcontroller.

I find that even though FPGA's look more expensive ($17 I think for a Spartan XC3S200AN), they can come out being cheaper in the final design since you don't need as many support chips. Although you'll probably need
a 6 layer board if you want to use a significant portion of the I/O, so that's a drawback.

Due to the need to support a graphical (presumably color) display, an AVR32 is probably not going to work. I second looking into the ARM, although I don't personally have any experience with them.

Also I just went through the prototyping process with the CrystalFontz 3.5" TFT display and the Newhaven 4.5" TFT display, if you are interested in either of those displays I'd be happy to share info.

Good luck with your project.

Paul Alciatore
06-19-2010, 03:27 PM
I don't have the skill level you are talking about, but I also doubt that the PIC type devices are probably too limited for your project. Even if you managed to get it done with them, sooner or later you will want to expand it and you will probably be up against a hard limit.

Probably what you want is one of the single board computers. They work a lot like a standard PC, but are made for dedicated systems like this. Keyboard, mouse, and monitor are all optional and can be used for development and if not needed, removed for the actual systems.

This would allow any programming language and any programmer who would be able to write programs for a standard PC to work on your project. One caution here, some of them can be VERY dedicated to their way of doing things and they may be quite hard to work with if you want specific features to work specific ways. Ask me how I know.

RTPBurnsville
06-19-2010, 03:44 PM
Take a look at the Cortex M3 controllers available from a variety of vendors. All use the same core but different I/O configurations. I agree with those above that the PIC, AVR type parts are not what you need.

If you want to go FPGA look at the Altera Cyclone III parts which are nice. You can also get a processor core, LCD controller, and many other things all in one part.

Most manufacturers have demo boards available to get you up and running in short order. I have a Altera NIOS demo board for example which sounds like it would do everything you are asking.

I do this type of stuff for a living, but currently have no spare time for additional projects.

Robert

MCS
06-19-2010, 05:07 PM
I would, especially in the early stages split the problem in two, the data aquisition module and the storage/display module it downloads to. The last one can be a pc, the first becomes suddenly very simple.

Once it works, you can consider integration of the two.

lazlo
06-19-2010, 05:59 PM
The project involves 1) a small robot arm that moves a sensor through a data acquisition cycle and stores the data from ~100 such cycles in memory; and 2) a small portable display that displays the data for each cycle as an X-Y graph. I would like the display to have the ability to animate a sequence of graphs, enabling the user to quickly pick out any differences among them.

Are the kinematics of the robot arm fixed, or is the motion calculated according to sensor feedback? If you're doing multi-axis kinematics and especially if you're talking about graphical displays, you're going to need a 32-bit microprocessor.

Black Moon's suggestion of an ARM development system is a good one. You can get an ARM9 or Cortex development system with WinCE or Embedded Linux.

lwalker
06-19-2010, 06:33 PM
I'd suggest you go in a slightly different direction.

I write software to control machinery in my day job and putz around with various microcontrollers in the home lab.

I think you'd be much, much, much better off if you got this thing running on a PC before worrying about miniaturization. The inverse kinematics and User Interface will probably be the hardest part of the project. Once it's working properly, then you'll have a much better idea of what kind of CPU horsepower is needed to get the job done easily (remember programmer time is expensive, silicon is cheap!) and you can decide what kind of microcontroller to port it to.

And I hope you have deep pockets, since even a cursory analysis of the project indicates that it's already into 5 figures at average software development rates.

arcs_n_sparks
06-19-2010, 10:48 PM
I think many are underestimating what one can do with the AVRs and PICs.

For example, this guy http://elm-chan.org/works/akilcd/report_e.html built a 128 point FFT audio analyzer driving a graphics display using an ATMEGA8. Scroll to the bottom and watch one of his 128 point FFTs in action on various audio inputs, which displays the input as well as the FFT results.

J Tiers
06-20-2010, 12:10 AM
There are AVRs and there are AVRs..... some are much more capable.

But, buy moving from the uP model to a DSP type processor, one gets a lot of benefits. A DSP is great for manipulating data, but it also works very well as a controller.

There are lots of good ones around. We use some in the TMS320 range, for motor control, basically custom VFDs for odd things such as 5 phase motors, etc. They have worked well, but we are looking to move on to a different type now.

What might take a VERY capable uP, can often be done in a low-end DSP.

RancherBill
06-20-2010, 01:41 AM
There's a lot of good ideas and suggestions already posted.

Processor sizing, development platform and sw tools are sort of clear in my mind, with your short description.

The data acquisition side is less clear to me. "Robotic arm" to me, means one of those Fanuc Robots. Your description is of a craftsman manual tool.

I watched a 'How It Is Made' and the guy was making a bell or something. He ran over the outside of it with a pantograph doomer and made a 'drawing'. He compared his paper with the 'master' for the tone the bell was supposed to produce. He went back to tweaking until it met spec.

What I am getting at is could a human operated 'arm' do the movement part of the process? Then it would just be a question of measuring the movements in the joints. The data acquisition part is the hard part of this project.

Then any software geek could do the display part. :eek: :D :)

lwalker
06-20-2010, 10:42 AM
I don't think people are underestimating their power: after all, the average AVR is faster than a mid-late 80's desktop computer and many of them have as much memory, all in a tiny package that fits on your thumbnail.
It's that unless you're making many thousands of something, in the end it's often cheaper to get a higher power processor than absolutely necessary in order to save on the development time.


I think many are underestimating what one can do with the AVRs and PICs.

For example, this guy http://elm-chan.org/works/akilcd/report_e.html built a 128 point FFT audio analyzer driving a graphics display using an ATMEGA8. Scroll to the bottom and watch one of his 128 point FFTs in action on various audio inputs, which displays the input as well as the FFT results.

lazlo
06-20-2010, 11:32 AM
I think many are underestimating what one can do with the AVRs and PICs.

The AVR and PIC's are 8-bit microcontrollers, running at 20Mhz. More importantly, they don't have floating-point units, that you would need for robotic kinematics.

AVR has a 32-bit family that does have floating-point units, but you're out of the hobby class development systems and into the mega-buck Embedded Systems and Digital Signal Processor price point.


For example, this guy http://elm-chan.org/works/akilcd/report_e.html built a 128 point FFT audio analyzer driving a graphics display using an ATMEGA8. Scroll to the bottom and watch one of his 128 point FFTs in action on various audio inputs, which displays the input as well as the FFT results.

Impressive build on an AVR, but it's running a very simple fixed-point FFT.

Greg Menke
06-20-2010, 11:34 AM
The microcontroller/fpga stuff is great, but if the problem is principally algorithmic, at low enough bandwidth where you don't need hardware assistance (coprocessors, DSP etc) then its hard to beat the efficiency of a desktop PC when it comes to code/debug/test. There are plenty of PCI cards to supply ADC, I/O, etc. A modern multi-ghz processor helps you get away with larger software inefficiencies, permitting substantial latitude in design/implementation.

BUT, don't use Windows if there are requirements for reasonably bounded latency (context switch or interrupt- control & sampling loops, input response etc)- it will cause a lot of trouble.

There are lots of small SBC's with a variety of processors capable of running Linux out of flash, for instance- so the final target needn't be a full desktop PC. But, not all of them have fpu's, so if you need floating point, make sure you're getting the right hardware- emulated fp can take a surprising amount of cpu time.

Gregm

lazlo
06-20-2010, 11:40 AM
There are lots of small SBC's with a variety of processors capable of running Linux out of flash, for instance

Like the ARM system Black Moons and I recommended on the first page :p ARM processors (which are used in most high-end cell phones, as well as the iPad), have very capable floating-point units, MMU's (for virtual memory), caches,... that a microcontroller doesn't have.

alsinaj
06-20-2010, 12:34 PM
Thanks for all your suggestions. Here's some more details.

No robot kinematics are needed. The arm just moves forward and back along one axis at a fixed speed. I probably shouldn't have called it a "robot arm" - sounded more complicated than it is.

Data acquisition is also not fancy - about 500 8-bit samples in 2 seconds. Total sample storage requirements would come out to about 50KB.

Transforming the samples into a format suitable for graphic display would require some work, but it's not time-critical. There's plenty of time for the processor to grind. The "graphs" are simple crooked lines on an X-Y grid. The size is fixed, so no scaling is necessary.

User interface will be just button presses. The graphics animation part would obviously be more demanding, but still simpler than the simplest video game. It would do just one thing - riffle through the graphs in sequence until the user presses "stop."

Dividing the tasks up between several small processors would make sense. I'm leaning toward hobby-oriented systems not because of cost but because the better ones have more dummy-friendly documentation. Professional products tend to assume that the user is a professional, which I'm not.

I'm tempted by something like the AVR/PIC Chameleon. It combines a 16-bit PIC with a Propeller, has built-in A/D and NTSC and VGA outputs, and adequate memory. Would that make sense?

Greg Menke
06-20-2010, 01:59 PM
If the goal is to mess around with a microcontroller, then sure- and you'll have the fun and games of coaxing the video controller into life and managing the display, which is a rewarding exercise but adds a lot of time to the project. If you want to get the axis control working quickly, then a PC w/ a I/O board, running Linux, is the quick and easy approach. You can do the coding and testing right on the target hardware, which is a HUGE advantage.

A multi-processor setup drastically increases the effort to get the system running- that tradeoff is up to you of course.

A plain old PC w/ a ADC/DAC/IO board will do the entire thing from a cpu standpoint. If you want to box it up later, then port your code from the Linux based PC to the Linux based ARM (or whatever) SBC down the road. Probably the only mods needed to make that work (if you choose your gui elements with some care) are to talk to the I/O differently since its probably an onboard resource vs a PCI board.

Greg

RancherBill
06-20-2010, 03:02 PM
No robot kinematics are needed. The arm just moves forward and back along one axis at a fixed speed. I probably shouldn't have called it a "robot arm" - sounded more complicated than it is.

Data acquisition is also not fancy - about 500 8-bit samples in 2 seconds. Total sample storage requirements would come out to about 50KB.

Darn, I wanted to see a Fanuc running on a pic processor:eek: :D

I am just trying to visualise the mechanism. I have an image of two old STRIPPED ink jet printers. Printer A is the X axis and Printer B is the Y axis and on the end of printer B is a stylus. Ink jets in my mind are pretty precise devices and they already have encoders that could give accurate position data.

I would guess the D/A program would be to start at HOME position and at selected X positions, read Y. That would get you out of any time problems relating to differences in speed of motion by different operators/motion.


There are probably shareware software driver/counters for the encoder chips. I would guess a lot of people ravish printers for parts.:D

J Tiers
06-20-2010, 03:59 PM
The AVR and PIC's are 8-bit microcontrollers, running at 20Mhz. More importantly, they don't have floating-point units, that you would need for robotic kinematics.

AVR has a 32-bit family that does have floating-point units, but you're out of the hobby class development systems and into the mega-buck Embedded Systems and Digital Signal Processor price point.



Impressive build on an AVR, but it's running a very simple fixed-point FFT.

Robert:

perhaps if you "and" those, yes...... although even the PIC seems to have some larger units.....

BUT..........

Go look and you will find that the AVR stuff goes up to 32 bit..... Ww only use the 16 bit. Perhaps you have not looked at them for a while.

I stand behind my suggestion of a DSP chip though...... they are MADE to do the math, although usually optimized for certain operations, and they make a heck of a controller.

Evan
06-20-2010, 06:02 PM
I think the product you need already exists at a reasonable price point too.

I will be ordering one before it is sold out.

http://ixian.ca/pics7/oscope.jpg


DS0201 is a pocket size digital storage oscilloscope fulfills basic electronic engineering requirements. It is base on ARMCortexTM-M3compatible 32 bit platform, equipped with 320*240 color display, SD card capability, USB connection, and chargeable batteries. Weighs only 60g! Portable Digital Oscilloscope DIY Kit provides waveform viewing, pocket size and over 2 hoursbatteryoperation. This DIY kit is a open source code. The Schematic, PCB layout and program code is free for re-design. It is ideal for production test, research, design and education.


All schematics and firmware are available here:

http://www.elechouse.com/elechouse/index.php?main_page=product_info&products_id=396

DX has the product here for $55

http://www.dealextreme.com/details.dx/sku.39750

lazlo
06-20-2010, 06:08 PM
That's pretty funny Evan -- that's a Chinese bootleg of someone's WinCE PDA (probably an HP iPaq).

Although the firmware is stated as "OpenSource" -- I can't find the link to the SourceForge repository, so I can't tell if it's a dedicated oscilloscope, or if you can run WinCE or Linux on it.

Edit: the firmware it ships with is a dedicated oscilloscope, but there's a Wiki with some basic developer tools for hacking it. No operating system though:

http://code.google.com/p/dsonano/wiki/DevelopersGuide

It's a better deal at SparkFun -- the Dealxtreme version doesn't ship with a battery or the scope probes. SparkFun sells the complete device for $99:

http://www.sparkfun.com/commerce/product_info.php?products_id=9625

I'm going to order one -- looks fun :)

Evan
06-20-2010, 06:21 PM
DX has the full kit with battery and probes for $76

http://www.dealextreme.com/details.dx/sku.39753

lazlo
06-20-2010, 06:26 PM
Cool, thanks Evan!

It's only a 1 Mhz Arm (most of the Arm developer's board you buy these days are 500 - 750 Mhz), but looks like it'll fun to hack. Just ordered one...

Evan
06-20-2010, 06:38 PM
Here is the firmware project page:

http://code.google.com/p/dsonano/

Black_Moons
06-20-2010, 07:00 PM
the reson I recommended ARM/etc over AVR/PIC isent because it could'nt be done.. in asm, on avr/pic, its because you have to be a very good coder to be able to pull stuff like that off, and have a LOT of time to spend optimising.

Evan
06-20-2010, 07:04 PM
I just ordered one too. This should be interesting to play with. It seems to have two undedicated I/O ports on the board plus other unused I/O available.

arcs_n_sparks
06-20-2010, 11:00 PM
It would seem that everyone is applying the same philosophy (or perhaps dogma is the better word) I have seen in "plugging the Gulf oil leak" thread to this OP's question.

I'm surprised someone hasn't mentioned Linux clusters.....

ikdor
06-21-2010, 07:13 PM
If you feel comfortable with the complexity of the ARM, I would definitely agree on the Dealextreme device. The ARM Cortex M3 inside would be my first choice if I had to learn microcontrollers right now. It might be hard to find help getting started with modifying this device though, but I haven't searched.
An alternative device with possibly more support is the Primer2 from STM
http://www.stm32circle.com/resources/stm32primer2.php
The screen has worse resolution however.

If you don't feel comfortable with the complexity of the ARM, I would suggest going the AVR way despite other claims. As your application doesn't require lightning speed it is well within the capabilities of even the 8bit architecture and the amount of support from other users to get you started is probably unrivalled.
The support forum can be found here: http://www.avrfreaks.net/ You'll be able to find tons of sample code there for driving all possible graphical displays.

I would advice against the FPGA and DSP route. These will require a longer learning curve and will delay happy results needlessly.

Enjoy,
Igor

Evan
06-21-2010, 07:51 PM
It might be hard to find help getting started with modifying this device though, but I haven't searched.


It's all at the link I posted.

DFMiller
06-21-2010, 09:20 PM
TI has some interesting demo boards out there. The have one Cortex board that ships with a 3axis stepper CNC controller. The app note shows a graphics touch panel attached. When I get back home it will get a close look. I was at an M3 training session a few weeks back at they did not have a demo board of that flavor to test drive. I have done many AVR designs but have started doing several M3 based projects. there areas several people have stated many inexpensive Linux based boards out there. I just got a seminar invite today for one that was less than $100.00 and it included a day training in the price. Many options out there now, with the demo boards you can do a lot without any hardware work and as others have stated the software is where the cost is so leverage as much as you can.
Dave

nheng
06-21-2010, 09:49 PM
Evan, one of our young software guys is a gadget collector and brought one of these in several months ago. He paid the $89 price. It is a nice looking little unit, very limited bw and other capabilities but still very cool and incredible for the price. Den

Evan
06-21-2010, 11:24 PM
I figure I can easily program it to display RPM, SFM and other details with a simple optical sensor as input. I am sure I will think of other applications too. It should also be easy to make it store audio at CD quality complete with a histogram display and an equalizer. A simple R2R ladder on an I/O port will give 8 bit playback for monitoring with almost no processor overhead.