Note 3 Beaglebone Black: Getting OpenROV software to load .hex file into Arduino

I tried to upload a new Arduino program to the OpenROV cape using the software routines and the procedure outlined here.   On the cockpit display you select setup and then select a program to upload.   This program is a tar or zip compression of the Arduino source files.   The tar file is automatically expanded and then an attempt is made to build the hex file required by the Cape Arduino processor for upload.   The program threw an error which I traced to Arduino “ino” command line toolkit  program not being installed on the BBB.   I attempted to load ino onto the BBB as described here but that failed since a setuptool file for Python was missing.   This was installed  using

cd /

opkg install python-setuptools

Next, I reran  /ino/make install and now it couldn’t find the file py.compile.  This file apparenty is used in later versions of Python.  Searching opkg angstrom packages I found  python-compile_2.7.2-r3.17_armv7a.ipk\ which was downloaded to my pc and ssh to BBB.  I then used opkg service to install  it:

cd /

opkg install python-compile_2.7.2-r3.17_armv7a.ipk

ino seemed to be installed without errors.  Now tried to upload an Arduino file and of course more problems arose.  Seems that the ino makefile puts some of ino Python libraries in the wrong folder and when the ino calls were made several library functions were not found.    A search showed up this post which discussed the libraries and one of the comments to the post said that installing ino with Python commands works.  So I reinstalled ino using

cd /ino

python setup.py install

At last success!!   I ran another upload and got a little further until more errors showed up.    Here is the log file output:

Received ‘arduinofirmware-startupload’ for file: OpenROV_arduino.zip file: undefined going to install the uploaded file: OpenROV_arduino.zip unpack: build dir is /tmp/tmp.klu0me4aEo

Archive:  /opt/openrov/src/temp/OpenROV_arduino.zip    creating: OpenROV/   inflating: OpenROV/Command.cpp   inflating: OpenROV/Command.h   inflating: OpenROV/Device.cpp   inflating: OpenROV/Device.h   inflating: OpenROV/Motors.cpp   inflating: OpenROV/Motors.h   inflating: OpenROV/OpenROV.ino   inflating: OpenROV/Timer.cpp   inflating: OpenROV/Timer.h

unziped /opt/openrov/src/temp/OpenROV_arduino.zip in /tmp/tmp.klu0me4aEo/src

Unpacked firmware file into Searching for Board description file (boards.txt) … FAILED Board description file (boards.txt) not found. Searched in following places:   – /usr/local/share/arduino/hardware/arduino   – /usr/share/arduino/hardware/arduino

Compiled firmware in directory Closing serial connection for firmware upload Setting up uploader

Searching for Board description file (boards.txt) … FAILED Board description file (boards.txt) not found. Searched in following places:   – /usr/local/share/arduino/hardware/arduino   – /usr/share/arduino/hardware/arduino

Initiating arduino reset

/opt/openrov/linux/reset.sh: line 18: /sys/kernel/debug/omap_mux/gpmc_ad0: No such file or directory

upload failed, trying again. Searching for Board description file (boards.txt) … FAILED Board description file (boards.txt) not found. Searched in following places: – /usr/local/share/arduino/hardware/arduino – /usr/sh are/arduino/hardware/arduino

Initiating arduino reset

So it can’t find the board description and it is missing sys/kernel/debug/omap_mux/gpmc_ad0.   Back later when I figure this out.

 Ok… I’m back.   The missing board .txt file indicates that I need to install the Arduino IDE.   Normally ino uses AVERDUDE to boot up files to the Arduino but this is not installed on BBB.  I I tried to opkg averdude but Angstrom doesn’t have that .  However, all these files are in the Arduino IDE.  So I downloaded the  linux Arduino .tgz from here and ssh it to my root. Then installed this way

cd /usr/share

tar -xzf /arduino-1.0.5-linux32.tgz

Cool, now I have board.txt and averdude.

 

I fixed the gpmc_ad0 error by updating rc.local to make use of the .dt0 file overlay files supplied with Angstrom for BBB which are located in /lib/firmware.   Basically, I commented any reference to omap_mux and add code to set up UART1.  I will write a more detailed post on how to do this.

Using .hex file instead of .tar file of source

Why not build the .tar file on the host PC and then ask the OpenROV software to just upload the .hex file to the Arduino?   First, it took me a while to find where the Arduino puts the IDE.  Some said that holding the shift key down while compiling will show the file.   This didn’t seem to work so I just searched for the project name in temp files and found my .hex program in this build directory.

C:\Users\vamfun\AppData\Local\Temp\build802015884711230598.tmp

Next I will work on how to make the OpenROV uploader use the file in .hex format rather than the expected .tar format.  You still need ino installed to do the hex file upload.  But it could save a few steps in the overall upload procedure.

Note: Using a Line Sensor to Update Gyro Heading

The programming challenge for the 2013 Sack Attack game was attempted by team 1508 LancerBots fully autonomous robot. It uses gyro information to generate a navigation solution and then automatically sequences through several way points to solve the route sequences. Unfortunately as mentioned in earlier posts, the gyro drift causes heading corruption which then causes sacks to by slightly missed. One possible solution I am proposing is to use line sensors to update the gyro.
Figure 1 shows the geometry and formulas required to accomplish the update for a special case when the line is parallel to the truth x axis.    The coordinates used by 1508 were specifically chosen so all lines were parallel to either the x or y  axis.  This simplifies the update equations.

Simply put… when a line sensor event occurs, note the position error  with respect to the line (using the Nav coordinates) and divide it by the range from the origin.    This ratio is the gyro drift error in radians.

Error Contributions:  

Errors in the update equation can stem from errors in  the Nav initial condition (<.25 in, 1 deg heading) , encoder scaling (typically <1%) , encoder resolution(< .03 in) , line location measurements (<.25 in), line tape width (<.5 in) and Navigation solution numerical errors (sampling, round off).

The dominant error is the encoder scaling which can add up when the encoder has moved several hundred inches.   Lines can also be use to update the Nav  position solution so that these  errors remain less than 1% distance  from the field origin and not the total distance traveled by an encoder.   This error translates to about .6 deg of heading error from a gyro update.    So we should not expect much better than that from our updates.

General Case: Lines skew to the coordinate axes

To complete this note,  lets consider a more general line that is described by

c = a*x + b*y

where a,b and c are constants and again x and y are truth coordinates.   Now we have three unknowns (x,y and delta) and three equations:

x’ = x*cos(delta) + y*sin(delta)

y’ = -x*sin(delta) + y*cos(delta)

c = a*x + b*y

First we solve for x and y from the first two equations which is a simple inverse:

x = x’*cos(delta) – y’*sin(delta)

y = x’*sin(delta) + y’*cos(delta)

Make the small angle substitution gives

x = x’ – y’*delta

y = x’*delta + y’

Now substitute x and y into the line equation

c = a*(x’ – y’*delta) + b*(x’*delta + y’)

Now solve for delta

c -a*x’ – b*y’ = (b*x’ – a*y’)* delta

or

answer:

delta = (c -a*x’ – b*y’ )/(b*x’ – a*y’)

Check the special case above :  y = c, a = 0, b = 1

delta = (y – y’)/(x’)  : checks ok