Remote Control Car

Post date: Sep 04, 2013 7:19:25 PM

The Remote Control Car is constructed as the Autonomous Lawnmower Project's (ALP) moving-platform, whereon the autonomous functions will eventually be tested. At this point in time, the Remote Control Car is only controllable through a remote laptop as demonstrated in the following video. However, as the project continues in the future, the Remote Control Car will eventually include other components.

The moving-platform is first switched on and then wirelessly controlled via my laptop. The red LED on the Remote Control Car indicates the XBee of the laptop and Remote Control Car are connected.

Hardware. Two main objects of interest in the video is, of course, the moving-platform and the laptop. The moving-platform consists of the Propeller Activity Board as the controlling embedded system, an XBee Module Series 1 as the source of wireless communication, 10 double-A Nick Metal-Hydride (NiMH) batteries as the power source (4 of which power the Propeller Activity Board and 6 power the servos), 4 VEX 3-wire Servos which directly moves the moving-platform, and the physical frame and wheels are from the Tumbler portion of the VEX Protobot Set. The Propeller Activity Board is a development board created by Parallax Inc., comprising of a socket dedicated to XBee modules, a socket for a microSD card from which instructions or other information can be read, a mounted breadboard, Analog-to-Digital (ADC) and Digital-to-Analog (DAC) converters, and other electronic components. Most importantly, though, the Propeller Activity Board is computationally driven by Parallax's P8X32A Microcontroller Unit (MCU), popularly referred to as the Propeller. The Propeller MCU lacks the conventional interrupt mechanics as most MCUs have for asynchronous applications. Instead, however, the Propeller employs 8-cores that can each execute in parallel. On the laptop side, the laptop is connected to another XBee Module Series 1. The device that interfaces the XBee Module to the laptop is the XBee USB Adapter.

The hardware block diagram graphically describes how the hardware interfaces with one another. The design, at this point, is simple, but I will build on the same block diagram as the project progresses. The blocks in the bold outline are the computational brains of the system.

Software. On the software side of the project, the laptop computer runs software developed in Java with NetBeans Integrated Development Environment (IDE) and C++ with Visual Studios 2010 IDE and the moving-platform runs software also developed in C++ with Parallax's SimpleIDE.

The GUI is developed in Java mostly because I know how to create GUIs much better in Java than in other computer programming languages. In addition, though, I find the programming skill required for writing software that uses a mouse and keyboard to be relatively simple compared to the other programming languages I know. In the Autonomous Lawnmower for Temple project (ALT), MATLAB was used, but programming in MATLAB proved difficult since the keyboard was hard to access (though, doable), not to mention object-oriented programming seems less intuitive in MATLAB (though, sill doable).

I won't get into any specific details regarding how the Graphical User Interface (GUI) is developed since the focus of the Remote Control Car project is on the wireless software and the software developed for the moving-platform. The GUI is developed with Java's Swing toolkit, and the access to the C++ library is done with the Java Native Interface (JNI). Although all the top level functions are called from the Java program, they are defined as C++ functions. Thus, the top level of the laptop's software is best described by the functions called from the C++ library.

This snippet of code describes the top level functions of the laptop's software.

Whenever the program is enabled, a setup function is called (i.e. Java_AutoMowJava_create) and then the functions dedicated for controlling the Remote Control Car's physical movement become callable (i.e., Java_AutoMowJava_move, _turn, and _stop). Whenever the program is disabled, a closing function (i.e. Java_AutoMowJava_destroy) is called and the functions for controlling the Remote Control Car are no longer callable. Behind the scenes, the create function first initializes the com port associated with the XBee USB Adapter and then sets up channels. I developed a channel-based system for accessing the XBee module to allow either different Windows API threads or Propeller MCU cores to wirelessly communicate with one another over the same device. On both the laptop and Remote Control side, the WirelessChannelLayer class is designed so that multiple channels can only access the XBee hardware one at a time and each channel has a small buffer that stores received data associated with the channel. As of now, one channel is dedicated to the user and another channel, the keep-alive-channel, is dedicated to checking to see whether or not the Remote Control Car's XBee can still communicate with the laptop's XBee. The keep-alive-channel, which runs in the background as a separate thread, has a greater importance on the Remote Control Car.

This snippet of code belongs to the Propeller MCU's top level on the Remote Control Car

Most of the C++ source code for the XBee-related software developed for the laptop, including the channel-based system encapsulated by the WirelessChannelLayer class, is nearly exactly the same. The only differences are, instead of utilizing threads and mutexes to make concurrency possible, the Propeller MCU employs multiple cores and "locks" to enable true parallel execution of software. Still, the initial function calls and object instantiations seen in the C++ library's setup function on the laptop are called the same way as in the top level of the software developed for the Remote Control Car's Propeller MCU (thus, they are not included in the snippet of code). After the setup functions for the Remote Control Car's XBee are called, the servos are initialized using the functions provided as part of the Propeller GCC libraries. It is within the main loop where all the servos' movements are triggered. However, the functions that map to the servos are only callable if the keep-alive-channel reports connectivity between the Remote Control Car's XBee and the laptop's XBee. If the keep-alive-channel instead reports there is no connection, the motors are continuously told to stop all movement. The reason, of course, is for cases during which the laptop or an XBee stops functioning for whatever reason. If a stop command from the laptop is not received by the Remote Control Car, the Remote Control Car may continue to move until either power is cut or communication is re-established.

This concludes my entry on the Remote Control Car project. For those who are interested in particular aspects of the project, such as the software or hardware, please let me know and I will keep this post updated. As of now, ALP will probably be on hold until I make significant progress in the Zynq Project. Much thanks to those who took the time to review what I had wrote and provide me with feedback.