[Zagan] Englander, you might want to pick up a book on basic electronics and then follow that with one on digital electronics. If you go with mostly pre-built boards, the main thing you need to know is how to interface these boards together. Include interfacing various sensors to your electronics on that list, too.
You don't have to be an expert in electronics, but you will need to know about things such as voltage and current requirements and limits of a given device. You'll also need to know about "sourcing" and "sinking" outputs and inputs. For the most part, you can follow the example applications provided by the manufacturer of a given device as a guide, but knowing the "why" of such designs will help.
I use FreeBSD Unix for development - Linux works great too. Also, AVR-GCC works on Windows. I understand that MacOS X support is present as well. Building AVR-GCC on Unix is near trivial - just unpack, run the configure script specifying the target, and build.
If using FreeBSD, it is a 'port', so it is literally as simple as the following, assuming you have an internet connection:
# install the GNU GCC C compiler target for the AVR % cd /usr/ports/devel/avr-gcc && make install
# install the AVRDUDE AVR programmer - for download flash to the AVR % cd /usr/ports/devel/avrdude && make install # install
That's it. At that point, you have everything you need for a robust development environment. Other tools are available, of course, like a simulator, debugger, etc. You do need a programmer which can be as simple as a cable connecting the parallel port of your PC to the ISP programming header. That's what AVRDUDE is used for - to download the code compiled with AVR-GCC to the target platform. It can talk to most parallel port programmers like this simple one, among others:
formatting link
Yep - I ship worldwide. Shipping outside of the US and Canada is $12, flat rate.
Cheers,
-Brian
-- Brian Dean, snipped-for-privacy@bdmicro.com BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
Though I generally use my JStik, which is much faster and has ethernet (something I never thought I'd use in a robot, until somebody suggested an ethernet-wifi bridge).
I like the ITX-Mini also, but I can't afford one yet. :(
Well, I'm working on building an i/o board that works via the USB port. I just got my USB converter today, so I may have something later this month, if this project jumps to the top of my list. :)
Yes, there are other solutions out there, but they don't work the way
We're developing and soon (early next year) will releasing a robotic-targeted version of our SIMM-Sys CPU card
formatting link
The differences from what currently is on our website are:
- 256kB RAM
- 66MHz operation
- Slightly different pinout with a standard .100 dual-line header (like the ones on HDDs)
Since it's an ARM based device, it can be programmed in C/C++ with GCC and other development tools, and we have plans to add support for other GCC-supported languages, like Pascal, ADA and Java.
[Zagan] I have a recommendation for basic electronics, but I can't remember the name of it or who wrote it to save my life. I used this textbook in an engineering course I took many years ago in electronics engineering. Since I can't remember the book, you should search
formatting link
using the terms "basic electronics". Most any book on basic electronics should fullfil your needs.
For digital electronics, I'd suggest "Digital Electronics" by William Kleitz.
If you can afford it, you might want to take one of the "distance education" courses offered by various companies. Try this link:
formatting link
As far as "sourcing" and "sinking" goes. think of sourcing as supplying a positive voltage (digital 1, assuming positive logic) and sinking as grounding (pulling the connection to ground or logical 0). The thing to remember is that "sourcing" outputs must be connected to "sinking" inputs and vice versa. However, some microcontroller outputs/inputs will both sink and source depending on the state of the terminal. If it sinks, then it wants to pull whatever is connected to it to ground (at or near 0 volts). If it sources, it wants to pull whatever is connected to it to positive (typically 5 volts with TTL logic). This is probably clear as mud, but once you get into it, it's really simple.
Please feel free to ask additional questions if you have any. I will try to answer to the best of my knowledge.
I'd consider some basic robotics texts and books. The first book that I recommend to beginners in robotics is: "Vehicles, Experiments in Synthetic Psychology" by Valentino Braitenberg This is an easy book to read and offers you insight into beginning AI thoughts and robotic "action blocks". It's even cheap on Amazon.
First book on digital electronics should be: "The TTL Cookbook" by Don Lancaster. I've worn one copy out and am on the second one.
From here on things diverge depending upon your inclinations...
have fun, DLC
: :> [Zagan] :> Englander, you might want to pick up a book on basic electronics and :> then follow that with one on digital electronics.
: What books do you recommend?
: I've got a basic electric/electronic/chip/component knowledge but no : circuit building experience.
: i am experienced in c++ and basic A2D stuff
: Sink and source i/o is something I was wondering about (did some : programming ge-fanuc and siemens plc's a while ago)
Yeah, thanks, If you read some of my other posts on this thread, I have come to the conclusion its a many moduled problem...
the control module and the decision making / long term memory / brain module being two main ones
in my opinion, memory is very important to an "intelligent" system to perform informed/learnt decision making (and having plenty of space for video capture...) others have other opinions no doubt it is some combination.
I reckon controller plus nano-itx is what I require.
as I said, space... its a trade off. In a heavyweight securitybot I think a mini-itx plus controller would be OK. I havent got space in the house for a heavyweight so I need to start making tradeoffs. I understand that.
The simplicity of writing familiar windows (PC BIOS) based code is attractive, raher than having to learn a new system and also have to make program sacrifices due to memory/storage shortage problems so I think controller plus nano-itx (hopefully there will be an rs232 header on the production boards...) seems a good option to me, just need to play some with controller options first.
Your example about brain size and survival is at one extreme of the scale where at the other end you have the dinosaur with huge body small brain and the neanderthal with smallish body largeish brain.. which survived in the closest to original state? (OK... cro magnon blahblahblah missing link blahblahblah, but you get my point I hope)
Survival.... well obviously in the bot world thats how much power-time you have, versus how much strength/armour/avoidance skill/ and offensive weaponry you carry. In a close to powerpoint docking station environment for a companion/securitybot I think you will get enough powertime for survival strategies. For a real military field robot, you (or I...) might want to think again about power requirements....
Personally I reckon big brain capacity small size (nano-itx) (high brain density I guess) will help any "real" robot "survive" with minimum programming effort for myself.
Also I am not building a robot to "survive" in any challenge, but rather to be the bees knees toy, if I want a tune playing, the robot can wireless network link into wherever and play whatever.... etc.
but your point about mini-itx being a poor controller was already accepted by myself, and after lots of input from the helpful people here, yourself included, I think the first hurdle I need to jump is which controller....
Video is extremely far removed from vision. Only a few systems come close to bridging the gap. And yes, they tend to use PC sized systems to process the data. Evolution springs to mind.
attractive, raher than having to learn a new system and also have
I hear this being your main driving concern.
I think you may be trivializing how much programming can be done in a give piece of memory. True, a meg isn't much memory anymore in a PC sized system, and the OOPIC and Basic Stamps often run into memory walls, but newer systems with larger memories, 32K, 64K or 128K take a very great deal of programming to fill up.
For instance, I've been doing robot interfaces on our IsoPod(TM) for a year and a half. Just in the past couple months, I've finally gotten enough program requirements to completely utilize the whole processors speed (2 CH PID, Odometry, Navigation, Ultrasonic Sonar ranging, Several Sharp sensors, AND half a dozen motion profiled RC Servos). But to date, I've never hit the top of the 64KB Flash memory available, even with the IsoMax(TM) language /operating system taking up a major part of the space.
I used survival, but what I most wanted to convey was suitability.
There you go. Suitable hardware for suitable tasks.
I'm curious as to how you arrive at this assumption.
The Mini-ITX platform is available now.
The Nano-ITX platform isn't. Also, the nano-itx has now additional features, though it is *said* to require less power than the Mini-ITX.
The Mini-ITX is around 7" by 7", which should fit on any bot that would fit in a house.
This is the direction I'm tending towards. I'm also planning on designing a USB I/O board (I got my eval board yesterday so I can start experimenting with it).
USB is important, because it doesn't look like the Nano-ITX platform will have serial ports. Also USB is *much* faster than the traditional serial ports.
The problem isn't always programming space, but variable storage. For example, how big a neural network can a ServoPod support?
I'm in the process of designing a neural network that will have
25 processing elements in the first layer, each connected to over
100 inputs. That's a *lot* of weigths. And this will only be the first iteration of the design.
Eventually this layer will be expanded and networked to other such maps with various feedback.
This is one of the reasons I like hardware with a *lot* of RAM.
well... I'm still at concept - no commitment stage
A program needs to be optimised to fit in small storage space - you have to do more work.
mini-itx - yes cool, but 7x7 (18x18) quite big in small house when you think wheelbase must be about that for stable platform. (plenty of objects to negotiate, so small size = fits in smaller passageway)
Any controller only based solution requires more effort to provide a complex solution. (and also no really useful consumer i/o ports (pci and USB)
mini-itx (slightly too big for my idea, though maybe not) and nano-itx provide all the useful ports (sound, video, usb, rs232 (hopefully on some nano-itx) lan) and I know how to program windows (and linux a bit)
ok.. survival.... whats your budget... whats the track....
I have found robotics to be an evolutionary process, and where you end is often vary far from where you start. Short of going to a multi $1000 dollar PC/104 based PC, you are going to have to go modular/distributed, and kind of string things out.
It also depends on whether you are a hardware/software/both sort of person, and base your goals from there. If you don't mind messing with hardware, and you have the resources, build it yourself. I hate doing hardware, and like to let someone else layout the 8 layer boards. This frees me to do other things like software, which I hate doing too. For me, it's in the system, and the mechanism. This is why I like the IsoPod, because the sheer number of hardware controlled functions. This frees you up to do other things, but any microcontroller has some degree of functionality, and it is a matter of choosing a path that leads you down a particular path.
For me, The IsoPod is a natural.
1) I have programmind in FORTH for 20+ years.
2) The software is easier, because of all the register based functionality.
3) I design simple 2-4 layer boards that the IsoPod that contain the specific functionality that I need to add.
4) There are several members of the family, with different size footprints and capabilities.
My second choice is the BASICX24 since it is reasonably fast, and simple enough to quickly play around with.
PC/104 was neat, because there was always, or most always a board(s) that did what I needed.
Find a chip family, or system on a board that liiks like a good match. Play with LEDs, and A/D converters, then D/A converters, PWM, Motor controls.
As far as the PC side of things, I am not terribly excited about the ITX things, but I usually go small and lightweight, and a micro-computer is more than I want to deal with.
I have to imagine that the IsoPodX would do what you need, but it comes down to whether you want to get into microcontrollers, microcomputers, or both. If you are getting into high speed image processing, you may want something with a PCI bus to handle DMA coprocessors or some such.
What are the memory requirements of the ANN you are designing? What specificly are the inputs? What are the speed requirements?
If you plan on having a vision based system, then you are prolly talking over the capabilities of the IsoPod, at least for any significant amount of pixels.
Sure, the conversion of video into usable/processable data = big jobs (but very interesting work...) my idea was more video capture of suitable events for human viewing which requires ports and memory/storage
well why waste valuable time....
no, given a good command set, a lot can be done with small memory (RISC = more program memory required for a task...)
but there is no denying that 1hr video footage (bitage?) at 720x576 at high/good quality compression = more memory than any controler can provide... (let alone 10hrs video footage...)
absolutely, horses for courses...
my lack of knowledge is with controllers and their command sets and features, wish i had enough cash to get one of each and compare them all myself...
Oh, I don't know. NN aren't so much my thing. I favor the State Machine approach to things. So I don't know how much RAM per node, etc., NN's take.
Anyway the ServoPod(TM) has 8KB (4K x 16) of Data Ram.
The IsoPodX(TM) has 64Kx16 Program Ram & 64Kx16 Data Ram -or- 32Kx16 Program Flash + 32Kx16 Program Ram & 64Kx16 Data Ram according to our web page. So I guess that's 128KBytes you could work with.
State machines and reactive programming do pretty similar things.
And I like them for the basics of robotic behavior.
However, for something a bit closer to cognition, I like neural networks.
A single artificial neuron can eat this much RAM for breakfast. I would estimate a more normal artificial neuron would use about 1/2 KB of RAM.
I hadn't heard of the IsoPodX. I'll have to look into it. I've always liked Forth. Around 20 years ago I implemented varients of Forth on several different machines.
I think I'm going with a a PC based architecture. I will either do this directly or by WiFi link, depending on the size of my budget.
Yes. However, the Nano-ITX and Mini-ITX have the same storage capacities.
I am planning on about a 12"-20" width, which fits in the smallest place needed. You can build a fairly simple bot with a 12" wheel-base which will fit pretty much everything you need.
I think they've dropped the rs232 on the Nano-ITX boards.
I'm working on the budget. The board I'll eventually use depends on what my budget is when I get get the funds. :)
For now I'm using my JStick and some auxiliary stuff, including a WiFi link to my Linux or Windows box.
Nah. There are already all sorts of converters that do that.
I want a real I/O board optimized for my use which will do what I need.
My first board planned is something that connects a JStamp to multiple small imagers, combines the data, and then sends it over to the main computer via USB. I'm hoping to be able to support about 10 16x16 imagers.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.