I just came across this kit, looks pretty cool. I currently use the RBBB Kit, so the JeeNode is just that + an onboard wireless serial device. Would work well in my case, because I already use the RBBB on a breadboard with an offboard XBee as wireless serial.
You'd need the PC end as well to be able to communicate with it. I'd like to know how hard they might be to configure to talk to different devices.
Don't know much about the serial device itself; whether it does spread spectrum, buffering, meshing etc; you do get a lot with the XBees. But this might turn out to still be quite acceptable.
Looks like they are available in Australia at toysdownunder, but the board is out of stock and they don't seem to have the host, which makes it all quite moot.
Wednesday, September 22, 2010
Tuesday, September 21, 2010
Xbee communication
I've had some odd problems with the XBee modules I have.
tl;dr I changed them from ZIGBEE (coordinator/end) to ZNET 2.5 (coordinator/end) and it seems to have fixed it.
If you want to know more, read on.
As it happens, when I went to buy them from littlebird electronics, they only had series 2.5 modules. I did read that they are not compatible with series 1, but thought that it was likely that 2.5 would be overall better. As it turns out, series 1 may have been better, at least where one is communicating in a transparent serial way, between just two nodes. Later, the features of 2.5 may come in more useful.
Another bugbear of the 2.5 series is that they don't do I/O line passing, ie the serial control signals like RTS, CTS etc, which means you can't treat them like a full transparent serial interface. Which means you can't set them up to be able to upload arduino code wirelessly. This is not essential as my car will not be inaccessible, but would have been nice. There may be ways to do it by sending a reset command at the right time, then hitting upload at the right time, but meh.
Back to my problem. When I originally configured them, I followed a tutorial, and was delighted to see they worked very well, fast and reliable! Later they started doing odd stuttering things, where the car would just stop responding, then maybe several seconds later suddenly start moving, like it had some of the commands buffered and had just gotten to them. This may be partially due to power issues I had. Then I stopped receiving any data at all from the car, which was annoying as I needed to debug the controls (the car would send back what action it had just performed).
I had, as per the tutorial, configured the modules as "ZIGBEE COORDINATOR AT" and "ZIGBEE ROUTER/END DEVICE AT". What this means is that they use the Zigbee protocol, one is the coordinator and the other is the end device, and they interface using the AT protocol. In a mesh, there can be multiple end devices which can either talk both ways with the coordinator, or use the broadcast address to talk to all at once. For a single peer to peer connection, imitating a wired serial connection, the devices are configured with eachother's high and low serial numbers, so they only talk to eachother. The AT protocol is the way one configured the old dialup modems. The other option is API which I won't go into here.
Another tutorial contradicted this and said I should configure it as "ZNET 2.5 COORDINATOR AT" and "ZNET 2.5 ROUTER/END DEVICE AT". I was dubious that this would fix it, because it had worked earlier, and the whole coordinator/end thing sounded basically the same. Also I had real trouble reconfiguring one of them; it seemed to not respond to attempts to rewrite the firmware. I eventually found a post here which worked for me; without having to wire up a reset switch or something, this was a lot simpler. It boils down to:
Here is a page with a lot of useful notes about XBee modules in general:
Xbee Znet and gps (RoboSci Blog)
tl;dr I changed them from ZIGBEE (coordinator/end) to ZNET 2.5 (coordinator/end) and it seems to have fixed it.
If you want to know more, read on.
As it happens, when I went to buy them from littlebird electronics, they only had series 2.5 modules. I did read that they are not compatible with series 1, but thought that it was likely that 2.5 would be overall better. As it turns out, series 1 may have been better, at least where one is communicating in a transparent serial way, between just two nodes. Later, the features of 2.5 may come in more useful.
Another bugbear of the 2.5 series is that they don't do I/O line passing, ie the serial control signals like RTS, CTS etc, which means you can't treat them like a full transparent serial interface. Which means you can't set them up to be able to upload arduino code wirelessly. This is not essential as my car will not be inaccessible, but would have been nice. There may be ways to do it by sending a reset command at the right time, then hitting upload at the right time, but meh.
Back to my problem. When I originally configured them, I followed a tutorial, and was delighted to see they worked very well, fast and reliable! Later they started doing odd stuttering things, where the car would just stop responding, then maybe several seconds later suddenly start moving, like it had some of the commands buffered and had just gotten to them. This may be partially due to power issues I had. Then I stopped receiving any data at all from the car, which was annoying as I needed to debug the controls (the car would send back what action it had just performed).
I had, as per the tutorial, configured the modules as "ZIGBEE COORDINATOR AT" and "ZIGBEE ROUTER/END DEVICE AT". What this means is that they use the Zigbee protocol, one is the coordinator and the other is the end device, and they interface using the AT protocol. In a mesh, there can be multiple end devices which can either talk both ways with the coordinator, or use the broadcast address to talk to all at once. For a single peer to peer connection, imitating a wired serial connection, the devices are configured with eachother's high and low serial numbers, so they only talk to eachother. The AT protocol is the way one configured the old dialup modems. The other option is API which I won't go into here.
Another tutorial contradicted this and said I should configure it as "ZNET 2.5 COORDINATOR AT" and "ZNET 2.5 ROUTER/END DEVICE AT". I was dubious that this would fix it, because it had worked earlier, and the whole coordinator/end thing sounded basically the same. Also I had real trouble reconfiguring one of them; it seemed to not respond to attempts to rewrite the firmware. I eventually found a post here which worked for me; without having to wire up a reset switch or something, this was a lot simpler. It boils down to:
- pull the module out of the usb or breakout board
- write the firmware with X-CTU
- it will complain that it can't find the device. when this happens, smoothly reinsert the module (don't miss or bend any pins).
- it will write the firmware, and possibly complain about not being able to set the AT commands. but the important part is done.
- re-read the module, and you will need to configure it again as it has had defaults written.
Here is a page with a lot of useful notes about XBee modules in general:
Xbee Znet and gps (RoboSci Blog)
Monday, September 20, 2010
Onboard Arduino and XBee
The "Arduino" that I'm using in this project is actually an arduino-compatible Really Bare Bones Board (RBBB). This was both cheaper and more appropriate for this project, because I would rather plug it into a regular breadboard to have more pins available. Luckily a breadboard I had already happened to have fit quite neatly into the car!
Since the control would be in the car, I had no use for the hacked handheld controller any more. I had to hack the car's receiver end instead and figure out how I could drive it. It had a number of transistors which appeared to form two variations of an H-bridge, one for the forward/reverse motor, one for steering. It also had a small PCB offshoot which probably did the signal processing. It connected to the main PCB with a number of pins. I made use of an oscilloscope which had been recently loaned to the hackerspace, and mapped out the pins as follows:
If we make the top left pin 1 and the top right 18 (going down and back up the other side), then pins 1, 3, 4 and 10 are of interest. All I have to do is send a 5V signal from the arduino to drive the car that way. You also need to connect up the ground to make them common (or the 5V signal won't be registered). Also, being a H-bridge, you must be careful not to send both forward and reverse signals at once, which shortcircuits around the motor and causes "shoot-through", driving all the current straight to ground and possibly damaging or burning out components.
Unfortunately I didn't get a photo of the car's hacked circuit board before I closed it up to test it, but here are some photos of the mounted wireless circuit. Hmm... these seem to be mirrored. Stupid mac camera software.
Since the control would be in the car, I had no use for the hacked handheld controller any more. I had to hack the car's receiver end instead and figure out how I could drive it. It had a number of transistors which appeared to form two variations of an H-bridge, one for the forward/reverse motor, one for steering. It also had a small PCB offshoot which probably did the signal processing. It connected to the main PCB with a number of pins. I made use of an oscilloscope which had been recently loaned to the hackerspace, and mapped out the pins as follows:
If we make the top left pin 1 and the top right 18 (going down and back up the other side), then pins 1, 3, 4 and 10 are of interest. All I have to do is send a 5V signal from the arduino to drive the car that way. You also need to connect up the ground to make them common (or the 5V signal won't be registered). Also, being a H-bridge, you must be careful not to send both forward and reverse signals at once, which shortcircuits around the motor and causes "shoot-through", driving all the current straight to ground and possibly damaging or burning out components.
Unfortunately I didn't get a photo of the car's hacked circuit board before I closed it up to test it, but here are some photos of the mounted wireless circuit. Hmm... these seem to be mirrored. Stupid mac camera software.
 |
| Controller mounted to car body and secured with electrical tape. That's the Xbee module sticking out the side. |
Pan-tilt camera
This is fairly straightforward. One servo controls horizontal movement (pan) of the rest of the structure, and the tilt servo controls vertical movement. I put it on the roof of the vehicle.
I didn't want to cut a huge hole for the big servo, nor have the mechanism mounted high. But the servo's mounting holes were too low. So I built up the rest of the space with polymorph. This stuff is awesome! You grab some of the pellets, throw them in hot water, when they turn transparent they are ready. Fish them out with a spoon and mould it as you like. It cools back to solid white and is a relatively hard plastic. If you mess up or want to change it, and chuck it back in hot water to soften it and you can use it again! If it's stuck to something that might be damaged by hot water, either cut it off or maybe you could use steam.
I screwed screws into it while it was still somewhat soft, to give it a thread. I am able to screw and unscrew it quite securely :) It wasn't quite flat on top, but you can file or cut it down and even retain the leftovers!
I stuck the first one together with blutack and polymorph.
At this time I used separate power for the car, onboard controller, and camera. 9V batteries don't last very long.
I'll get some photos of the new mount. Or maybe skip that entirely and get a better one.
 |
| Hole for the pan servo to hold the structure on top. |
I didn't want to cut a huge hole for the big servo, nor have the mechanism mounted high. But the servo's mounting holes were too low. So I built up the rest of the space with polymorph. This stuff is awesome! You grab some of the pellets, throw them in hot water, when they turn transparent they are ready. Fish them out with a spoon and mould it as you like. It cools back to solid white and is a relatively hard plastic. If you mess up or want to change it, and chuck it back in hot water to soften it and you can use it again! If it's stuck to something that might be damaged by hot water, either cut it off or maybe you could use steam.
 |
| Polymorph to build up some space, with screw thread |
I screwed screws into it while it was still somewhat soft, to give it a thread. I am able to screw and unscrew it quite securely :) It wasn't quite flat on top, but you can file or cut it down and even retain the leftovers!
 |
| Wireless camera and pan/tilt mount, roughly attached with polymorph and blutack. |
I stuck the first one together with blutack and polymorph.
 |
| The pan servo is unneccessarily huge and slow. Soon to be replaced. |
At this time I used separate power for the car, onboard controller, and camera. 9V batteries don't last very long.
 |
| Rear and batteries. |
I'll get some photos of the new mount. Or maybe skip that entirely and get a better one.
PC-based wireless control
The first "wireless" control I had was the handheld battery powered one that came with the car. But since I wanted it controlled through the PC, I had two options:
I also didn't have a wireless camera, but since I had a PC-controlled car, I had to try it out! I blutacked a cheap toy webcam to the car and could drive it about 5m with some USB extensions.
- hack the handheld controller so I could use the existing radio control from the arduino.
- hack the car's controller, instruct it from the arduino, and get commands to the car somehow.
 |
| I hacked the original RC controller in order to send the commands from the PC, from the arduino. |
 |
The controller plugged into the breadboard. |
I also didn't have a wireless camera, but since I had a PC-controlled car, I had to try it out! I blutacked a cheap toy webcam to the car and could drive it about 5m with some USB extensions.
 | |||
| Early days. |
 |
| Success! Remote control car with camera! |
Sunday, September 19, 2010
The Project
I'm starting this build blog to document my progress, as well as the problems I have encountered and their solutions during my project, in order to help others and collaborate.
The project has multiple phases planned, depending on how successful each phase is. The first phase is this:
Ideally also:
I am aware that it is not an original idea to put a camera on a car, nor to control it from a computer. The idea is a smooth game-style interface, and I have a much greater goal in mind which I don't want to reveal yet :) There is much more planned, I have 4 phases sketched out, and will describe them when I start them ;) I might start the next phase soon, while still solving some of the existing problems.
In building this, I have tried to use mostly off-the-shelf components, such as an existing RC car, rather than building from the ground up. A system designed for this specific purpose might perform better, but I just want to get something up and running. In some cases this is cheaper, or easier, or just makes it easier to reproduce. I don't have enough knowledge to build all the different parts, so I'd rather just try to interface them together.
I have implemented this essentially with an arduino (compatible) mounted on a breadboard, hacking into the existing circuit board on the car to control the speed and direction, using XBee series 2.5 2mW radios for communication. The arduino also controls two servos for the pan-tilt mechanism, which was built first by myself, then improved with help from Buzz from HSBNE. The camera is independent of the circuit, having its own antenna and power source, currently.
Here's my photo album for the car, starting with the original circuit and camera mount.
This project has been built with significant assistance and advice of the members of Hackerspace Brisbane, and built and tested at the space.
I'll post about some of the problems I've had so far, and new stuff as it happens!
The project has multiple phases planned, depending on how successful each phase is. The first phase is this:
- PC-based remote control;
- WASD keyboard controls
- video on-screen
- mouse camera control
Ideally also:
- full screen video and mouse
- with overlays
- battery level and lag overlay
- speed control
- protection logic eg auto shutoff when no signal received.
- smooth video even when travelling fast or rough
- upload code changes to arduino remotely
- a single power supply
I am aware that it is not an original idea to put a camera on a car, nor to control it from a computer. The idea is a smooth game-style interface, and I have a much greater goal in mind which I don't want to reveal yet :) There is much more planned, I have 4 phases sketched out, and will describe them when I start them ;) I might start the next phase soon, while still solving some of the existing problems.
In building this, I have tried to use mostly off-the-shelf components, such as an existing RC car, rather than building from the ground up. A system designed for this specific purpose might perform better, but I just want to get something up and running. In some cases this is cheaper, or easier, or just makes it easier to reproduce. I don't have enough knowledge to build all the different parts, so I'd rather just try to interface them together.
I have implemented this essentially with an arduino (compatible) mounted on a breadboard, hacking into the existing circuit board on the car to control the speed and direction, using XBee series 2.5 2mW radios for communication. The arduino also controls two servos for the pan-tilt mechanism, which was built first by myself, then improved with help from Buzz from HSBNE. The camera is independent of the circuit, having its own antenna and power source, currently.
Here's my photo album for the car, starting with the original circuit and camera mount.
This project has been built with significant assistance and advice of the members of Hackerspace Brisbane, and built and tested at the space.
I'll post about some of the problems I've had so far, and new stuff as it happens!
Subscribe to:
Posts (Atom)