So, my “PIC control board PCB” project has been so fun that I’m thinking of doing another PCB project.
But I haven’t decided what it would be yet, so I’m open to suggestions.
The parameters are:
I plan to use the ExpressPCB “miniboard” service, which means that it will be 3 boards, each 3.8 X 2.5 inches.
It will involve surface-mount parts (because I’ve never done that before).
I will probably want to design 2 or 3 smaller circuits for different things, and lay them all out to fit in 3.8 X 2.5, then cut them apart myself.
It’s best if it’s something that I can use 3 copies of, since that’s how many boards I’ll have.
Something involving a PIC would be cool…
One off-the-cuff idea would be a very small servo controller - one that does only 4 or 5 servos. Sorta like a “tiny SSC”.
Another idea is a self-contained telemetry transceiver, using those little 434 Mhz modules from SparkFun. It would include a PIC to provide a simple serial interface and such.
Well, there are other really cool micros out there that need a good carrier board and such. One is the Parallax Propeller chip. I so want to use this as the brain of my Walk 'N Roll bot when I start building it. I don’t like the Parallax support hardware for this chip at all and would rather see an Atom Bot Board style of board for it, perhaps a board with built in Bluetooth (maybe using that cool 3.3 chip from Sparkfun).
Having a Bluetooth link on a robot would make it insanely easy to see what it is doing while it is actually running around. Just point your favorite IDE at the com port for the Bluetooth adapter on your PC and there ya go after you pair it with the robot.
I think a board with a Propeller and a super PIC I/O processor would be VERY COOL, especially if it has Bluetooth also. The PIC could be used for controlling servos, sensors and whatever else and talk to the Propeller via I2C and/or other protocols, maybe even CAN.
How about 3 to 6 servos with the last 3 being optional? I am thinking 6 servos maximum because that could control a pair of 3DOF legs. Make it controllable via I2C and CAN as an option.
Another good idea.
I still have one of your dual PIC boards on my list of must have items. I just have to find somebody to build it for me for a reasonable fee when I get ready for it. It’s a good possibility, as is a Propeller board, for the brain of my Walk 'N Roll when I start building it.
Thanks for those inputs.
I’ll pass on the Propeller for now - I’m still not sure that it will turn out to be a practical chip to use (other than for educational purposes, to teach the concepts of multi-processing). In most applications, I think a higher-end PIC is a lot more functional, and I can write code for it in C.
I’ll think about the Bluetooth idea. At the moment, I know nothing about it.
I’m liking the idea of a small servo controller that talks I2C. I’m imagining a board that is perhaps only 1" X 2", and controls a few servos (up to six should be no problem). A bot with a bunch of servos (like a hex) could have one of these boards for each leg, or one for each pair of legs. Because of using I2C, it is easy to have multiple boards on the same bus, each with a different I2C address. It might be possible to include a pair of H-bridges on the board, so that it could also control wheel-motors and such. The H-bridges could be optionally configured as general-purpose power switches (like on my dualPIC board).
I had another idea for a PIC/Bluetooth related project… How about a simple remote robot communicator/controller? You could put an LCD display (I would like a 4x40 display) with some sort of keyboard, and of course a Bluetoothlink like this from Sparkfun on it. Something like this would make it a lot easier to debug a robot and see what it is doing when the robot also has a Bluetooth link. It’s not real expensive to add Bluetooth to a robot now. It can be difficult to tell what part of the code a robot is in when doing a certain behavior when it’s up on the bench, and I can’t see my serial output when it’s down on the floor rolling around in different environments outside my apartment, so this device would definitely have to be small and portable.
Yes, for sure! If a bot happens to have more than 3DOF in one or more legs, the additional servo controls could also be used for those.
The next addition I get for W.A.L.T.E.R. will be an i2c device, either the Nubotics Wheel Watchers with the Wheel Commander, a compass module, a TPA01 thermal sensor, or an SRF08 or SRF10 Ultrasonic sensor (not necessarily in that order). I really want to learn how to use i2c. I am running out of I/O pins fast on my Basic ATOM, so I need to get familiar with i2c.
Do you mean a stand-alone gadget that you could hold in your hand, that does NOT involve using your PC, and lets you send/receive simple commands with your bot?
If so, that’s just a higher-tech version of the telemetry system that I already have working. My dualPIC board has a xmtr on it, and it sends serial data (text) from the PIC18F4620. My current ‘receiver’ consists of a receiver module on a Microchip demo board with a 2X16 LCD display and a serial port (optional, goes to the PC, to display stuff that doesn’t fit on the LCD). The xmtr/rcvr I’m using is this: sparkfun.com/commerce/produc … ts_id=7815
At the moment, my setup is one-way only (from bot to receiver).
The up-side of Bluetooth appears to be speed, encryption, robustness, etc. And it is bi-directional by default. It’s a complete wireless modem link.
The down-side is cost: it’s $65 for each end of the basic link ($130 total).
My approach is slow (4800 baud), but only costs $15 each way.
I see how this works now, and seems to have a little better range than Bluetooth. However, with Bluetooth there are more kinds of devices that could potentially be used to interface to the robot, including PDAs, Laptops, Tablet PCs, other robots (which could also use your telemetry system), etc.
Yes, there is a price for that robustness. Actually, Bluetooth is a wireless cable replacement the way it is officially marketed. It really is a type of wireless modem though. While it may be more expensive for each link, it’s gaining very wide appeal and usage in all sorts of devices. I would really like to see that spread to robotics.
The price of your approach is definitely appealing!
Maybe it could be a module that could be added to any robot easily, and then we just use the remote transceiver when we need it. It (like Bluetooth) would be an option to using a wireless PS/2 controller and probably would not use as many I/O pins on the robot’s controller. It (also like Bluetooth) would have the benefit of two way communication with the robot. I would like to see you make what you have into a full duplex communication system.
Would this telemetry system work for communication between many robots, as well as a portable remote display/control?
Yes, but it would have limits. A ‘protocol’ would need to be wrapped around the data, to handle things like collisions (two xmtrs talking at the same time) and addressing (knowing who sent a particular packet).
At some point the complexity would make it no longer feasible, and that’s where Bluetooth would be the way to go.
Emphasis on the ‘mini’ - if I do this, it will only be about 1/3 the size of an SSC, so I would not count on 8-12 servo ports. With an I2C interface, it would be easy to just use two of the boards if you need more than (say) 6 servos.
As for the Bluetooth and such: It would not be part of a servo controller board. In fact, it occurs to me that there’s really no need for a ‘special board’ for using any of the proposed wireless modules - they are already self-contained. You just apply power and connect them to a serial data stream from your MPU.
Right. One would be trading hardware cost for software development time.
The Bluetooth approach would not require much of either hardware or software development to implement if you use that neat little dip module from Sparkfun. Of course, that module is about 4 times more expensive than what you are using now.
I think Bluetooth would still be the way to go for something like this. You have standards and many different types of devices that adhere to them. Most Bluetooth devices can pair up and work with each other pretty easily as long as they have at least one profile in common. All you would need for this project is the serial port profile.
I have also purchased the same sparkfun wireless module you have. Do you have any tips to get it working correctly? What I have is 2 pic’s setup, one as a transmitter, the other as a receiver. The transmitter just sends “hello” over and over. The receiver takes this and then relays it back into the PC’s serial port. If I directly connect the pic’s together everything works fine - I can see “hellohello…” on my terminal window. When i replace the wire with the wireless modules I get nothing. Occasionally if I touch the antennas I will see garbled characters and maybe a “hello” once in a while.
Sorry to be off topic but how do you have yours setup?
Are you powering the modules with the recommended voltages? 5V should be fine for both.
Make sure you’ve identified “pin 1” correctly on the modules. Mine has tiny markings I think. Don’t trust the pictures shown in the data sheet.
On the the rcvr, use pin 2 as the serial output and not pin 3.
Try doing something more basic: Don’t use the PICs, but instead just power up the rcvr and xmtr modules, and use a voltmeter to monitor pin 2 on the rcvr. Now connect the data input of the xmtr to Gnd and then +5, alternately – you should see the output of the rcvr change state to match. If it doesn’t, you either have a bad module or something is wrong with your hookup.
The antenna on the xmtr should be just a simple length of wire that goes nowhere. While testing on the bench, you shouldn’t need any antenna wire at all.
Baud rate on both sides must be 4800 or less. See if a slower rate changes anything.
When the rcvr is running, but the xmtr is powered off, the rcvr should (as I recall) spew out a constant stream of random garbage. This is because the rcvr has no ‘quieting’ functionality, so it tries to always receive “something”. If you have an oscilloscope, check the rcvr output.
When you power up the xmtr (with no data signal), the rcvr output should stay at a constant state.
I am running both the rx and tx on 5v. They are both wired up correctly. The modules have markings on them now so I know they are correct. I have tried running the tx as a higher voltage of 7.2v. The manual says it can be run up to 12v. The modules are running at 1200 baud and I have also tried 2400 with no luck. I have also tried tuning them as the manul suggests.
I am pretty sure the modules are fine. I purchased 2 sets and they both behave the same.
One thing that I do not see is the receiver spewing out random characters when the tx is powered off. Every once in a while I will see something when I touch the antenna (sometimes random chars, sometimes the correct char).
Where did you find a tuning procedure? The docs I have don’t talk about how to do it.
It’s possible that you have them out of tune.
Are you using the 2400 baud model, which appears to have an adjustment on the rcvr module? I’m using the 4800 baud type, which does NOT have any obvious tuning capability. I wouldn’t recommend changing the tuning unless you’re sure that they’re wrong.
But if you’ve already changed it, then using a voltmeter as described before, I’d suggest playing with the tuning adjustment until you get a clear indication of a signal. It’s best to use a plastic tuning tool - if you use a metal screwdriver, the tuning will change just by bringing the driver close to the adjustment.
Side-note related to tuning: I tried using one of the Laipac xmtr modules with a Microchip rfPIC receiver module. It didn’t work with the Laipac xmtr, but it DID work with the Microchip xmtr. Using a frequency counter, I found that the Microchip modules are not very close to the ‘official’ frequency of 434.92 Mhz. The Laipac xmtr was within the spec shown in the datasheet. The Microchip modules are intended to be demos for the rfPIC chips, so they are on a much larger board, and it is easy enough to tune them by changing a capacitor value (but I haven’t done it).
Another (fainter) possibility is that you have a strong source of interference that is ‘swamping’ your rcvr, so that your signal isn’t seen amongst all the muck.
The frequencies used by these modules (434 and 315 Mhz) are used by lots of household gadgets, including garage-door openers, keyless entry systems for cars, etc.
Are you running 315 or 434? I think 315 is used by more cheap gadgets, and is more likely to see interference.
Try running the rcvr without an antenna wire connected (you should do that anyway until you get everything working). If you have an antenna wire connected, your rcvr is picking up everything within half a block or so… Maybe also try covering the rcvr with a metal box, to shield any unwanted signals.
I am using a ttl shifter from spark fun as well. There is an led light that indicates serial going into the PC. This led is constantly on which means someting is being sent but hyperterminal doesnt pick anything up.
Does the TTL shifter light up only when the signal is actually changing, or would it stay on solid simply because the serial line is always high (or low, whichever)?
You could easily test that without the rcvr, just connect the serial line manually to +5 and then Gnd.
If it only lights when things are changing, then that could be the random output from the rcvr. Note that the random output is not serial data at any particular baud rate; rather it is just the rcvr’s output randomly wiggling up and down. So Hyperterm would not necessarily see anything.
Regarding the “tuning procedure” - note that it doesn’t really tell you how to adjust it…
FYI, folks might recall at the beginning of this thread that I planned to make an SMT board this time.
To enforce that notion, I’ve ordered myself a hot-air rework/soldering station for Xmas .
It’s the same brand as the ones that SparkFun sells, but it’s a model 768. I found a web store that had a bigger selection and considerably lower prices. Also ordered some various extra soldering tips and hot-air nozzles.
It’s “in the mail” as we speak…
My old Weller has served me well, but it will probably be mostly idle from now on.
I still haven’t decided what the new PCB will do. I’m now leaning towards a small board that does the following:
A small/medium sized PIC, such as an 18F2420.
The little 434 Mhz rcvr and xmtr modules from SparkFun (I’ve ruled out Bluetooth for now, because of the cost). I’ve ordered two more sets of rcvr/xmtr modules.
Software to do some basic half-duplex communications with other modules running the same code.
Several MOSFET switches for controlling motors or other gadgets.
I2C.
Some basic I/O pins.
One possible cool application of these would be in making a “fleet” (swarm) of very small bots that all are controlled by a “mother ship” (queen).
Or, this board could simply be the intelligent wireless communications port on a bot. As was suggested in an earlier post, it could be used for doing hand-held remote control and such.
I had an idea for my next PCB project:
Since I can’t settle on exactly which functionality to put on a single board, I’ll make 3 or 4 little “modular” boards that stack on top of each other (similar to PC104).
Each board would be 1.25" X 2.5" (or less), to get 3 boards from the ExpressPCB “miniboard” service, which is 3.8" X 2.5".
One board would be the MPU, it’s programming header, and perhaps a 5V regulator.
Another little board would contain some FET switches, and H-bridge, and related stuff.
Another board would include the transmitter and receiver modules mentioned in earlier replies.
The MPU board would probably be “required”, but the other boards would be optional.
The board-to-board connectors would be based on SMT IDC-type connectors, such that header pins from the bottom board go through holes in the PCB to mate with an SMT female header on the top of the board.
With this approach, someone could easily make their own board to add to the “stack”, such as a Bluetooth module, or an SD flash card, or whatever.
It can be difficult to tell what part of the code a robot is in when doing a certain behavior when it’s up on the bench, and I can’t see my serial output when it’s down on the floor rolling around in different environments outside my apartment, so this device would definitely have to be small and portable.