Alternative Open Propeller Project #1: Android to Propeller BOE

John Abshier · 2014-01-29 09:04

I don't, won't, buy Apple. Not sure what I would do if given one. So this project will be Android to Propeller.

A little background about my strengths and many more weaknesses. A little over 50 years ago I started programming in FORTRAN with card on an IBM 1401. I did a little FORTRAN programming while getting an Aerospace Engineering degree in the late 1960's. Then I too a little over a decade off from programming to shoot cannons and fly helicopters. I then became an Operations Research Analyst, getting a MS in Computer Science with an emphasis in Operations Research. I have never been a professional programmer, but have programmed to do my job and also as a hobby (mainly robotics). In one organization we couldn't even admit to programming since that was reserved for the Directorate of Management Information Systems. I have programmed in various FORTRANs, BASICs, Pascal, PL/I, GPSS H, Simscript II.5, Java, Dynamo, C, AWK, Python, RCA machine language (hand assembled), IBM 360 assembler, and, of course, Spin and PASM. Also, although some may not consider them programming languages, SAS, SQL, Lotus 123, and Excel. I wonder if anyone recognizes all those languages without Google. Network programming experience: none, nada, zilch. Android programming experience: see network programming.

On the Prop side I will be using a BOE, because that is what I have. It should generalize to the Activity Bot. I will use Spin. I know it and Spin will save the time of learning the Prop specific idioms of C for the Prop.

Connection between Android devices and the Prop will be by a Digi XBee S6B. Bluetooth would be another option. A hard wired USB connection looks to be feasible but harder than I want to attack.

Android devices will be an old DroidX, a Galaxy S III, and old and new versions of Nexus 7.

I considered five languages for Android. MIT's App Inventor for Android, a graphical 12 Blocks, Scratch, like system would work over Bluetooth. Java, I looked at it and didn't want to go there. Basic4android is a commercial product ($59 with 2 months free upgrades) may be the best solution, especially if you want to use the USB connection. RFO BASIC! is a free dialect of Dartmouth BASIC that allows you to write and run programs directly on an Android device (http://laughton.com/basic/). I was tempted to use RFO BASIC! and may go back to it if time and interest level allow. I selected Processing mainly because it had more books listed on Amazon. Processing is to JAVA as Arduino code is to C/C++

John Abshier

John Abshier · 2014-01-29 09:17

For my first task I just wanted to talk to the XBee from my PC with Terra Term or putty. I managed to find my USB to XBee adapter and took off running. A man I used to work with said, "Things take longer than you expect even when you plan for them to take longer than you expect." He spoke truth. I downloaded and installed the latest version of XCTU. A disadvantage of the newest version is that it doesn't match the online help that uses the older version. I then proceeded to get frustrated. One thing that caused me problems is that XCTU uses hex for port numbers and the rest of the world used decimal. For a while I thought I may have bricked my XBee. XCTU wanted me to reset it and I didn't know how. At last I thought I had everything correct but things still didn't work. I quit to eat supper and watch the news. Came back upstairs and every thing was OK. I was able to talk to the XBee and back with Terra Term and putty. I downloaded a terminal app to the Nexus 7 and it was able to communicate with the XBee. I originally tried to set up the XBee with a static IP address, but eventually got things working with DHCP. But I didn't want the IP address to change. So I went into my router and assigned the IP address permanently to that IP address.

John Abshier

Ken Gracey · 2014-01-29 10:26

Hey John,

Would you like us to get behind your OPP Alt #1? This is what our involvement would mean:

- we rename your project OPP #2 (eventually these will become stickies, until there are too many and we'll find another alternative)
- we add a graphic to the first post
- we drive a little more attention to it, sometimes distributing hardware to key parties to help them move forward with the effort
- occasional check-in, and when it's mostly "done" we mark it as such and people can freely harvest the code, etc

Please let me know.

Ken Gracey
Parallax Inc.

John Abshier · 2014-01-29 11:40

Ken, being an OPP is OK. Once I get beyond the examples in the book(s), I will post my code. I don't need any hardware now. I have the XBee S6B, Prop BOE, servos, Ping, pots, switches, LEDs, etc. I have gotten over a major hump, installing Java SDK and Android SDK, and now have a program I wrote, actually copied, running on my Android devices. See next post. The book I am using has a chapter titled, Networking Devices with WiFi and one titled Peer-To-Peer Networking Using Bluetooth and WiFi Direct.

John Abshier

John Abshier · 2014-01-29 11:41

Another day of frustrations. Instructions that were valid in mid-November 2012 may not be so in January 2014. I downloaded the latest version of Processing and worked thru the hello world example. It uses the mouse/finger to draw ellipses. I am using the draft version of Rapid Android Development: Build Rich, Sensor-Based Applications with Processing (paper copy is dated May 2013 and in the mail). Then I wanted to change to Android mode. This became time consuming and was the source of frustrations. Some of the lessons learned: Even though there is only one user account on a machine (Windows 7) and it has administrator privileges, you must right click and select "run as administrator" for installation programs to run correctly. Some programs when they check for Java don't distinguish between Java Run Time Environment and Java SDK, required for Android SDK. Java SDK installer does not set the path. Windows path editor sucks! Android SDK Manager claims to install the Google USB driver but actually only downloads it to local disc. When following installation instructions on a web page, if it says install this using instructions on <link>, don't. Read the rest of the page because the linked to page may do something that the remainder of the original page says not to do. On later versions of Android, the Developers Tools are hidden. You must tap on Build Level seven times to unhide them. Parallax, Processing and others say, "We didn't include X because it makes the download too big." I would much rather have a big download (my ISP is Time Warner Cable) and just click install and everything gets installed. I have now found and installed everything and have successfully run the hello world program on Nexus 7, Droid X, and Galaxy S III. Processing and Android emulator start up times seem very slow and I have a Core 7 with a SSD.

I am tempted to jump to Part III--Using Peer-To-Peer Networking, but I will be not posting much as I work thru parts I and II, using the screen, sensors, and cameras.

John Abshier

jazzed · 2014-01-29 12:31

Try the attached instructions.

Warning, big download straight ahead! I had to download the 32-bit version since the 64-bit version didn't work with my JDK1.7. No idea why. Both packages are 0.5GB.

John Abshier · 2014-01-29 15:30

jazzed, thanks

John Abshier

John Abshier · 2014-01-29 15:48

I put the XBee on the Prop BOE and was able to send and receive over WiFi. But I am not satisfied. One, it sometimes takes upward of a minute to connect. Some of my problems may have been because I was impatient and bailed too early. Two, there is more jitter than I would like to have for controlling a robot. I had one program that wrote a number from the Prop to the terminal app every second. Sometimes it would hang for a while and then I would get 2 or 3 numbers real fast. This may be an inherent part of TCP/IP or my router, or my terminal app or me. I wonder if WiFi Direct is better? Would a classroom full of students all using the same router be worse? Here is a sample of the output from the Prop

john
Sending to WiFi 63

sam
Sending to WiFi 9

susan
Sending to WiFi 59

I don't know why there is a blank line between "Sending to WiFi num" and the name read.

John Abshier

John Abshier · 2014-02-01 15:04

I now have my taxes calculated, but have been unable to efile them. "Sorry, we are updating the system. Please try again in a few minutes." has now lasted for about 30 hours. At least I didn't have to mess with HealthCare.gov.

Today I finished Chapter 2: Working with the touch screen display. Several things didn't work because Processing changed. My paper copy of the book arrives Tuesday and is a few months later than the draft electronic copy I am using. Next chapter is motion and position sensors. Still a ways to go to get to WiFi and WiFi Direct.

John Abshier

Brian_B · 2014-02-02 17:19

Hey John,
I played around with the android SDK a couple of years ago and never did much with it. I fired it up today, updated some files ,sent a "hello Brian" program to my tab3 and it worked. I don't know how much help I will be for you, but at least I can test stuff on my end.

My Tab 3 is version 4.1 android.

Brian

LoopyByteloose · 2014-02-04 01:17

Hello all,
I am interested in using Android with a Cubieboard as an interface to the Propeller. While the Raspberry Pi might provide Android, or I could buy an Android pad of some sort, the Cubieboard offers me lower cost that the pad, and more power than the Raspberry Pi.

Is this going to be committed to an Xbee wireless interface, or are other alternatives being considered (Wifi, Bluetooth, and such)?

www.cubieboard.org

Roadster · 2014-02-04 05:02

I have used Basic4android and it is really easy to make android apps with it, I have make a few apps to connect to the propeller with it.

blue tooth to serial, OBC has played with this project

I used the usb library to connect to the propeller plug or it will work with any FTDI board

John Abshier · 2014-02-04 11:08

Continuing to learn Android programming. No power provided to Propeller lately. Partially finished the chapter: Using Geolocation and Compass. Compass is tilt compensated--NEAT. The Nexus 7 tablet's GPS worked indoors with a reported accuracy of 6-8 meters. Reported location of my house was accurate, but altitude was about 100 feet off. I passed on all the take your phone and walk outdoors suggestions. Not today. The location class has several methods that would be very useful for an outdoor (Robo Magellan) robot. I only skimmed the chapter, Using Android Cameras. I see applications to robotics, but am anxious to move to the next two chapters, Networking Devices with WiFi and Peer-To-Peer Networking Using Bluetooth and WiFi Direct.

John Abshier

Clock Loop · 2014-02-04 16:25

http://forums.parallax.com/showthread.php/148964-Propscope-Galaxy-Tab-2-Android-4.1.1-Samsung-USB-adapter-you

I started on hardware but never moved into android dev.. thats basically the only thing stopping the prop from taking over the android.

Im surprised parallax hasn't already hired an android dev to make a parallax serial terminal for android, and even a Propeller (android)Tool for on the go prop dev.

Bluetooth is the best method, then usb.
I needed to buy a special usb converter from samsung for my tab2.

So cheapest method would be to get a bluetooth device for the prop.
(but it needs a working DTR or RTS in both android and on the prop side bluetooth module)
http://www.parallax.com/product/30086

And dev an android app. to serially talk to the prop over bluetooth spp (serial profile).

John Abshier · 2014-02-06 14:11

The book I am mainly using relied on Open Sound Control (OSC). I am not up right now to writing an OSC object, so I am just using Processing's Network library. Goal is Processing to Prop. Propeller is a BOE with a Digi XBee S6B. Here is a Spin program that echos bytes received via WiFi to PST on my PC.

{Echo.spin
  Arthor:  John Abshier
           jabshier on forum
  Purpose:  To demo transfering data to Propeller via WiFI
}


CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

        LCD_TX = 19
        XBee_DO = 4
        XBee_DI = 3
        
VAR
  byte  fromXBee[81]
  byte  aChar
OBJ
  SIO : "Parallax Serial Terminal"    ' To PC vis USB
  XBee: "Parallax Serial Terminal"
  
PUB Main
  SIO.Start(115200)
  XBee.StartRxTx(XBee_DO, XBee_DI, %0000, 9600)
  waitcnt(clkfreq * 3 + cnt)   ' Wait to open PST on PC
  SIO.Str(string("Demo starting",13))
  repeat
    aChar := XBee.CharIn      ' Get something from WiFi    
    SIO.Char(aChar)          ' Echo it to PC

Here is a Processing program to send data to the Propeller

import processing.net.*; 
Client myClient; 
int i; 
 
void setup() {
  frameRate(2); 
  size(200, 200); 
  // Connect to the local machine at port 23.
  // This example will not run if you haven't
  // previously started a server on this port.
  myClient = new Client(this, "192.168.1.120", 23); 
} 
 
void draw() {
 myClient.write("From Processing " + i++ + "\r"); 
}

Here is a sample of the output to my PC.

From Processing 100
From Processing 101
From Processing 102
From Processing 103
From Processing 104
From Processing 105
From Processing 106
From Processing 107

John Abshier

Edit: PS. Cannot get to work on Android devices.

PPS. Google and persistence will eventually pay off. Nexus 7 to Propeller successful. Two things required. First, Processing sketch must have a directory "code" That directory must have a copy of net.jar. Second, in Processing IDE, go to Android-Sketch Permissions and check the internet box.

Bob Lawrence (VE1RLL) · 2014-02-09 21:53

Hi john,

Great project. I've been doing Android apps using various methods including Java, HTML5 & Phone Gap and for the past few months Delphi XE5. My latest project is with the propeller chip- Bluetooth to Delphi XE5/Android. I'll follow your progress with interest.

Bob

Bob Lawrence (VE1RLL) · 2014-02-09 22:03

@ John Abshier

The book I am using has a chapter titled, Networking Devices with WiFi and one titled Peer-To-Peer Networking Using Bluetooth and WiFi Direct.

What is the title of the book?

John Abshier · 2014-02-10 07:09

Rapid Android Development: Build Rich, Sensor-Based Applications with Processing by Daniel Sauter (May 2, 2013)

John Abshier

John Abshier · 2014-02-10 12:19

Worked on the project a little today. Successfully talked from Propeller to PC, Android emulator and Nexus 7 via WiFi. Simple programs at both ends. Propeller sends a message via WiFi every second and also echos to PST. Processing sketch displays the message in the debug text area on the PC and on the screen.

{SendStrings.spin
  Author:  John Abshier
           jabshier on forum
  Purpose:  To demo transfering data to Android via WiFI
}


CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

        LCD_TX = 19
        XBee_DO = 4
        XBee_DI = 3
        
VAR
  long  i

OBJ
  SIO : "Parallax Serial Terminal"    ' To PC vis USB
  XBee: "Parallax Serial Terminal"
  
PUB Main
  SIO.Start(115200)                                                             
  XBee.StartRxTx(XBee_DO, XBee_DI, %0000, 9600)
  waitcnt(clkfreq * 3 + cnt)   ' Wait to open PST on PC
  repeat
    SIO.Str(string("From Prop "))      ' Send message to PST
    SIO.Dec(i)
    SIO.Char(13)
    XBee.Str(string("From Prop "))     ' Send message to Android
    XBee.Dec(i++)
    XBee.Char(13)
    waitcnt(clkfreq + cnt)

And for Android

String inString;
byte interesting = 13;               // end of message character
import processing.net.*; 
Client myClient; 

void setup() {
  // Connect to the local machine at port 23.
  // This example will not run if you haven't
  // previously started a server on this port.
  myClient = new Client(this, "192.168.1.120", 23);
 background(0);              // Display window black
 textAlign(CENTER, CENTER);  // Center text 
// size(300, 100);             // Display window size
} 
 
void draw() {
  if (myClient.available() > 0) { 
    background(255);               // Display window changes color on first receipt
    fill(0);                       // Black characters    
    inString = myClient.readStringUntil(interesting); 
    text(inString,width/2, height/2);           // print to Display Window
    println(inString);                       // print to text area of IDE
  }
}

Three grumpy old man observations:
1. I am not even close to fluency in Processing. Lots of dumb errors and time looking stuff up. The Processing web site Reference page is nice.
2. The men (I assume they are men.) responsible for the LF, CR, LF+CR mess and not in hell only because God is forgiving.
3. The 30 or so seconds it takes to establish a WiFi connection seem like eternity when you are just siting watching the monitor and not sure your program works.

What's next. Sending and receiving from Prop to Android proves the project is feasible. I am reminded of something from the math world. Proving that something exists may be much easier than an algorithm to find it. What is needed is a protocol for the two devices to use for communication. I think there is an art to designing a protocol. Too simple, it may not be robust enough for the real world. Too complex, it will be slow, hard to implement, and impossible to understand. However, all is not lost. This wheel has been invented, and reinvented. On my Kindle I found a book that I haven't gotten around to reading: A Hardware Interfacing and Control Protocol, that uses the Propeller as its target microcontroller. Also a Google search for "robot communication protocol" gives 1,470,000 wheels.

John Abshier

John Abshier · 2014-02-11 14:29

Two way communication today. Android sends commands to Propeller to turn LEDs on and off. Whenever the LEDs are turned off the Propeller sends a random number standing in for a sensor measurement. Android displays the status of the LEDs and the last value received from the Propeller. Today I discovered that Pin 0 of my BOE is dead. Probably not feasible to fix. I will live with it. Here is the code:

{SendReceive.spin
  Author:  John Abshier
           jabshier on forum
  Purpose:  To demo transfering data to and from Android via WiFI
}


CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

        LCD_TX = 19
        XBee_DO = 4
        XBee_DI = 3
        RED_LED = 2
        GREEN_LED = 1
VAR
  long  i
  byte  fromXBee[81]

OBJ
  SIO : "Parallax Serial Terminal"    ' To PC vis USB
  XBee: "Parallax Serial Terminal"
  
PUB Main
  SIO.Start(115200)                                                             
  XBee.StartRxTx(XBee_DO, XBee_DI, %0000, 9600)
  waitcnt(clkfreq * 3 + cnt)   ' Wait to open PST on PC
  dira[RED_LED]~~           ' set LED pins to output
  dira[GREEN_LED]~~
  repeat
    XBee.StrIn(@fromXBee)       ' Get something from WiFi
    SIO.str(@fromXBee)          ' Echo it to PST
    SIO.char(13)
    if strcomp(@fromXBee, @on)
      outa[RED_LED..GREEN_LED]~~     ' turn on LEDs
    if strcomp(@fromXBee, @off)
      outa[RED_LED..GREEN_LED]~      ' turn off LEDs and send a value
      XBee.dec(?i // 100)
      XBee.char(13)
      
DAT                      ' commands from Android
        on byte "On", 0
        off byte "Off", 0

And for Android

import processing.net.*; 
Client myClient; 
int i;
String inString = "";
byte interesting = 13;               // end of message character

void setup() {
  size(400, 200); 
  // Connect to the local machine at port 23.
  // This example will not run if you haven't
  // previously started a server on this port.
  myClient = new Client(this, "192.168.1.120", 23);
 textAlign(CENTER, CENTER);  // Center text 
 fill(0);                       // Black characters  
 textSize(50); 
 i = millis();
 while (millis() - i < 30000) ;  // pause 30 seconds to connect 
} 
 
void draw() {
  frameRate(2);
  background(255);              
  if (i > 0) {
    myClient.write("On\r");
    text("On",width/2, height/4);
    i = -1;
  } else {
    myClient.write("Off\r");
    text("Off", width/2, height/4);
    i = 1;
  }
    text(inString,width/2, 3*height/4);           // print to Display Window
}

void clientEvent(Client someClient) {
  inString = someClient.readStringUntil(interesting); 
}

John Abshier

John Abshier · 2014-02-17 15:03

I haven't given up. I have been reading a lot, thinking some, and writing "experiment" code a little. I think I am closing in on a communications protocol and a skeleton for the Propeller program.

John Abshier

John Abshier · 2014-02-18 11:06

Bottom line up front if you don't care to read my ramblings. A message is in ASCII with the following format.
!<command><CR>[<integer><CR>]
The [] are not sent and items inside them are repeated 0 to n times.
The Android device is the master and initiates all messages. The slave Propeller will respond with data requested by command, if no data requested !ACK<CR>, or !NAK<CR> for error. Format for sending data is !<command><CR><integer><CR>[<integer><CE>] Master needs to know what to expect the Prop to return.

Protocol. ASCII or binary? The only advantage I see to binary is that it is faster. 128 requires 3 ASCII characters, 4 with <CR>, versus 1 for a byte. At the default XBee baud rate that is roughly 1 millisecond versus 3 or 4. Plus there is the time to encode/decode from binary to ASCII and back. The advantage to ASCII is that it is human readable. Some would say self documenting. What is 0xE1 compared to Set_left_motor_speed_with_ramping? To the computer there is no difference, they are both used in an if statement. The ASCII example given is not self documenting to a non-English reader. Sadly it is not self documenting to an English reader. Is it RPM, radians per second or a power level. If it is a power level, is it -100 to 100 or 0-255 with 0 being full reverse and 255 full forward? I am going to use ASCII to start because I can read it and also can type it in a terminal program for testing. If performance becomes an issue, I will increase the XBee baud rate and then consider switching to a binary format.

Many protocols have sender/receiver addresses. I don't need that because the combination of IP address/port number serve that purpose.

Most protocols have at least a checksum or a CRC for error discovery. I am going to rely on the TCP/IP stack.

I am not going to send a message length/number of data items. The command knows how many data items it needs.

I am assuming that with TCP/IP that if we have a connection, it is relible. But we could lose the connection at any time (Robot went into the culvert. Phone battery died.). So I need to know when the connection is lost and be able to resync when communication is reestablished. If the connection is lost the Propeller code will time out and resume looking for the ! sync character. Additionally, after a longer time out, the Propeller code will go into a "Safe" mode. The Android app should do something if the Propeller doesn't respond in a reasonable time. I haven't thought much about that.

Back to more reading.

John Abshier

trooks · 2014-02-21 20:18

John Abshier wrote: »

I don't, won't, buy Apple. Not sure what I would do if given one. So this project will be Android to Propeller.

A little background about my strengths and many more weaknesses. A little over 50 years ago I started programming in FORTRAN with card on an IBM 1401. I did a little FORTRAN programming while getting an Aerospace Engineering degree in the late 1960's. Then I too a little over a decade off from programming to shoot cannons and fly helicopters. I then became an Operations Research Analyst, getting a MS in Computer Science with an emphasis in Operations Research. I have never been a professional programmer, but have programmed to do my job and also as a hobby (mainly robotics). In one organization we couldn't even admit to programming since that was reserved for the Directorate of Management Information Systems. I have programmed in various FORTRANs, BASICs, Pascal, PL/I, GPSS H, Simscript II.5, Java, Dynamo, C, AWK, Python, RCA machine language (hand assembled), IBM 360 assembler, and, of course, Spin and PASM. Also, although some may not consider them programming languages, SAS, SQL, Lotus 123, and Excel. I wonder if anyone recognizes all those languages without Google. Network programming experience: none, nada, zilch. Android programming experience: see network programming.

On the Prop side I will be using a BOE, because that is what I have. It should generalize to the Activity Bot. I will use Spin. I know it and Spin will save the time of learning the Prop specific idioms of C for the Prop.

Connection between Android devices and the Prop will be by a Digi XBee S6B. Bluetooth would be another option. A hard wired USB connection looks to be feasible but harder than I want to attack.

Android devices will be an old DroidX, a Galaxy S III, and old and new versions of Nexus 7.

I considered five languages for Android. MIT's App Inventor for Android, a graphical 12 Blocks, Scratch, like system would work over Bluetooth. Java, I looked at it and didn't want to go there. Basic4android is a commercial product ($59 with 2 months free upgrades) may be the best solution, especially if you want to use the USB connection. RFO BASIC! is a free dialect of Dartmouth BASIC that allows you to write and run programs directly on an Android device (http://laughton.com/basic/). I was tempted to use RFO BASIC! and may go back to it if time and interest level allow. I selected Processing mainly because it had more books listed on Amazon. Processing is to JAVA as Arduino code is to C/C++

John Abshier

I actually had to take a test in most of the languages you named off and some that were not listed. While you were off shooting the cannons I was state side as contractor fixing stuff that required the company of an armed guard.

The languages you mentioned do not seem to be in order though or at least not any order that I understand.

One of those languages dates me close to the time I decided to head closer to home and work field service instead of 'up Nawath' or 'way out west'. ]8>D

I had a good run because each time one of those companies listed bought all or part of another company in the list I was always kept on the job.

These days I carry nothing around with that will intrude with my concentration in keeping some tentative grasp on reality. (u do rd hippy code - right?)

Tim
<grinning like a mule eatin' briars>

Bob Lawrence (VE1RLL) · 2014-02-21 21:07

@John Abshier

re:Rapid Android Development: Build Rich, Sensor-Based Applications with Processing by Daniel Sauter (May 2, 2013)

Thanks!

pedward · 2014-02-26 08:41

I was interested in making the propeller talk to Android a while back. I searched and found some Java classes that provide a serial gateway to the propeller, using USB OTG. I compiled an example and loaded it on my tablet. The program registers an intent with Android so that when the FTDI device is plugged into it, it launches my program.

This is the native way to make the Propeller idiot proof communicate with Android. I didn't have any real purpose beyond proving it worked, so I haven't built anything more elaborate.

Whether I wanted to or not, it seems the most direct way of supporting the Propeller is via a native Java app on Android. I have Eclipse and setup to do Android dev. It really helps if you're using Linux as the dev environment, as Android really works better with Linux IMHO.

John Abshier · 2014-02-26 09:42

pedward, Eclipse and native Java are something I am not interested in. I agree that USB OTG/FTDI is a good way to go. Basic4android has a USB library, but I haven't purchased it. I found a Processing library, but haven't gotten to it yet.

John Abshier

John Abshier · 2014-02-26 15:01

Here is a skeleton or template Prop program for the project. It is based on my previous robot coding, Arduino and Processing. The only testing so far is the Lucy B. test, it complied without error. (Memories of a long and frustrating conversation, "I don't care if it complies. A negative number of tanks in a company is an error!") Known work to be done: Parallax Serial Terminal needs to be changed to timeout and to trap invalid integers. The CommandReader method probably needs to be able to tell the Spin method that data has been received that requires its attention.

{Design.spin
  Arthor:  John Abshier
           jabshier on forum
  Purpose:  Skeleton or template for Android - Prop commo
}


CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

        XBee_DO = 4
        XBee_DI = 3
        SPIN_LOOP_HZ = 20                   ' Spin loop cycles per second
        HEARTBEAT_LIFE = SPIN_LOOP_HZ * 30  ' 30 second timeout
        
VAR
        long          commandReaderStack[50] 
        long          SPIN_LOOP, wait  ' variables to time Spin loop
        
OBJ
        SIO : "Parallax Serial Terminal"  
  
PUB Main
  Init                          ' inizilation
  Spin                          ' main program loop
  Safe                          ' puts system in safe state on error or exit from Spin

PRI Init
{{ All setup code here.  Last statement load the CommandReader cog }}
  SPIN_LOOP := clkfreq / SPIN_LOOP_HZ    ' Spin loop time in clock ticks
  cognew(CommandReader, @commandReaderStack)

PRI Spin
{{ This is a loop that does the work.  It maintains the heartbeat and calls Safe if comms are lost.
   It communicates with the CommandReader via  a DAT block}}
  repeat until heartBeat > 0         ' Wait for comms to start
  wait := cnt
  repeat
    wait += SPIN_LOOP
    
        ' your code here
        ' if loop takes too long and you miss the waitcnt expect a wait of about 50 seconds
        
    heartBeat --                      
    if heartBeat == 0           ' Commo timeout with Android device             
      Safe                      ' Shut down gracefully
    waitcnt(wait)
PRI Safe
{{ If comms are lost, this method puts the system in a "safe" state.  Examples:  Motors--off, machine guns stop firing
   If possible, it should make a visual/aural indication that it has been called }}
   
DAT
{{ Area for communication between CommandReader and Spin. }}
        heartBeat       byte    0               ' ****** must be 0 at program start
        ' sample data elements
        leftMotor       byte    127             ' set to safe value.  In this case off
        rightMotor      byte    127
        turretDir       word    900             ' direction of turret in 1/10 degree
        LED             byte    0, 0            ' LED status 0 = off 1 = on


VAR
  byte command[21]
DAT
        NAK byte "!NAK", 13, 0
        ACK byte "!ACK", 13, 0
PRI CommandReader | tmp1, tmp2
{{  Communicates to and from remote system.  Communicates with Spin method via a DAT block. Updates Heartbeat on each
    received and understood message. }}
  SIO.StartRxTx(XBee_DI, XBee_DO,  %0000, 9600)
  repeat
    repeat until SIO.CharIn == "!"   ' wait for sync character if never received heartBeat will go to 0
    SIO.StrInMax(@command, 20)       ' read the command
    ' need to figure out how to time out and break back to looking for sync character for cmd and parameter reads
    ' now find and act on command
    if strcomp(@command, string("Cmd1"))
      'read parameters if any
      'set variables if required
      heartBeat := HEARTBEAT_LIFE    ' update heartBeat
      SIO.Str(@ACK)                  ' send ACK or send requested data
    elseif strcomp(@command, string("Cmd2"))
      'read parameters if any
      'set variables if required
      heartBeat := HEARTBEAT_LIFE    ' update heartBeat
      SIO.Str(string("!Cmd2",13))    ' send requested data or !ACK
      SIO.Dec(leftMotor)
      SIO.Char(13)
    else
      SIO.Str(@NAK)

John Abshier

John Abshier · 2014-02-28 15:24

Made progress on modifications to Parallax Serial Terminal for time outs and graceful failure on invalid characters in decimal (base 10 only) input. Still need to do more testing. I also need to decide whether to keep all of the original Parallax Serial Terminal with my changes as additional methods or to make a smaller version.

<RANT> Spent hours getting the computer hooked up to my TV working again. I now think (after buying a different USB wireless network adapter) the offending software is the TV tuner driver. But I don't know for sure. Thirty years ago, I enjoyed the challenge of getting computers to work. Now I just wish they would work. </RANT>

John Abshier

John Abshier · 2014-03-01 14:07

Attached is a project with a Serial Terminal object with a test program. The Serial Terminal object defaults the time out to 1 minute and has a Set Timeout method. A timeout returns NEGX. An invalid character in DecInTime returns POSX.

John Abshier

John Abshier · 2014-03-03 09:01

I have been working on the Android part of last project before moving on to WiFi Direct and USB OnTheGo (wired connection between Android device and Prop). I have forgotten semicolons more times than I can count. Project goal is drive a robot with a phone/table/PC. So far zero code on Prop and all I have finished on Android is drawing the user interface. Here is an image.

At the top is a virtual joystick, click/tap in the gray circle to move the joystick. The go button enables the servos/motors. When enabled the go button is replaced with a red stop sign. The blue rectangle displays Ping reading. I haven't decided if it will be constantly updated or only updated when you click in the rectangle. The red and green rectangles at the bottom display status and toggle state of two LEDs.

I need to get a move on. The first shooting match of the year is only 3 weeks away and Prop time will decrease as shooting time increases.

John Abshier

PS. Sorry for small image size. If you click on it, you get an image big enough to read.

John Abshier · 2014-03-06 11:32

Yesterday's computer project was getting my Windows 7 based media center PC working again. The Time Warner tech support guy was pleasant and knowledgeable. Hopefully it is stable now. Time will tell.
Today: If you (I) reverse dataOut and dataIn in a call to a serial driver start method, things don't work. And I can look at working and non-working code for a loooong time before seeing the difference. The next 4 or 5 days will be eaten by other priorities, but i hope to finish the application in the above post next week.

John Abshier

Alternative Open Propeller Project #1: Android to Propeller BOE

Comments