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:
In the last post the connection between the Android smartphone and an RC Car was established. Now it’s also possible to have a connection from the smartphone to the Internet for both, video streaming and remote controlling (RC). Both is needed for a first person view controlling of a vehicle.
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.
Smartphones are a really great thing. They have a lot of sensors, computing power, great communication capabilities and a really nice display.
Combine a smartphone with an rc vehicle is really attractive. You can do a lot of things with it. Control it, display telemetry data or other things as well. So I start with the communication and choose bluetooth for the connection.
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.
To start developing something with an arduino you may as yourself “what can I build, which is easy at start and a lot of fun, too”.
If you like (remote) planes, maybe the follwing is something for you. I changed the electronic controlling unit from a plane
which has no rudder to controll it but two diffenrent prop speeds on each side. Famous product groups of these kind of planes
are X-Twin or AirAce. The nice thing is, you only need a small arduino, a small receiver and 8 other electronic parts. Two mos-fet, two dioden, some capacitor and a power regulation like the 7805. That’s all, simple to build and also cheap stuff.
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.
For a better controlling of the plane I reused a old rc from my silverlit x-ufo. Changed the electronic of the rc to an arduino based and used a wi232 module for the transmission of the control commands. The old “mousepad approach” I used is not very handy if the environment and especially the plane is not in best condition.
So it’s more comfortable to control the plane this way.
The construction is not a big deal. I only used a 7805 to get 5 volt from the batteries and connect everything to this. You only have to remember to cross rx and tx between rc and plane. Also double check with one is the “middle” pin of the poti to connect to the analog input pin on the arduino.
I also used the soft serial library to get a second serial interface. This is used for logging on the pc at the moment.
.
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.
Today I did my first outdoor testflight with the newly implemented ACC/stable-mode. ACC means it uses a accelerator sensor to level the quadrocopter if nick/roll stick is in middle position. Another mode is Heading Hold (HH) which means the copter hold its attitude if nick/roll stick is in middle position. For the HH mode only gyros are nessesary and the copter do not need to know where the bottom is. On the OSP you can switch between both modes while flying.
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.
On my little uav plane project I started with a new tool for the laptop. It should be possible to create a waypoint map and to track the current position of the plane. I tried to keep things simple as possible but also that it is useable. As alsways it should be usable on the most popular operation systems. In the end it’s a java swing application created with netbeans.
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.
After the nice testflight of my simple uav plane I decide to rebuild the electronic part for some improvements:
- 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.
On the last sunday I’d the maiden flight of my “Simple UAV” plane. The weather was not really perfect because it’s cold these days and also just a little bit wind, but after some tries I get more comfortable with the touchpad-controlling. Two flights are short, but not too bad and showed me what’s working and what’s to improve.
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.
Today I did my first “HIL-Test”. Ok, a real “Hardware in the loop” might be a little bit more complex. 
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/).
