New car test through laptop

We took the new RC car for a spin with the UI and the camera. Buzz wanted to try out his own camera, which is much more expensive and better than mine, so we mounted it.

Camera mounted to car with additional rails... and tape.

 

That's a true hack job there :) TJ suggested putting rails on it between the back and front shocks. We'll get around to actually cutting them to size, tapping and screwing them, but for now they're zip tied on. Then a plastic light cover is taped between the rods, and the camera, antenna and wires are taped down everywhere :)

You can also see the JeeNode at the front. It turns out to be really easy to control both steering, and throttle with an ESC, as they both just use standard servo control. It actually saves me 2 pins compared to the other car!

View from car camera

 Buzz took it for a spin. He was determined to try to drive it under the cars parked in the space. We taped a small flashlight to the front so we could see.

Unfortunately I didn't record any video footage from this. We were also still getting used to the fast car and the controls were twitchy; with just a slightly too-long keypress, I drove the car into a pole so hard the zip-tied rails slid forward out of the rear zip ties. Buzz got it stuck under a car. I tried to drive it outside which I knew was dangerous if I lost jeenode signal and therefore control. I lost both video and control signals at once momentarily, and Buzz went to get the car. He found it trying to reverse while hard up, and making a bad electronics smell. We're not entirely sure what made the smell, and everything still works, but I think it was probably the ESC - it's the only thing that was a bit warm.

I have been aware of the danger of driving out of signal for some time, because there's nothing stopping the car from continuing if it never gets the stop command. There's no way to detect a JeeNode signal in range except to receive data. It wasn't that much of a concern with the smaller car, and I was just careful. So now I have a really compelling reason, and I've done it - if the car hasn't received a command to go forward, reverse or stop for 250ms, it stops. This also requires a change to the UI to send an update every 150ms, just to keep it going if for example you hold down forward for over 250ms, where before there would be no need to send an update.

Fancy new UI

I've been working on dramatic improvements to the UI - position indicators, more gauges, and building in the support for a few features to come. Tell me if it looks familiar at all ;)

This would of course finally be full screen, with the video behind, and work in widescreen or 4:3.

New car! New control!

Bigger, faster, actually has suspension, proportional steering and throttle, and simplified electronics through an ESC - awesome :)
Also the battery is higher voltage (7.2V) so I should be able to run the camera off the same battery!
However, the canopy is very flimsy so I'll have to create a new mount for the camera + gun.

Oh and what's that behind it?....

It's an old set of steering wheel and pedals that I picked up for $10 at an op shop! It's for a PS2 or Xbox original, but as Xbox is just USB, at Hackerspace tonight I lopped off the end and after a lot of cursing about anti-standard wire colours, got it recognised as a USB device under Windows. Have yet to try Mac. How awesome will it be to drive that car with a proper wheel and pedals!

JeeNode frequencies and signal quality

A question arose on the HackerSpace Brisbane mailing list about the supported frequencies of the JeeNodes. I was under the impression, in the vacuum of contrary information, that the units I had would work at least to some extent in all the supported frequencies (433, 868 and 915 MHz), although it is difficult to make a single radio that can do that. I was under this impression because I had tested such with the RF12demo on the units when I first unpacked them.

It turns out that because I bought them at the actual JeeLabs Shop, in Europe, I got the 868 MHz versions, rather than the 915 MHz version sold at Modern Device. This might be problematic.

Anyway, I did a number of tests to determine the suitability of each frequency with the modules I have.

Testing more thoroughly with the RF12demo again, I determined the following radio capabilities:

• changing both to any of the 3 frequencies allows communication both ways (including ack)
• changing one to 868 and the other 433 allows data 868 -> 433 but not the other way (and no ack reply)
• sending from 915 cannot be received by either 868 or 433

This indicates all frequencies work, or at least some kind of shared delusion of using the same frequency.

Then I tested the relative signal quality of each frequency. I wrote a sketch that spams my car about every 50ms (it has an echo function for pinging and tests just like this) and reads the echo reply. I ran that on the USB JeeLink attached to my laptop used the highly scientific approach of walking around the house with it. I had it print out a dot for every send, and an R for every receive, so the ideal output looks like this:
.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R

... and so on.

• 915 was ok, in the same room it got all the packets, and I could get through two or three walls and still receive a significant number of packets.
• 868 was awesome. I went all over the house and hardly dropped a packet. In fact I had to get the laptop halfway into the fridge before I started losing more packets than I sent! ...R...R.R.R.R....R..R... 
• 433 was disappointing. It lost packets within the room and lost significant amounts just outside the door!

Note that this was all with unoptimised antennas. Default length of about 90mm. According to this talk page, 868 should be at 82mm (pretty close), and 433 at 165mm, which might explain its poor performance. I don't think 1/8 wave works very well. 

 

 

Car fully working with JeeNode

I pulled out the old RBBB Arduino clone, and hastily blue-tacked the JeeNode in its place. I left all the breadboard wiring in place in case it didn't work and I had to revert to the RBBB. But, success! It was a bit fiddly jumping all the wires from their otherwise neat ribbon cables into the JeeNode ports, but here it is:

The small ribbon cable with the black lead goes to the wheel motor controller, and the larger cable with red is for the pan/tilt servos, IR gun and has room for expansion.

So I've connected up everything, and it successfully goes forward, back, left, right, moves the camera, shoots and measures the battery voltage! Just as responsive as before! Only this time with better range! More on that in another post.

Saggy reprap parts :(

I often leave my stuff in the car, in the sun, while I'm at work, when I'm heading to HackerSpace Brisbane that evening. This must have happened on a particularly hot day:

 

The base of the pan/tilt mount is badly warped. The tilt doesn't work very well any more because the distance is greater, so you tilt up halfway and it starts going down again. Infinite sadness.

Do I put it on a flat surface and hit it with a hair dryer to get it back in shape? Do I just print a new part? I planned to design a new one with a support that went all around instead of just at the front. That should help with warping. Also a smaller base would be better, and the corners on this one catch on the servo wire, so it should be more rounded.

JeeNode working!

After quite a while porting my arduino code to use the jeenodes instead of serial/xbee, and figuring out which pins on the "ports" map to digital pin numbers, I got it to work! I can control the pan/tilt mount remotely! (that's all I've tried so far) And it's quite acceptably fast - in fact pings hover aound 54ms!

The main challenge with porting the code was that instead of just throwing data at the serial port and letting the xbees deal with it, I have to think about how to break it into packets, and which packets I really need to send and which I don't. There is also the issue of sometimes having to wait to send data, which might become a problem later. For now I have two methods, one says "send it now if you can, else drop it" and the other says "try to send forever". If the channel was tied up, it would just freeze up there. Obviously there will need to be some middle ground, if I run into problems.

I also had to write code for the JeeLink (the usb dongle, which is basically just a SMD AVR and antenna), to make it appear to be a plain serial connection for the frontend software. It was easiest if the frontend changed as little as possible (not at all, actually). In future it will be extended to provide the sender node ID and so on. This may probably become a central server node that directs all the traffic to the clients.

I had to figure out the mapping of pins to the existing arduino pins I was using so I could plug the servos into the right ports. Also there are only 4 digital and 4 analog-in ports provided on the JeeNode, so I was worried that I was already using all the pins I had available. I looked at the JeeNode diagram and the arduino diagram and painstakingly mapped it out. Basically the RF12 module steals 5 of my digital pins, two of them PWM. But some pins are mapped to the I2C and SPI/ISP connectors also available on the JeeNode, and to the INT pin on each Port. So I should be able to recover 3 digital pins, 2 of which are PWM, and two more analog-in pins. So that provides enough room for some additional things I want to do :)