Introduction

Creating graphics for latex can be a real pain. There are a number of different options for doing this, though none of them is completely ideal. If you’re comfortable using regular latex and generating DVI’s, then the pstricks package is a very powerful tool. If you prefer generating PDF (now an open standard) files (as I do) then the PGF/TikZ latex packages are a very powerful and can do just about everything… except that you have to code your graphics… which is a very slow iterative process. The GNU Diagramming tool Dia can create block diagrams and flow charts and can export either pstricks or tikz code. Inkscape is a much nicer user-oriented graphical vector drawing tool, but doesn’t have native support for for LaTex, and creating graphics including LaTeX math-mode is a real pain. In any case, I’ve found a number of situations where a figure like the following was pretty easy to do create in Inkscape.

Inkscape Figure for LaTeX

Getting the Fonts

In order to get the math font’s to look like they do in LaTeX, though, you need to have the font’s installed where Inkscape can find them. Unfortunately, LaTex uses type1 postscript fonts, while Inkscape can only find font’s that windows has installed in the system, which includes true-type or open-type fonts. Fortunately you can get the fonts for “Computer Modern” (Knuth’s Font uses as the default in LaTeX) from the TeX archives in these formats. Simply download these fonts, and install them in windows (drag them to C:/Windows/Fonts). The next time you run Inkscape, it will have these font’s available and you can use them in your pretty graphics.

Other Fonts

There are some other font’s that you’ll find used by latex that aren’t in OTF or TTF format though. The only (open-source) way I’ve found to convert type-1 font’s to OTF is through an ancient tool called Font-Forge. It’s an X-Windows program so you’ll have to install the Cygwin x-server, or, luckily, someone has ported it to MinGW (native Win32).

So, anyone who uses Doxygen to document their code knows that it’s pretty much the most amazing thing ever. Seriously, it’s awesome. One cool thing about it is the ability to reference external documentation. For instance, if you use a library in your code and you want to include the library’s documentation with your own. However, let’s say that (hypothetically of course) you’re an academic… and the code you write implements some theoretical design or model. In that case, you may actually want your documentation to reference a paper, or a report that you’ve written. Perhaps, even many such papers or reports.

The Problem

In particular, let’s say that you’re a grad student, in the process of writing a paper (and of course, you used LaTex… because, well, why wouldn’t you?) and you go and write some code to simulate or demonstrate some elements of that paper. In that case, some of your functions may implement certain equations. Some of your classes (if it’s object oriented) may implement certain models. For an example, lets say this is your paper:

Let’s also assume that you’ve been good, and have been documenting your code with Doxygen. Let’s say you had some c++ class that implemented your model and it’s definition looks something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

/**
 *  \file       CTheoreticalModel.h
 *  \author     Joe Author (jauthor@institute.edu)
 *  \date       Apr 17, 2010
 *  \brief      Definition file for CTheoreticalModel class
 */
 
#ifndef CTHEORETICALMODEL_H_
#define CTHEORETICALMODEL_H_
 
 
/**
 *  \brief  Theoretical Model derived in section 2, on page 1
 *
 *  This is a detailed description of the model
 */
class CTheoreticalModel
{
    private:
        double    m_alpha;    ///< [parameter] defined in equation 2.1
        double    m_beta;     ///< [parameter] defined in equation 2.2
 
    public:
        /**
         *  \brief      Construct a new model using the given parameters
         *  \param[in]  alpha   [parameter] defined in equation 2.1
         *  \param[in]  beta    [parameter] defined in equation 2.2
         */
        CTheoreticalModel( double alpha, double beta );
 
 
        /**
         *  \brief      calculates [some property] by implementing algorithm 2.1
         *              on page 1
         *  \return     [some property]
         */
        double algorithmA();
 
 
        /**
         *  \brief      updates the model by [some parameter] according to the
         *              dynamics of equation 2.4
         *  \param[in]  gamma   [parameter] defined in equation 2.3
         */
        void equationB( double gamma );
 
 
        /**
         *  \brief      tests [some parameter] against the model; implements
         *              equation 2.6
         *  \param[in]  theta   [some parameter] defined by equation 2.5
         */
        bool testC( double theta );
};
 
#endif /* CTHEORETICALMODEL_H_ */

Then the html documentation that doxygen will generate will look like this:

Now let’s say that you talk to your advisor and he suggests that maybe section 2 should come after section 3. Moreover, you add a bunch of content to section 1 so now all of the code for this model is on page five. So then you end up with this:

So now you have to go back and change all of the equation numbers and page references in your code. But wait, when we wrote our document we “\label{}“ed all of our equations, algorithms, and sections. Wouldn’t it be cool if we could just reference those in the comments? Doxygen exposes latex’s math mode for us to document inline equations. It uses latex to render the equations, and then uses dvipng to turn those into png images. Moreover, latex has the xr package, which allows us to reference labels from other documents. Lastly, the “\ref{}” command is valid inside math-mode. So we have all the tools we need, but there is one slight problem. In order to use the xr latex package, we need to include the “\externaldocument” command in the header of the document.

The solution

Now here’s the fun part. When Doxygen renders all of the equations, it does so by generating a single latex source file called “_formulas.tex“. We don’t have explicit access to modify the preamble of that source file, but we are allowed to add optional packages to the list of what is included. We do that by modifying the “EXTRA_PACKAGES” line of the doxyfile. For instance, if we edit the doxyfile like this:

1
2
3
4
5
6

...
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
# packages that should be included in the LaTeX output.
 
EXTRA_PACKAGES = amsmath xr amsfonts
...

then when doxygen generates _formulas.tex it will include in the preamble a list of includes like this

1
2
3

    \usepackage{amsmath}
    \usepackage{xr}
    \usepackage{amsfonts}

Note that Doxygen tokenizes the list of packages (parses it) at whitespace, and then takes each token and wraps it with “\usepackage{}”, inserting it into the header. We can hijack this method of input by making EXTRA_PACKAGES variable like this

1
2
3

...
EXTRA_PACKAGES = amsmath xr}\externaldocument[paper-]{dummy}% amsfonts
...

Then the preamble of _formulas.tex will look like this

1
2
3
4

    \usepackage{amsmath}
    \usepackage{amsfonts}
    \usepackage{xr}\externaldocument[paper-]{dummy}%}
    \usepackage{hyperref}

Note how we use a comment character (percent) to comment out the closing bracket that doxygen put’s around our ‘package’. Now we have an extra command in our preamble. If you haven’t looked up the xr documentation yet, this command means to look for a file called “dummy.aux” generated by latex. The package extracts all the labels from that file and appends “paper-” to the front of the label names. Now we can change our code documentation to look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

/**
 *  \file       CTheoreticalModel.h
 *  \author     Joe Author (jauthor@institute.edu)
 *  \date       Apr 17, 2010
 *  \brief      Definition file for CTheoreticalModel class
 */
 
#ifndef CTHEORETICALMODEL_H_
#define CTHEORETICALMODEL_H_
 
 
/**
 *  \brief  Theoretical Model derived in section \f$\ref{paper-sec:Model}\f$,
 *          page \f$\pageref{paper-sec:Model}\f$
 *
 *  This is a detailed description of the model
 */
class CTheoreticalModel
{
    private:
        double    m_alpha;    ///< [parameter] defined in equation \f$\ref{paper-eqn:alphaDef}\f$
        double    m_beta;     ///< [parameter] defined in equation \f$\ref{paper-eqn:betaDef}\f$
 
    public:
        /**
         *  \brief      Construct a new model using the given parameters
         *  \param[in]  alpha   [parameter] defined in equation
         *                      \f$\ref{paper-eqn:alphaDef}\f$
         *  \param[in]  beta    [parameter] defined in equation
         *                      \f$\ref{paper-eqn:betaDef}\f$
         */
        CTheoreticalModel( double alpha, double beta );
 
 
        /**
         *  \brief      calculates [some property] by implementing algorithm
         *              \f$\ref{paper-alg:SomeAlgorithm}\f$ on page
         *              \f$\pageref{paper-alg:SomeAlgorithm}\f$
         *  \return     [some property]
         */
        double algorithmA();
 
 
        /**
         *  \brief      updates the model by [some parameter] according to the
         *              dynamics of equation \f$\ref{paper-eqn:SomeEquation}\f$
         *              on page \f$\pageref{paper-eqn:SomeEquation}\f$
         *  \param[in]  gamma   [parameter] defined in equation
         *                      \f$\ref{paper-eqn:gammaDef}\f$
         */
        void equationB( double gamma );
 
 
        /**
         *  \brief      tests [some parameter] against the model; implements
         *              condition \f$\ref{paper-eqn:SomeCondition}\f$
         *  \param[in]  theta   [some parameter] defined by equation
         *                      \f$\ref{paper-eqn:thetaDef}\f$
         */
        bool testC( double theta );
};
 
#endif /* CTHEORETICALMODEL_H_ */

Now all we have to do is dump dummy.aux (generated when we build the paper using latex) into the html directory where doxygen is going to build _formulas.tex and then when we make the documentation it looks like this:

Sure, all the references are images… which isn’t particularly great, but it’s a lot better than having to go in and change the labels every time we make a change to the referenced document. Whenever writing a code and a referenced document are done in parallel, this could be quite a handy trick. If you want the html document to look a little more professional, add a package that will set the font to the same as the font set by your doxygen CSS stylesheet.

If you want to play around with the files used in this post, pick them up here: dummy.7z. Create the latex document with the following command.

1

latex dummy.tex

Then copy dummy.aux into the html directory.

1

cp dummy.aux html/

Then run doxygen

1

doxygen doxyfile

In relation to the TxDuino (somewhat documented here), I wrote a C++ class to ease the interfacing with the device. That code was posted here. In this post, I am sharing a program that can be used to easily discover and save the configuration of the saturation points of the different actuators on a vehicle. The program is written using the wxWidgets toolkit so *should* be compatible with any wx-supported operating system. Of course, at this point in time I still haven’t updated the TxDuino class with linux implementations yet, but hopefully that will happen soon.

The saturation points are the raw commands that correspond to the extreme edges of the actuators range. For instance, if the actuator is a servo, then the minimum saturation point is the minimum command that the servo can actually achieve. If a command lower than that is sent, then the servo will constantly jitter as it cannot actually achieve that rotation. By setting the saturation points, normalized commands (percentages) can be sent to the device using the TxDuino::setPercent() function.

A screenshot of the program in action is below:

Actuator Configuration Tester

You can connect to the device by entering the device name in the text field at the top and clicking “Connect” (or pressing enter). Once the device is connected (success or failure will be reported in the console at the bottom), then commands can start being sent. You can start sending commands by clicking “Continue” or stop at any time by clicking “Pause”. Note that “pausing” won’t stop your vehicle from doing something retarded, the vehicle’s actuators will just be stuck in the last commanded state. If the program is not paused, then every time you change one of the values in the spin controls, then that new value is sent as the current command.

To discover the value of the minimum saturation point of one of the actuators, start by clicking on the spin control for that channel, setting it to zero, and hitting enter (this makes the control think it has changed whether it has or not so the value is sent to that channel). If the actuator is saturated (on a servo, if it’s making noise and/or jittering but not correcting itself) then raise the value by one unit. Keep raising the value until the actuator is no longer saturated. Repeat for the max saturation point and the neutral point. The neutral point is the point corresponding to 0%. For a servo this is most likely near the center of it’s range. For a speed controller, it should be the same as the minimum saturation.

A windows binary of this program can be downloaded here: Tester .
The source can be downloaded here: TxDuino Actuator Configuration Tester.

In order to make interfacing with the TxDuino as easy as possible, I wrote a little c++ class to take care of all the heavy lifting. You connect to a TxDuino device by creating a TxDuino object. The constructor accepts a device name. In windows that looks like “\\.\COM8” (my arduino is installed on COM port 8). In linux it’ll look something like “/dev/ttyS2” except that I haven’t gotten around to implementing the linux part of this class yet.

The class, along with the supporting classes and test program are included here: TxDuino Class Source.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189

/**
 *  \file       TxDuino.h
 *  \date:      Oct 27, 2009
 *  \brief:
 *
 *  detail:
 */
 
#ifndef CTXDUINO_H_
#define CTXDUINO_H_
 
 
#include <vector>
#include <string>
 
#include "types.h"
 
 
namespace txduino
{
 
 
/**
 *  \brief  operating system dependendant implementation structure
 */
struct STxDuinoImpl;
 
/**
 *  \brief Class encapsulating the interface / API for communicating with one
 *  TxDuino device. The TxDuino sends a standard RC PPM signal encoding
 *  commands for up to 8 PWM channels (servos, engine controllers).
 *
 *  The magnitude of each channel is divided into 250 discrete segments.
 *  Exactly how those segments are interpreted by the actuators is determined
 *  by the configuration of this object.
 *
 *  note: channels are zero indexed
 *
 *  \todo   add a constructor that accepts a csv file with the saturations and
 *          neutral points that can be generated from the test program
 */
class CTxDuino
{
    private:
        STxDuinoImpl*   m_osInfo;   /// pointer to os-dependant implementation
        std::string     m_devName;  /// system device name,
                                    /// i.e. "\\.\COM2", "/dev/tty2"
 
        u8          m_chan      [9];    /// value for each channel [0,250]
        u8          m_neutral   [8];    /// the "center" for each actuator
        u8          m_minsat    [8];    /// the minimum value for each channel
        u8          m_maxsat    [8];    /// the maximum value for each channel
 
 
    public:
        /**
         *  \brief  Constructs a new TxDuino object serving as an interface
         *          into on particular TxDuino device.
         *  \param  strDevice   device string, i.e. "\\.\COM2", "/dev/tty2"
         */
        CTxDuino( std::string strDevice );
 
 
        /**
         *  \brief  cleans up OS resources reserved for this serial connection
         */
        virtual ~CTxDuino();
 
 
        /**
         *  \brief  sends the current channel definitions to the device
         */
        void send();
 
 
        /**
         *  \brief  sets the value of an actuator as a percent of it's viable
         *          range.
         *  \param  chan        the channel to set
         *  \param  percent     -100% < percent < 100%; value to set channel to
         */
        void setPercent( s32 chan, f64 percent );
 
 
        /**
         *  \brief  returns the percent value the indicated actuator is set to,
         *          note: if the neutral point is equal to one of the saturation
         *          points this value may be unreliable
         *  \param  chan        the channel to get
         *  \return percent value of actuator on indicated channel
         */
        f64 getPercent( s32 chan );
 
 
        /**
         *  \brief  sets the raw value of the actuator pulse width
         *  \param  chan        the channel to set
         *  \param  value      0 < value < 250; value to set channel to
         */
        void setRaw( s32 chan, u8 value );
 
 
        /**
         *  \brief  returns the raw value the indicated actuator is set to
         *  \param  chan        the channel to get
         *  \return a value between 0 and 250 indicated the pulse length for
         *          that actuator (multiply by 4us and add 700us to get the
         *          actual pulse length)
         */
        u8 getRaw( s32 chan );
 
 
 
 
        /**
         *  \brief  sets the raw value of the actuator pulse width corresponding
         *          to a neutral state of that actuator
         *  \param  chan        the channel to set
         *  \param  value      0 < value < 250; value to set channel to
         */
        void setNeutral( s32 chan, u8 value );
 
 
        /**
         *  \brief  returns the raw value corresponding to a neutral state of
         *          the indicated actuator
         *  \param  chan        the channel to get
         *  \return a value between 0 and 250 indicated the pulse length for
         *          that actuator (multiply by 4us and add 700us to get the
         *          actual pulse length)
         */
        u8 getNeutral( s32 chan );
 
 
 
 
        /**
         *  \brief  sets the raw value of the actuator pulse width corresponding
         *          to the minimum state of the indicated actuator
         *  \param  chan        the channel to set
         *  \param  value      0 < value < 250; value to set channel to
         */
        void setMinSat( s32 chan, u8 value );
 
 
        /**
         *  \brief  returns the raw value corresponding to a minimum state of
         *          the indicated actuator
         *  \param  chan        the channel to get
         *  \return a value between 0 and 250 indicated the pulse length for
         *          that actuator (multiply by 4us and add 700us to get the
         *          actual pulse length)
         */
        u8 getMinSat( s32 chan );
 
 
 
 
        /**
         *  \brief  sets the raw value of the actuator pulse width corresponding
         *          to the maximum state of the indicated actuator
         *  \param  chan        the channel to set
         *  \param  value      0 < value < 250; value to set channel to
         */
        void setMaxSat( s32 chan, u8 value );
 
 
        /**
         *  \brief  returns the raw value corresponding to a maximum state of
         *          the indicated actuator
         *  \param  chan        the channel to get
         *  \return a value between 0 and 250 indicated the pulse length for
         *          that actuator (multiply by 4us and add 700us to get the
         *          actual pulse length)
         */
        u8 getMaxSat( s32 chan );
 
 
        /**
         *  \brief  return the device name that was used to connect to this
         *          txduino
         */
        std::string getName();
 
};
 
}
 
#endif /* CTXDUINO_H_ */

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445

/**
 *  \file       CTxDuino.cpp
 *  \date:      Oct 27, 2009
 *  \brief:
 *
 *  detail:
 */
 
#include "CTxDuino.h"
#include "compile.h"
 
#include <iostream>
#include <iomanip>
#include <sstream>
#include <cmath>
 
#include "IllegalArgumentException.h"
#include "IOException.h"
 
#ifdef TXD_MINGW
#include <windows.h>
#endif
 
namespace txduino
{
 
 
 
#ifdef TXD_MINGW
struct STxDuinoImpl
{
    HANDLE hComPort;    /// handle to the opened COM device
};
#endif
 
 
#ifdef TXD_LINUX
struct STxDuinoImpl
{
    FILE hSerialFile;
};
#endif
 
 
 
 
 
 
/**
 *  The initial state of the individual actuators is initialized as follows
 *
 *  \verbatim
 *      minimum saturation: 0
 *                 neutral: 125
 *      maximum saturation: 250
 *                   value: 125
 *  \endverbatim
 *
 *  Note that this is probably not appropriate for your system. Many of the
 *  servos that we've used have minimum saturations around 10 and maximum
 *  saturations around 240. Use the actuator test program to determine what
 *  these values should be.
 */
CTxDuino::CTxDuino( std::string strDevice )
{
    using std::cout;
    using std::endl;
    using std::stringstream;
 
    // intiialize all the arrays
    for( int i=0; i < 8; i++ )
    {
        m_chan      [i] = 125;
        m_minsat    [i] = 0;
        m_maxsat    [i] = 250;
        m_neutral   [i] = 125;
    }
 
    // stop byte
    m_chan[8]   = 0xFF;
 
    // initialize the OS dependant information
    m_osInfo    = new STxDuinoImpl();
 
 
/* ----------------------------------------------------------------------------
 * Windows Specific Implementation:
 * ---------------------------------------------------------------------------*/
 
#ifdef TXD_MINGW
    // open the file using the windows API
    m_osInfo->hComPort  =
    CreateFile( strDevice.c_str(),          // file name
        GENERIC_READ | GENERIC_WRITE,       // access mode: read and write
        FILE_SHARE_READ|FILE_SHARE_WRITE,   // (sharing)
        NULL,                               // (security) 0: none
        OPEN_EXISTING,                      // (creation) i.e. don't make it
        0,                                  // (overlapped operation)
        NULL);                              // no template file
 
    // check to make sure the file open succeeded
    if( m_osInfo->hComPort == INVALID_HANDLE_VALUE )
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid Device Name: " << strDevice;
        throw IllegalArgumentException(message.str());
    }
 
    // get the current settings on the com port
    DCB dcb;
    GetCommState( m_osInfo->hComPort, &dcb );
 
    // change the settings, the TxDuino uses a BAUD rate of 9600
    dcb.fBinary     =   1;
    dcb.BaudRate    =   CBR_9600;
    dcb.Parity      =   NOPARITY;
    dcb.ByteSize    =   8;
    dcb.StopBits    =   ONESTOPBIT;
 
    // set the new settings for the port
    SetCommState( m_osInfo->hComPort, &dcb );
#endif
 
 
}
 
 
 
CTxDuino::~CTxDuino()
{
 
/* ----------------------------------------------------------------------------
 * Windows Specific Implementation:
 * ---------------------------------------------------------------------------*/
 
#ifdef TXD_MINGW
    // close the device if it's open
    if( m_osInfo->hComPort != INVALID_HANDLE_VALUE )
        CloseHandle( m_osInfo->hComPort );
#endif
 
delete m_osInfo;
 
}
 
 
 
void CTxDuino::send()
{
    using std::stringstream;
 
 
    // ensure that the last byte of the packet is the stop byte
    m_chan[8] = 0xFF;
 
 
/* ----------------------------------------------------------------------------
 * Windows Specific Implementation:
 * ---------------------------------------------------------------------------*/
 
#ifdef TXD_MINGW
    DWORD bytesWritten;
 
    BOOL retVal =
    WriteFile(  m_osInfo->hComPort, // output handle
                m_chan,             // buffer of bytes to send
                9,                  // number of bytes to send from buffer
                &bytesWritten,      // pointer to a word that receives number of
                                    // bytes written
                NULL);              // pointer to an OVERLAPPED struct
 
    if( bytesWritten != 9 )
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Bytes written to device less than expected: "
                << bytesWritten << ", expecting 9";
        throw IOException(message.str());
    }
 
    if( retVal == 0 )
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Writing to device failed; error code: " << GetLastError();
        throw IOException(message.str());
    }
#endif
 
}
 
 
 
/**
 *  If the percent is positive, the raw value is calculated as follows
 *
 *  \verbatim
 *      raw = neutral + (max - neutral) * percent
 *  \endverbatim
 *
 *  if the percent is negative, the raw value is calculated as follows
 *
 *  \verbatim
 *      raw = neutral - (neutral - min) * percent
 *  \endverbatim
 */
void CTxDuino::setPercent( s32 chan, f64 percent )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    if(percent > 0)
    {
        m_chan[chan] = (u8) (m_neutral[chan] +
                    ( m_maxsat[chan] - m_neutral[chan]) * percent );
    }
 
    else
    {
        m_chan[chan] = (u8) (m_neutral[chan] -
                    ( m_minsat[chan] - m_neutral[chan]) * percent );
    }
}
 
 
 
/**
 *  If the value is strictly less than the neutral value then the percent value
 *  is calculated by
 *
 *  \verbatim
 *      percent = -( neutral - value ) / (neutral - min);
 *  \endverbatim
 *
 *  If the value is strictly greater than the neutral value then the percent
 *  value is calculated by
 *
 *  \verbatim
 *      percent = ( value - neutral ) / (max - neutral);
 *  \endverbatim
 *
 *  If the value is equal to the neutral value then the percent value is zero.
 */
f64 CTxDuino::getPercent( s32 chan )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    if( m_chan[chan] < m_neutral[chan] )
    {
        return (double)(-(m_neutral[chan] - m_chan[chan])) /
                    (m_neutral[chan] - m_minsat[chan]);
    }
 
    else if( m_chan[chan] > m_neutral[chan] )
    {
        return (double)(m_chan[chan] - m_neutral[chan]) /
                    (m_maxsat[chan] - m_neutral[chan]);
    }
 
    else
    {
        return 0.0;
    }
}
 
 
 
void CTxDuino::setRaw( s32 chan, u8 value )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    if(value > 250)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid value: " << value << HERE
                << "valid channels are 0-250";
    }
 
    m_chan[chan] = value;
}
 
 
 
u8 CTxDuino::getRaw( s32 chan )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    return m_chan[chan];
}
 
 
 
void CTxDuino::setNeutral( s32 chan, u8 value )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    if(value > 250)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid value: " << value << HERE
                << "valid channels are 0-250";
    }
 
    m_neutral[chan] = value;
}
 
 
 
u8 CTxDuino::getNeutral( s32 chan )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    return m_neutral[chan];
}
 
 
 
void CTxDuino::setMinSat( s32 chan, u8 value )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    if(value > 250)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid value: " << value << HERE
                << "valid channels are 0-250";
    }
 
    m_minsat[chan] = value;
}
 
 
 
u8 CTxDuino::getMinSat( s32 chan )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    return m_minsat[chan];
}
 
 
 
void CTxDuino::setMaxSat( s32 chan, u8 value )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    if(value > 250)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid value: " << value << HERE
                << "valid channels are 0-250";
    }
 
    m_maxsat[chan] = value;
}
 
 
 
u8 CTxDuino::getMaxSat( s32 chan )
{
    using std::stringstream;
 
    if(chan < 0 || chan > 7)
    {
        stringstream message( stringstream::in | stringstream::out );
        message << "Invalid channel number: " << chan << HERE
                << "valid channels are 0-7";
    }
 
    return m_maxsat[chan];
}
 
 
 
std::string CTxDuino::getName()
{
    return m_devName;
}
 
 
 
 
 
 
}

A re-write of the serialTest.exe program that sends sinusoidal commands to the plane using this new class demonstrates its use.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

/**
 * 	\file		serialTest.cpp
 *  \date:      Oct 27, 2009
 *  \brief:
 *
 *  detail:
 *  This is a simple test program that demonstrates how to connect to and
 *  write commands to the arduino transmitter interface using windows.
 *
 *  the TxDuino is an interface into the futaba FP-TP-FM transmitter module,
 *  which accepts an RC PPM input. This signal contains a maximum of 8
 *  servo channels.
 */
 
#include <iostream>
#include <iomanip>
#include <cmath>
 
#include "CTxDuino.h"
#include "constants.h"
 
using namespace std;
using namespace txduino;
 
int main( int argc, char** argv )
{
    // check to ensure that the command line included a device to open
    if( argc < 2 )
    {
        cout << "Usage: serialTest.exe [Device Name]\n"
                "   where [Device Name] is the name of the COM port file on\n "
                "   windows (i.e. \\\\.\\COM8), or the name of the serial\n "
                "   device on *nix (i.e. /dev/tty8)\n" << endl;
 
        return -1;
    }
 
    // grab a pointer to the device to open
    char*       strDevName = argv[1];
 
    // create the txduino device
    CTxDuino tx(strDevName);
 
    // send a sinusoidal input on all channels (except for channel 3, which is
    // usually the throttle) for 10 seconds
    for(int i=0; i < 1000; i++)
    {
        for(int j=0; j < 8; j++)
            tx.setRaw(j, (unsigned char)
                            (125.0 + 75.0 * sin( 2.0 * PI * i / 100.0 )) );
 
        tx.setRaw(2, 0);
 
        for(int j=0; j < 8; j++)
            cout << setw(3) << (int)tx.getRaw(j) << " | ";
        cout << endl;
 
        tx.send();
 
#ifdef TXD_MIGNW
        Sleep(1);
#endif
 
#ifdef TXD_LINUX
        usleep(0.001);
#endif
    }
 
 
    return 0;
}

In our lab we have some very light weight foam aircraft that we do control work with. In order to keep the weight down, we use micro RC receivers that generate PWM signals for each of the servos that deflect one of three control surfaces: ailerons, elevator, and rudder. Note that both ailerons are linked and are together controlled by a single servo (a common setup for these lightweight foam planes). A PWM signal is also sent to control the throttle of the propeller. The glowing little spheres are reflective features to aid in motion capture which we use for estimation of the vehicle’s state.

One of our 'lil baby airplanes

The trick, however, is to get our control codes, running on a PC somewhere in the room, to actually change the deflection of the airplane’s control surfaces, or the throttle of the propeller.

The TxDuino project aims to create a single device that allows a PC to control an RC vehicle. At the time of starting this project, the only option for doing this was a device from here that could be plugged into the trainer port of a transmitter. An arduino has been used to achieve this same setup as described here. Going through the handheld transmitter, however, is a huge hassle for a number of reasons so I set out to create a simple single device that could accomplish this. As it turns out, so did the guys at Tom’s RC, their solution being this guy here. Anyway, since the work is done, I’ll share the results.

The easiest way that I figured to pull this off is to work with a modular RC transmitter, and interface directly with the module. For instance this is a transmitter

Futaba Modular Transmitter

And this is the module that plugs into the back of the transmitter

the FP-TP-FM Transmitter Module

The handheld part creates some kind of signal that it sends to the module, which does something, and then sends something else to the antenna. If I can figure out how to recreate that signal, then the “somethings” aren’t very important. The modules are cheap enough and easy enough to find that there isn’t much of a need to re-engineer that part.

To begin with, I needed to do some investigation. There are 5 pins on the back of the transmitter. It was easy enough by tracing the module circuit to find the source, ground, and RF out (antenna) pins, but what about the other two? I was hoping one of them was the control signal in a not too esoteric form, and I had no idea what the last would be. I managed to find the control signal with a little probing. Here is a little video showing the transmitter (Tx) hooked up to the module, via some wires with alligator clips which made it easy to investigate things.

After figuring our a little of what was going on, I found this forum post that had a pretty good discussion of the pinouts on this particular module. In particular, this post I found to be accurate and helpful.

Basically, looking at the back of the transmitter (or the top of the module, when the cover is off) the pins are

        1   2   3   4   5
        .   .   .   .   .
 
     left side
     #1 PPM
     #2 V+
     #3 RF check
     #4 ground
     #5 RF out
     right side

Of particular importance is the note on that post that the hand-held part is actually pulling the line low to make the pulses, and that the PPM line is at 2.5 volts.

I found a description of the PPM signal here. While the measurements I made using the oscilloscope did not match the information on that page exactly (I measured a 4us pulse between channels), using the signal description from that page has had good results. The details of the PPM frame are repeated here.

• complete PPM-Frame has a length of 22.5 ms.
• consists of an overlong start segment combined with 8 analog channels.
• stop pulse of 0.3 ms follows every channel’s impulse.
• The length of a channel’s impulse ranges from 0.7ms to 1.7 ms

Below is a video of the PPM signal from the transmitter. You can see the impulse length for each channel changes as I manipulate the control sticks on the handheld part of the transmitter. I apologize for the poor light sensing on my crappy little digital camera. Also, note that channel 5 jumps up and down because it is a flip switch (see the photo above) and only has two possible positions.

Ok, now that I know what is happening, I need a way to recreate that PPM signal using some kind of device that I can connect to my PC. Hey, the arduino is easy to develop with, comes with a USB controller, and has a nice software library that handles the PC interface stack. It’s also built around an Atmel microcontroller (my decimila specifically uses a ATmega168L) which has some pretty sophisticated features. It runs at 16Mhz, has three timers that can be used for generating interrupts, and comes with a (relatively) standard C / C++ compiler for writing code. Furthermore, the arduino’s bootloader means that I don’t even have to worry about messing with a programmer to get something up and running.

I wont go into all the gory details of the TxDuino design, but I will point out some of the relevant considerations.

The 168L has three timers. Timer1 is a 16-bit counter, Timer0 and Timer2 are 8-bit counters. Timers 0 and 1 share a prescaler, Timer2 has it’s own. The prescaler is a component that reduces the update rate of the timer, so we can scale the 16Mhz system clock to some fraction of it’s rate. Using an 8-bit counter would be extremely limiting because scaling the clock down enough that the counter capacity is sufficient would provide a counter resolution that is too coarse for the fine control we need to generate our waveform. This means I want to use Timer1. However, Timer0 is used by the serial stack. I want to be able to send commands from the PC to the TxDuino which will require use of the serial interface. Thus, the serial baud rate will dictate the prescale factor used by Timer0, and thus used by Timer1… meaning that my choices are limited to whatever the serial stack allows.

A simple arduino test program, however, quells this dilemma.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

 int inByte = 0;         // incoming serial byte
 
 //define the Timer1 overflow interrupt service routine
 ISR(TIMER1_OVF_vect) 
 {
    // print out the current value of the timer control register B which
    // contains the timer prescale value, set when the serial BAUD rate 
    // is defined
    Serial.print("Timer1: ");
    Serial.print(TCCR1B, HEX);
    Serial.print("\r\n");
 }
 
 
 void setup()
 {
   // set Timer1 to operate in "normal" mode
   TCCR1A = 0;
 
   // activate Timer1 overflow interrupt 
   TIMSK1 = 1 << TOIE1;
 
   // start serial port at 9600 bps:
   Serial.begin(9600);
 }
 
 void loop()
 {
   // if we get a valid byte, read analog ins:
   if (Serial.available() > 0) {
     // get incoming byte:
     inByte = Serial.read();
     Serial.print(inByte, BYTE);
     Serial.print("\r\n");
   }
 }

This program sets the serial baud rate to 9600 bits/sec, and then prints out the value of the Timer1 control register. A subset of the bits in that register indicate what the prescaler is set to, and thus what the prescale factor is. Running this program, and looking at the datasheet, I was able to determine that the prescale factor is set to 64. This means that the timer resolution for Timer1 is

And the 16-bit timer has a range of zero to

Since our frame length is 22.5 ms, we have plenty of range to work with. Also, the range on the individual servo channels is 1000 us, so that gives us 1000/4 = 250 possible steps for each channel (251 possible discrete positions). That gives us a resolution of better than +/- 0.5% for each channel, which is quite acceptable.

Also, since the PPM signal pulls the voltage on the line low, we cannot just use digitalWrite() like we usually do when writing to a pin with the arduino. Instead, we need a way to drive the voltage to zero when we want to pull the line low, and a way to basically “do nothing” when we want the line high. We can do this by setting the pin voltage to LOW, and then switching between INPUT and OUTPUT using pinMode()

The last consideration is the serial packet format. I decided to keep things simple. Since each channel can only have 251 possible values, I used an unsigned 8-bit integer ( possible values for an 8-bit number) for each channel, with values 0-250, and reserving 0xFF (255 in decimal) as a end-of-packet identifier.

Here is a little test code to demonstrate the use of pinMode() to set the voltage of the line high / lo. It listens for either an 'a' or 'b' character over serial, and sets the line high or low depending on what is sent. If you want to play with this, you can use the terminal from within the Arduino software to send the commands.

int inByte      = 0;    // incoming serial byte
int ppmPin      = 2;    // pin to make the waveform on
 
 
// to setup the device, we will initialize all the channels, and initialize the
// timer settings
void setup()
{
    // start serial port at 9600 bps, note that this also sets the Timer1
    // prescaler, so we need to ensure that we don't change it later; a test 
    // using a previous program showed that 9600 baud set the prescaler to 64
    // or the Timer1 control register B to 0x03.
    Serial.begin(9600);
 
    // we configure the signal pin as an input; not that the signal actually is
    // an input but we modify the signal by pulling it low when we need to
    pinMode(ppmPin, INPUT);
 
 
    // then we set the inital state of the pin to be low
    digitalWrite(ppmPin, LOW);
}
 
 
// the main routine monitors the serial port, and on receipt of a completed 
// packet will recalculate the compare points for the specified signal
void loop()
{
    // if there's a byte available on the serial port, then read it in
    if (Serial.available() > 0)
    {
        // get incoming byte
        inByte = Serial.read(); 
 
        switch(inByte)
        {
            case 'a':
                pinMode(ppmPin, OUTPUT);
                Serial.print("setting pin low\n");
                break;
 
            case 'b':
                pinMode(ppmPin, INPUT);
                Serial.print("setting pin high\n");
                break;
 
            default:
                break;
        }
    }
}

Here is a photo of the arduino hooked up with a resistor from the PPM pin to ground which allows me to look at the signal as I’m testing. The wire from the right side of the resistor to the ground terminal on the arduino is hidden behind the black probe. The other things connected to the breadboard are the transmitter module (the thing in the metal shield), and the back circuit board from the transmitter (the green thing; the pins from that board are plugged into the breadboard). The red thing is the battery for the transmitter.

Arduino Test Setup

Well that’s pretty much it as far as background and design. Here is the final code that I used to generate the desired waveform. I wont describe it much here since it’s heavily commented already. Basically it uses two compare match interrupts with Timer1. The two interrupts leap-frog each other and signal either a rising edge or a falling edge. The counter is not cleared when the interrupts are serviced, until the last falling edge is serviced.

int inByte      = 0;    // incoming serial byte
int ppmPin      = 2;    // pin to make the waveform on
int chan[8];            // 8 channels encoded as 250 * (percent range)
 
int compA[9];           // 9 compare points for Timer1
int compB[9];           // 9 compare points for Timer2
int iCompA      = 0;    // compare point index for currently active
int iCompB      = 0;    // compare point index for currently active
 
 
// the 0xFF byte will serve as a packet delimeter, we don't want to read
// garbage from the serial so we'll start as soon as we get one of those but
// not before
int bDelimReceived  = 0;
 
// we don't want to write to any of the compare registers unless we have to 
// so we'll only do so at the end of a frame if that frame involved a change
// in the current signal
int bSignalChanged  = 0;
 
// index for which channel is next to read in
int iChan = 0;
 
 
// define the Timer1 compare match interrupt service routine for the rising 
// edge
ISR(TIMER1_COMPA_vect) 
{
    // to set the line high, we switch the pin mode to "INPUT"
    pinMode(ppmPin, INPUT);
 
 
    // if this is not the last rising edge
    if( iCompA < 8 )
    {
        // then we change the compare register to issue an interrupt at the next
        // rising edge, by incrementing the compare point counter
        iCompA++;
 
        // and then setting the compare register
        OCR1A = compA[iCompA];
    }
 
    // if this is the last rising edge then we need to set the compare
    // register to be at the time of the rising edge following the start 
    // frame
    else
    {
        // first, if the signal has changed since while writing the last frame
        // then we need to update the compare points
        if( bSignalChanged )
        {
            compA[0] = 3550;
            for(int i = 0; i < 8; i++)
                compA[0] -= chan[i];
 
            // the end of the first pulse is 75 ticks (300us) after that
            compB[0] = compA[0] + 75;
 
            // and then the rest of the compare points depend on the value of
            // each channel
            for(int i = 1; i < 9; i++ )
            {
                compA[i] = compB[i-1] + chan[i-1] + 175;
                compB[i] = compA[i] + 75;
            }
 
            bSignalChanged = 0;
        }
 
        // then we set the compare point to match the end of the start segment
        iCompA  = 0;
        OCR1A   = compA[0];
    }
 
}
 
// define the Timer1 compare match interrupt service routine for the falling 
// edge
ISR(TIMER1_COMPB_vect) 
{
    // to set the pin low we open the collector
    pinMode(ppmPin, OUTPUT);
 
 
    // if this is not the last falling edge
    if( iCompB < 8 )
    {
        // then we change the compare register to issue an interrupt at the next
        // rising edge, by incrementing the compare point counter
        iCompB++;
 
        // and then setting the compare register
        OCR1B = compB[iCompB];
    }
 
    // if this is the last falling edge
    else
    {
        // then we wrap around to the beginning
        iCompB=0;
 
        // and set the compare register
        OCR1B = compB[iCompB];
 
        // and we also need to reset the timer because this is the end of the 
        // frame
        TCNT1 = 0x00;
    }
 
}
 
 
 
 
 
 
// to setup the device, we will initialize all the channels, and initialize the
// timer settings
void setup()
{
    // initialize all eight channels to be at 125, or neutral
    for(int i=0; i < 8; i++)
        chan[i] = 125;
 
    // initialize the throttle to be "full left" which is actually "full stop"
    chan[2] = 0;
 
    // start serial port at 9600 bps, note that this also sets the Timer1
    // prescaler, so we need to ensure that we don't change it later; a test 
    // using a previous program showed that 9600 baud set the prescaler to 64
    // or the Timer1 control register B to 0x03.
    Serial.begin(9600);
 
    // set Timer1 to operate in "normal" Mode, and set the
    // prescaler to 64; the default mode is one of the PWM modes so we need to
    // set this
    TCCR1A = 0;
 
    // note: Timer0 and Timer1 share a prescaler, and Timer0 is used by the 
    // serial lines. Therefore, we cannot pick the value of the prescaler, 
    // rather it is determined by the baud rate we want. A simple program has 
    // shown that setting the baud rate to 9600 involves setting the prescaler 
    // to 64
 
    Serial.print("Timer Control Registers: \n");
    Serial.print("   A: 0x");
    Serial.print(TCCR1A, HEX);
    Serial.print("\n");
    Serial.print("   B: 0x");
    Serial.print(TCCR1B, HEX);
    Serial.print("\n");
 
    // set the Timer1 output compare register A to 3550 ticks, which corresponds 
    // to 14,200us with the prescale set to 64; the math goes like this: 
    //    with the prescaler set to 64, the Timer1 period is 64/16e6 = 4us
    //    want an interrupt issued after 22.5ms - 8*700us - 9*300us = 14,200us
    //    means we want an interrupt issued after 14,200/4 = 3550 ticks
    compA[0] = 3550;
    OCR1A = compA[0];
 
    // set Timer1 output compare register B to something 300us/4us = 75 ticks 
    // after the first compare point for timer A
    compB[0] = compA[0] + 75;
    OCR1B = compB[0];
 
    // we can go ahead and initialize all the other compare points as well, we
    // know that all the channels are set to zero, but I'll do this the long 
    // way because it'll match code that we use elsewhere in this program
    for(int i=1; i < 9; i++)
    {
        compA[i] = compB[i-1] + chan[i-1] + 175;
        compB[i] = compA[i] + 75;
    }
 
    // activate Timer1 output compare interrupt with compare register A and
    // compare register B by setting the Output Compare Interrupt Enable bits
    TIMSK1 = 1 << OCIE1A | 1 << OCIE1B;
 
 
    // we configure the signal pin as an input; not that the signal actually is
    // an input but we modify the signal by an open collector so to make the
    // signal high we enable a 20K pull-up resistor, and to make the signal 
    // low we open the collector
    pinMode(ppmPin, INPUT);
 
 
    // then we set the inital state of the pin to be low
    digitalWrite(ppmPin, LOW);
}
 
 
 
// the main routine monitors the serial port, and on receipt of a completed 
// packet will recalculate the compare points for the specified signal
void loop()
{
    // if there's a byte available on the serial port, then read it in
    while (Serial.available() > 0)
    {
        // get incoming byte
        inByte = Serial.read(); 
 
        // if the byte is a packet delimiter, then start recording the new 
        // packet by resetting the channel indexer
        if( inByte == 0xFF )
        {
            bDelimReceived  = 1;
            iChan           = 0;
        }
 
        // otherwise, if we've recieved at least one packet delimiter and the
        // current channel index is valid, then record the chanel value; 
        else if(bDelimReceived && iChan < 8)
        {
            // we can save some processing time by only updating the stored 
            // values if the incoming command has changed, so we'll condition
            // the calculations on the fact that the byte is different than
            // what is already stored
            if(inByte != chan[iChan])
            {
                // the protocol is defined to send values between 0 and 250 
                // inclusive, for 250 distinct values; the timing increment is 
                // between 0 and 250 so we simply store the value
                chan[iChan] = inByte;
 
                // since the signal changed, we need to raise the flag
                bSignalChanged = true;
            }
 
            // then we increment the channel index so that we're ready for 
            // the next byte that's sent
            iChan++;
        }
    }
}

In order to test this, I wrote this little program to send a sinusoidal input to the TxDuino. Note this code is specific to windows.

/**
 *  \file       serialTest.cpp
 *  \date:      Oct 27, 2009
 *  \brief:
 *
 *  detail:
 *  This is a simple test program that demonstrates how to connect to and
 *  write commands to the arduino transmitter interface using windows.
 *
 *  the TxDuino is an interface into the futaba FP-TP-FM transmitter module,
 *  which accepts an RC PPM input. This signal contains a maximum of 8
 *  servo channels.
 */
 
#include <iostream>
#include <iomanip>
#include <cmath>
#include <windows.h>
 
#define PI 3.14159265
 
int main( int argc, char** argv )
{
    using std::cout;
    using std::endl;
    using std::sin;
    using std::setw;
 
    // check to ensure that the command line included a device to open
    if( argc < 2 )
    {
        cout << "Usage: serialTest.exe [Device Name]\n"
                "   where [Device Name] is the name of the COM port file on\n "
                "   windows (i.e. \\\\.\\COM8), or the name of the serial\n "
                "   device on *nix (i.e. /dev/tty8)\n" << endl;
 
        return -1;
    }
 
    // grab a pointer to the device to open
    char*       strDevName = argv[1];
 
    // open the file using the windows API
    HANDLE      hComPort         =
    CreateFile( strDevName,
        GENERIC_READ | GENERIC_WRITE,       // access mode: read and write
        FILE_SHARE_READ|FILE_SHARE_WRITE,   // (sharing)
        NULL,                               // (security) 0: none
        OPEN_EXISTING,                      // (creation) i.e. don't make it
        0,                                  // (overlapped operation)
        NULL);                              // no template file
 
    // check to make sure the file open succeeded
    if( hComPort == INVALID_HANDLE_VALUE )
    {
        cout << "FATAL, Invalid device name: " << strDevName << "\n" << endl;
        return -2;
    }
 
    // get the current settings on the com port
    DCB dcb;
    GetCommState( hComPort, &dcb );
 
    // change the settings, the TxDuino uses a BAUD rate of 9600
    dcb.fBinary     =   1;
    dcb.BaudRate    =   CBR_9600;
    dcb.Parity      =   NOPARITY;
    dcb.ByteSize    =   8;
    dcb.StopBits    =   ONESTOPBIT;
 
    // set the new settings for the port
    SetCommState( hComPort, &dcb );
 
    // allocate the data buffer for sending over serial
    unsigned char data[9];
 
    // set the last byte to be the stop byte
    data[8] = 0xFF;
 
    // send a sinusoidal input on all channels (except for channel 3, which is
    // usually the throttle) for 10 seconds
    for(int i=0; i < 1000; i++)
    {
        for(int j=0; j < 8; j++)
            data[j] = (unsigned char)(125.0 + 75.0 * sin( 2.0 * PI * i / 100.0 ));
 
        data[2] = 0;
        data[8] = 0xFF;
 
        for(int j=0; j < 8; j++)
            cout << setw(3) << (int)data[j] << " | ";
        cout << endl;
 
 
 
        DWORD bytesWritten;
 
        BOOL retVal =
        WriteFile(  hComPort,       // output handle
                    data,           // buffer of bytes to send
                    9,              // number of bytes to send from buffer
                    &bytesWritten,  // pointer to a word that recieves number of
                                    // bytes written
                    NULL);          // pointer to an OVERLAPPED struct
 
        Sleep(1);
    }
 
 
    // close the device
    CloseHandle( hComPort );
 
    return 0;
}

The result of running this test program with the probes attached to the arduino is below.

Then I disconnected the line from the handheld part of the transmitter to the module, and connected the arduino’s output instead. This is shown below.

Arduino Replacing PPM from Handheld

By connecting the oscilloscope probes like this

Arduino Replacing PPM from Handheld with Probes

I was able to test the output, which is shown here.

Everything looks good at this point. The next thing to do is connect the voltage and ground pins of the module directly to the batter, they RF out line to the antenna, and the RF good line to ground through a resistor. This is shown below. Note the module is underneath the little breadboard.

TxDuino Prototype

And when running the test program, this is what the airplane does.

And here you can see the waveform generated by the completed TxDuino prototype

TxDuino Prototype Moneyshot

And that’s that.

These are my install notes for installing Ubuntu 9.04 on a Dell XPS with two NVIDIA 7900 GS cards in SLI and three monitors. Some of this is quite specific to this setup.

I did a no-cd install using the method described here

To install ubuntu without an install CD, I used the net installer. This was done on a system currently using windows XP, that already had an additional partition for linux.

The first thing I needed to do is download the linux kernel and the net installer. These are in two files linux.bin and initrd.gz. I got them from

http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/netboot/ubuntu-installer/i386/

For future versions, replace “jaunty” with the nickname of the current distribution. After downloading these two files in windows, I placed them in C:\boot. This directory didn't exist yet, so I created it.

    title Ubuntu Installer (hd0,1)
    kernel (hd0,1)/boot/linux vga=normal ramdisk_size=14972
    root=/dev/rd/1 rw
    initrd (hd0,1)/boot/initrd.gz

    C:\gldr="Start GRUB"

    sudo apt-get install ubuntu-desktop

    sudo gedit /etc/X11/xorg.conf

    sudo lspci | grep VGA

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 1.0  (buildd@palmer)  Sun Feb  1 20:21:04 UTC 2009
 
Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 1680 0
    Screen      1  "Screen1" RightOf "Screen0"
    Screen      2  "Screen2" LeftOf "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection
 
Section "Files"
EndSection
 
Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection
 
Section "ServerFlags"
    Option         "Xinerama" "1"
EndSection
 
Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection
 
Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection
 
Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor2"
    VendorName     "Unknown"
    ModelName      "DELL 2007WFP"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection
 
Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL 2007WFP"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection
 
Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "DELL 2007WFP"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection
 
Section "Device"
    Identifier     "Device2"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 7900 GS"
    BusID          "PCI:1:0:0"
    Screen          1
EndSection
 
Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 7900 GS"
    BusID          "PCI:1:0:0"
    Screen          0
EndSection
 
Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 7900 GS"
    BusID          "PCI:6:0:0"
EndSection
 
Section "Screen"
    Identifier     "Screen2"
    Device         "Device2"
    Monitor        "Monitor2"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "DFP-1: nvidia-auto-select +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
 
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "TwinViewXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DFP-0: nvidia-auto-select +0+0; DFP-0: 1600x1024 +0+0; DFP-0: 1440x900 +0+0; DFP-0: 1400x1050 +0+0; DFP-0: 1360x768 +0+0; DFP-0: 1360x768_60_0 +0+0; DFP-0: 1280x1024 +0+0; DFP-0: 1280x1024_60 +0+0; DFP-0: 1280x960 +0+0; DFP-0: 1152x864 +0+0; DFP-0: 1152x864_75_0 +0+0; DFP-0: 1152x864_70 +0+0; DFP-0: 1152x864_60 +0+0; DFP-0: 1024x768 +0+0; DFP-0: 1024x768_70 +0+0; DFP-0: 1024x768_60 +0+0; DFP-0: 960x600 +0+0; DFP-0: 960x540 +0+0; DFP-0: 896x672 +0+0; DFP-0: 840x525 +0+0; DFP-0: 840x525d70 +0+0; DFP-0: 840x525d60 +0+0; DFP-0: 840x525d60_0 +0+0; DFP-0: 832x624 +0+0; DFP-0: 800x600 +0+0; DFP-0: 800x600d60 +0+0; DFP-0: 800x600_75 +0+0; DFP-0: 800x600_72 +0+0; DFP-0: 800x600_60 +0+0; DFP-0: 800x600_56 +0+0; DFP-0: 800x512 +0+0; DFP-0: 720x450 +0+0; DFP-0: 680x384 +0+0; DFP-0: 680x384d60_0 +0+0; DFP-0: 640x512 +0+0; DFP-0: 640x512d60 +0+0; DFP-0: 640x480 +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
 
Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "nvidia-auto-select +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

    sudo apt-get install flash-nonfree

    # Flash also looks for /usr/lib/libesd.so.1
    sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1
 
    # Flash expects /tmp/.esd/socket to exist.
    sudo mkdir -p /tmp/.esd/
    sudo touch /tmp/.esd/socket