View unanswered posts | View active topics It is currently 20 Sep 2017, 00:01

Reply to topic  [ 32 posts ]  Go to page 1, 2, 3, 4  Next
 Tank Drone 
Author Message

Joined: 14 May 2012, 15:48
Posts: 196
I must say I really love the Carambola, no other embedded hardware platform at this price would've allowed me to develop a WiFi enabled tank drone within a week.
Well, obviously the development is far from finished, but I've got a tracked vehicle with the following features already working:

[*] WiFi remote Control
[*] Webcam Streaming (up to 720p)
[*] GPS
[*] Battery Voltage Monitoring (Both cells individually)
[*] System current consumption monitoring
[*] Dual H-Bridge motor controller with PWM based speed control
[*] Servo controller (since I only had one Servo in my parts bin it's used to rotate the camera around)

The Hardware Controller is based on a Parallax Propeller Chip, the Dual H-Bridge was built from 2 VNH 3SP30 and accepts the 3.3V Logic levels from the propeller for its logic inputs (datasheet states only 5V compatible inputs though). A MAX1270 is used to read the Battery Voltage and the output from the 20A hall effect based current sensor (ACS712), later it will also read the output from 3 Sharp IR distance sensors.
For now the Carambolas WiFi is in Client mode, later it will run in AP mode - the plan is to write an Android Software to control the tank from my Android tablet independently of any stationary AP's.
At the moment a temporary PC Software written in Python (quick and dirty) is there to display the camera stream and remote control the tank.

Propeller and Carambola communicate over UART0 (/dev/ttyS0 in Linux) @115200Baud, the Carambola communication server for the drone is also written in Python, programms and additional data are stored on a 4GB USB drive.

The chassis for the vehicle is taken froma RC-Toy Tank (Heng Long), they're cheaply available from eBay.

tankDrone.png [ 478.1 KiB | Viewed 8305 times ]
28 May 2012, 23:28

Joined: 05 Apr 2012, 10:23
Posts: 25
Location: Lithuania
Sounds seriously cool.

29 May 2012, 06:14
Profile WWW

Joined: 14 May 2012, 15:48
Posts: 196
Thank you.
I will document this project here on the forum, at least until I have time to finish my projects website and can put more detailed information online.
If anyone is interested in more details about the hardware/software/configuration please feel free to ask, I'm gonna open source everything when it's done anyway.

Now a short list of features to come for this drone:

  • Obviously a turret (perhaps even some sort of missile battery, would make this thing useful on new years eve)
  • Sound effects (my Tamiya Leopard 2A6 has a pretty decent sound module with engine, turret and weapon sounds. Since this project is eventually gonna end up in there too I need to replicate that sound feature)
  • 3G/UMTS support to remote control it "around the world"
  • Google Maps integration for auto navigation, waypoint integration and Radar Display in simulated battles
  • Augmented Reality for displaying Waypoints, Targets, Events during simulated battles within the video stream
  • Autonomous object tracking and following
  • Clustering multiple drones to improve gathering and processing of informations

Now obviously implementing that list of features is going to take quite a bit of time, some features might not be possible/feasible for the current hardware platform, but I'll certainly try.
The next step is to write an Android app to remote control the drone, because it isn't really practical to carry around a laptop to remote control your "RC-Toy".

EDIT: Hmm, how does that list feature work?!

29 May 2012, 08:36

Joined: 22 May 2012, 21:23
Posts: 24
I so can't believe it!! :D Naythan, I'm doing the same (almost) thing!!

Look: http://www.mighty-prototype.com/wordpress/?p=79

29 May 2012, 11:37

Joined: 14 May 2012, 15:48
Posts: 196
LOL, what a coincidence. ^^

So you're using gstreamer to stream the webcam, what's the advantage over mjpg_streamer? Is UDP streaming possible with it?
I use mjpg_streamer over http. The test-Software I wrote to remote control the tank and display the stream is in Python (in my Idea the perfect prototyping language, as you quickly achieve the result you're looking for). But I believe I already mentioned, that the real remote control Software will be an Android app.
I didn't use ser2net, I wrote a "drone server" in Python. Works very reliable.
The Server opens the serial port @115200,8,N,1, runs an UDP Server to recieve movement control commands and a TCP Server to reliably pass on the sensor data and recieve configuration commands (I'm gonna make the stream adjustable in resolution and frame rate, as I also plan to control the tank over 3G/UMTS which won't allow for the same high quality streaming as WiFi does.)

So, auxtony78, let me know if you want to take a peek at my solution to the serial2net problem.

29 May 2012, 12:19

Joined: 22 May 2012, 21:23
Posts: 24
Actually I use the same as you mjpg_streamer! (I've corrected my site, thks for pointing it btw!)

I'm really interrested in using Python like you do. I'm ASM, C, C++ developer IRL. But I'm might get into that.
Could you describe which package, librairie you use in Pyhton?
Client side and server side!

Looking forward to it !

29 May 2012, 13:33

Joined: 14 May 2012, 15:48
Posts: 196
Well IRL I'm a web developer. ASM and C I only write in the microcontroller world and Python is my number one choice for everything else.
On the Carambola Python only uses one module that's not part of the standard distribution, which is pyserial for easy access to the serial port.
Now as you might already know the standard Python distribution is too large for Carambolas limited Flash ROM, so I use the python-mini package and had to improvise a bit to get pyserial and a few modules from the standard distribution.

First off you can install python-mini and pyserial with opkg, but pyserial won't work without the Termios.so that's missing from the python-mini distribution.
So what I did was to doenload the normal python package for OpenWRT/Carambola and extract the Termios.so. Then I copied it to the appropriate folder on the Carambola.
I did the same for the other standard modules (and dependencies) I needed for this project. (actually I ended up being lazy and just copying the entire standard modules folder to the USB flash disk and adding the include path in the python programm I wrote at runtime)

Anyway, following a list of the modules I used on the Carambola side of things:

os, sys, time (included in python-mini)
Queue, serial
from SocketServer : BaseRequestHandler, ThreadingTCPServer, ThreadingUDPServer

The entire server runs on 486 lines of code (as you can see that includes threaded UDP and TCP Servers as well as the whole serial communication protocol).

The PC Programm for displaying the stream and controlling the tank/displaying sensor data (like GPS) was more of a quick hack, since I only needed to test that the server works before I moved on to learning Java for Android.

It uses the following Modules:

Tkinter (part of the standard python distribution on all platforms, except Linux where it's a seperate package most of the time)
sys, os, time, Queue, threading, httplib, StringIO, socket (all part of the standard distribution)
pygame (2D game related library, used for rendering the mjpg stream)

Interestingly the Client Software, although havin to perform the potentially more complex task of handling the mjpg stream and the GUI, runs on only 390 lines of code. (there's still a lot of garbage in there, probably closer to 290 lines of code without that)

Everything works fine so far, except I'm thinking about switching from UDP to TCP for the movement controls, as WiFi is inherently prone for UDP packet loss (and since UDP is a connection less protocol which makes it so great for bombarding a server with lots of individual packets, those packets are lost for good, which means control commands sometimes don't get through properly). I'll have to do more network expermiments to be sure what the best course of action will be.
In the end I might have to go down the full TCP route anyway, since I plan to add 3G/UMTS support.

29 May 2012, 13:59

Joined: 22 May 2012, 21:23
Posts: 24
Waoo! Thank you very much for the reply! Now I have to digest all of that!

Talking about UDP and TCP, I know a little bit that problem as I'm actually an embedded software engineer and it happens that I work with communication.

Throught Wifi, it's really common to loose packet you are right. Now it depends on how do you manage the tank.
If you give order like "go straight" and the tank is going straight until you say "stop", yeah you better get a connected socket (ie TCP). But IMHO, if you just do like I do for now, you give order "go straight" and the tank goes straight as long as you give the order (ie the buttons is pressed), well, in case of socket drop, the tank will stop and nothing can happen to him. So the UDP socket might not be bad choice. Now, if you loose too much packet, the tank might also saccade... :?
So test will be really interresting ! I don't know if you know that but in TCP, the KEEP_ALIVE packet/option, might save yourself in some tricky situation where the socket drop without knowing why!

Good luck my friend, keep the good work updated here !

29 May 2012, 14:32

Joined: 14 May 2012, 15:48
Posts: 196
Good luck my friend, keep the good work updated here !

Thanks, I will :)

I originally intended to use UDP the way you described, but noticed that it quickly oversaturates the message queue between the UDP Server and the Serial port connection resulting in a serious control loss. So then I temporarily switched it to "only send a message for a changed button state". Which isn't really ideal though, as the Android app will user the touch-screen equivalent of analog control sticks (constantly sending the current value for those "control sticks" was the most obvious choice, the hardware controller is already designed for this proportional control scheme)...
So I guess I really need to work on my network protocol and timing for the control mechanism. Maybe implement a "first in last out" queue, that also flushes the message queue of a certain control (don't wanna flush the entire queue from all commands, since I could execute the drive forward command while completely losing the go left command and driving straight into a wall) command once the last command has been processed.

Ah well, it's easy to throw together a great sounding project, but it's hard to work out the details properly ;)

29 May 2012, 14:46

Joined: 14 May 2012, 15:48
Posts: 196
Oh well, seems like my real problem isn't the UDP communication at all.
I've implemented the idea from my previous post, implementing a LIFO Queue. It improved things a little bit. But everything started to work perfectly fine when I turned off reading in the sensor data from the serial Port.
After that controlling the drone over UDP commands was perfectly smooth, just as you'd want it to be.
So my problem resides with serial reads of sensor data, which seems to be taking up just enough time to cause control lags.
I guess that's not a problem of serial communication speed, as the control messages get through fast enough. I might have to look into speeding up the message generator in the propeller chip. Instead of updating the data when the request comes in I'll have to update the data continuously and then just spit out the existing results on request. Hopefully that'll improve things.
Otherwise I might have to open another hardware interface (maybe try the i2c on the carambola) to completely separate reading sensor data from writing control data. Well, I still got a few cores left unused in the Propeller, so that wouldn't be a problem (just seems dirty wasting interfaces like that).

EDIT: Scratch that last part, I'm gonna try something adventurous. I'll create two instances of the serial port, one for exclusive writing and one for exclusive reading. Simultaneous access to the serial port shouldn't be a problem as long as I don't try to write in both threads at the same time. The UDP Thread will get the exclusive writes, ensuring that every control command gets through in time. Control commands don't produce any ouput anyways, so the TCP Thread will get exclusive reads. The TCP Thread is handling the requests for sensor data. It can pass on those requests through the main thread into the UDP thread where the request is put out to the serial port along with the control commands. The TCP thread can wait the extra time on that sensor data (GPS updates like twice every second only, so that's more than enough time to pass along a message between three threads and a microcontroller).

29 May 2012, 22:26
Display posts from previous:  Sort by  
Reply to topic   [ 32 posts ]  Go to page 1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Protected by Anti-Spam ACP Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.