I worked on my 3G data link based FPV car with the Android Smartphone. Improved the following things

• Wide angle lense
• “4 channel” RC transmitter for control input generation
• Automatic reconnect function on both sides, Smartphone and Laptop

The first thing is an optional lense to get view angel of nearly 90 degres. That helps a lot to navigate and control a vehicle with first person view. Another effect is, that the cam gets more light from the environment and that improves also the speed of dark-bright adaption.

The second thing was to find something with which it is easier to control a vehicle than with the mouse pad. An old remote from an xufo is used for that. To get the stick positions an Arduino reads the potentiometer values and send it via FTDI interface to the laptop.

The last was, to improve the software on Smartphone and Laptop a bit. The main thing was to introduce a detection if connection is lost on both sides. If this is the case, the smartphone software try to reconnect and the laptop software informs the user that connection is lost and wait for a new connection.

Now the car is much more controllable, even with a poor 3G data link as you can see on the following video:

But why controlling a FPV car via Internet? Because theoretically there is no limit about the range except the battery capacity. Normal FPV gear and RC components have without the need of a special radio license in Germany a range about half or one kilometer with clear line of sight between sender and receiver. On ground it’s even less, maybe 100 or 200 meter at best. With a 3G data link it depends on the telecommunication net which is big on most places. That’s the reason for doing a little bit “research” on this topic.

The video can be produced through the on board cam of the smartphone. The cam video can be streamed to the net. I use Skype ™ for this purpose, because it’s fast and easy available for my Galaxy S2 and support video telephony.

The tricky part was the car controlling. I decided to establish the connection from the smartphone to my laptop. This worked well even through the home router. Next part was the protocol. TCP is not the perfect option, because it can be very slow with all the checks in it. UDP is much better, because it doesn’t matter if some of the controlling information don’t reach the car. It’s much more important that – new – controlling information coming fast to the car.

For this the smartphone act as the client. On the laptop site there is a small server software which communicate with the smartphone. This software wait for the initial UDP connection of the smartphone and send after that control information via UDP to the smartphone. The smartphone transmit these information via Bluetooth to the Arduino.

A first test show that this all works together but with a lack of accuracy and some delay.

I think the software part of this approach can be improved for faster and better reactions and also more reliability. This approach also use 3G data link and IPv4. You can imagine how this will be improved if IPv6 and 4G data link is available.

There are cheap and simple serial bluetooth modules available with an uart interface. Perfect to put it on an arduino and communicate with it. The chosen module had a default baud rate of 9600 or 19200, I’m not quite shure about that. But this can be changed with a “AT” command to 115200 (“AT+BAUD8″ in my case). The command has to be send to the module fast and complete. On my mac I’d some problems to configure the module, but on the linux within a virtual machine it works perfect. I connect the module on a USB to UART adapter and used something like:

echo "AT+BAUD8" > /dev/USB0


On the Arduino site it is really simple to connect one of the six possible PWM output pins to the servo or electronic speed controller (ESC) of the car. If connected, it can be set with the arduino analogWrite command. It should be a value between 128 and 255, because a value lower than 128 is like “no signal” for the servo or ESC. On the traxxas car the ESC had to be recalibrated, because “neutral” position was something different than 192 (128 + 128/2).

Now, everything on the “car-site” is fine. What’s about the smartphone site? I choosed android for some reasons. One of them is the open architecture and the free software developement kit without any registration. There are some tutorials and examples for the bluetooth communication. Important to get a connection is the correct UUID for a serial module. To communicate with a bondet device the code should include something like

BluetoothAdapter mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
Set pairedDevices = mBluetoothAdapter.getBondedDevices();
BluetoothDevice mbtDevice;
for (BluetoothDevice device : pairedDevices) {
mbtDevice = device;
}
BluetoothSocket btSocket = mbtDevice.createRfcommSocketToServiceRecord(UUID.fromString("00001101-0000-1000-8000-00805F9B34FB"));
btSocket.connect();
InputStream btInputStream = btSocket.getInputStream();
OutputStream btOutputStream = btSocket.getOutputStream();


How this work all together you can see in the following video

Now a basis for further experiments is established.

On the arduino site you need two of the PWM output channels to control the speed of the motors via the mos-fet.

analogWrite(motorPin, motorValue);

Two digital input pins on the arduino are needet to read the two controlling channels of the receiver. To read a channel you basically measure the time between a low/high change on the pin and get the value of your rc. You can try something like pulseIn() or
for better results use an existing code like the one who is used in the MultiWiiCopter.

The only thing left is to mix the rc values to your motors, but this is easy. Something like

motor_left = power + (direction - direction_center)
motor_right = power - (direction - direction_center)

will do the work, but keep in mind that your PWM output only can handle values between 0 to 255.

Now you can control the direction and the altitude of your plane. So you can also extend this vehicle with some other sensors to
stabilize it, or give your “robot” more autonomously behaviour.

Or you can just enjoy your plane with a light fpv cam+video tx combination, like me on this video.

.

Advantages of this are

• Small device to control the plane
• No limit on “channels” compared to a traditional rc
• Back-channel for telematic or other information
• Resolution up to 1000 steps on a poti
• Free programmable
• Optional logging capabilities

You can also use the normal rc that you get with such a plane like mine. I use the “bigger” x-ufo rc because of the two way control of every stick. In this way I have the option to test this also on other vehicles like a copter.

First testflights on a gusty day:

On the last flight the plane “landed” in the water channel.

This is an easy and basic implementation of the ACC mode. Fusion of the gyro and acc sensor values are done with the following code.

int angle_diff_nick=IMU_CalcData.acc_angle_nick-CTRL_FlightParams.reserved[ACC_TRIM_NICK]-IMU_CalcData.angle_nick;
angle_diff_nick*=CTRL_FlightParams.approach_speed;
angle_diff_nick/=1000;
IMU_CalcData.angle_nick+=angle_diff_nick;


A pd controller is responsible to get the correct attitude.


perror_nick = (-real_nick * CTRL_FlightParams.K_stick_nick) + IMU_CalcData.angle_nick;
derror_nick = perror_nick - old_error_nick;
CTRL_InternalOut.nick= (CTRL_FlightParams.Kp_nick*perror_nick)+(CTRL_FlightParams.Kd_nick*derror_nick);
old_error_nick = perror_nick;


And here is the video of the first outdoor testflight.

Most things are configurable, like maps, size of waypoint, default map position on earth and other things.

Tracking the current position is also tested with my gps simulator on the plane. The plane send this position wireless to the ground application which displays the position in the map.

The next two tasks are to extend the plane/arduino firmware with waypoint flight function and to create a simple plane simulation on the laptop. This way it’s much better and saver to test, especially at winter time.

The code is available as usual on the project page.

• Size – should fit into the plane cargo bay
• Easy reflash the arduino – not reconnect wires every time
• Remove unnecessary parts – AnyVolt Micro is not needed
• GPS connection – just plug in the GPS module

On the picture you see three electronic build-ups. The original AirAce electronic on the left. In the middle it’s the electronic of the successful maiden flight and on the right side the new one which fit into the plane and should be also more robust.

Next steps are to test all functions of the electronic and play a little bit with the new Firmware 0.2. Especially if the GPS data is received and interpreted correctly. This can be done with the GPS module itself or by my “GPS Simulator”. If these things work well a new testflight will show if the flight behaviour is stable enough or if I need an additional sensor to stabilize the plane.

The value for both motor sides for straight and level flight are between 60 and 110 (maximum is 255). Control input to the left and right are not more than +/-50. Without checksum it’s possible on a distance of ca. 100m that single controlling signals went wrong and the plane do something “strange”. This happens only just for a part of a second but it’s enough .. to much I would say.

Battery minimum was about 6 Volt for a very short time with full loading.

What I did was to connect my Quadrocopter with two serial interface to my computer. With the first connection I get the quadrocopter internal information to the mac. On the second connection – normally – a gps receiver can be connected to the quadrocopter. Now I implemented a gps simulation on my mac and put these simulated gps data to the quadrocopter. The first connection is now used to see, if the quadrocopter use the gps information in a correct way.

Now I see that this works and on the next step I can check if calculating the home position or the next waypoint is correct. The nice thing is, that the gps simulation allow to get me a moving position without a time-consuming and risky testflight. The other point is, that winter time is not very nice for outdoor tests.

All the code – simulation, quadrocopter firmware and data visualisation – is available on the subversion repository on the project website (http://sourceforge.net/p/opensourcepilot/).