@jeff
I did not think you used portrait mode but took a pic just in case. I use the setAllowed Orientations(4)
in my test TB apps. I agree with you we need to limit to one orientation.
I will try your screen again, I tried entering some text in ip text field and it seems a bit tiny and did not work.
Could be that part you have not played with except put it on screen and that is ok.
Could also be be with a fat finger LOL
@dgately
Yes a setup ie config file is a nice idea and Tech Basic can read files. A simple INI style file
IP=192.168.1.23
PORT=9750
and anything else needed.
We've got an Australian chemical engineer customer at the office today but I'll be back to this project by the end of the week. Great to see that Brian got his WiFi settings sorted out again - hopefully it'll work for me too. Is this an ad hoc connection, or through router?
Ken
If you are referring to my last post of settings #268 it is DIRECT AD-HOC. I just call it direct the
term ad-hoc I remember from the other wifi module the WIFLY which acted like a router and did DHCP.
The Digi XBEE does not do that.
I am open to being corrected on that but for sure my settings are direct iPad to XBEE .
Tom you mention fat fingers, when we first started talking about techBasic I tried doing everything with fingers and the on screen keyboard, it's just too much trouble so now I use a cheap stylus and a bluetooth keypad. It makes the whole iPad experience a lot better.
Even so I think it might be a good idea to increase the size of the input fields. The graphics are really only there to give a feel for what the finished article could be and there is no reason at all why they can't be replaced or modified. I think Ken mentioned Parallax has an in house graphics artist.
I have a version of source now that contains a sub routine dedicated to transmitting and receiving, this can be simply changed out for any kind of protocol we might want to test.I have also started to put a few comments in place.
Most of the source was patched together trying different samples of code, as it has grown I now see ways to do a few things better and I am working on that.
I may have misworded what I said in an earlier post about standardization especially about the wifi connection. It's not that I think everyone should go with the same IP and wireless set up but I do think that something is needed in place to make it clear and simple how to make the connection. From day one it has been one of the biggest hurdles for people to get by. Ken you said you could talk with the people at Digi that would be great.
All,
My last Abot code that used a extra cog was causing the xbee problem. Here is the new drive code with no error checking ,use Jeff's post 220 ipad code and Tom's post 268 xbee setup. My son drove the Abot around for a hour ,completely shutting everything down and restarting it without issue.
Brian
#include "simpletools.h"
#include "fdserial.h"
#include "ping.h"
#include "abdrive.h"
fdserial *xbee;
#define xbee_recieve_pin 9 // I prefer to define these so I can easily change them later
#define xbee_transmit_pin 8
#define LED1 26 // select activity bot led 1 pin
#define LED2 27 // select activity bot led 2 pin
#define LedCode1 17 // code from ipad to turn on led 1
#define LedCode2 33 // code from ipad to turn on led 2
#define LedCode3 49 // code from ipad to turn on led 1 and led 2
#define PingPin 4 // ping pin
#define LedData 0 // byte for led data
#define AccelXdata 1 // byte for accel x data
#define AccelYdata 2 // byte for accel y data
#define PingData 3 // byte for sending ping data
#define UserData1 4 // byte for user data
#define CheckSum 5 // byte for checksum
int main(void)
{
int i; // iterator
char x ;
int Ay,Ax; // from xbee 1-byte buffer
char xBee_Data[6]={0,0,0,0,0,0}; // command buffer
xbee = fdserial_open(xbee_recieve_pin,xbee_transmit_pin,0,9600);
simpleterm_close(); // close old terminal connections
fdserial_rxFlush(xbee); // clear the xbee buffer, need to start 'anew'
pause(100); // pause 1/10 of a second (2ms) was not enough time
while(1) // run forever
{
if (fdserial_rxChar(xbee) == 'W') // got specific command-byte?
{
for (i = 0; i < 6; i++) // 6 characters in a command string, check them!
{
x = fdserial_rxTime(xbee,20);
if(x != -1)
xBee_Data[i] = x; // if there is a byte, store it, else move on
}
}
switch(xBee_Data[LedData]){ // check data from proper char for controlling leds
case LedCode1:
high(LED1);
low(LED2);
break;
case LedCode2:
high(LED2);
low(LED1);
break;
case LedCode3:
high(LED1);
high(LED2);
break;
default:
low(LED1);
low(LED2);
}
Ax = (xBee_Data[AccelXdata]-125);
Ay = (xBee_Data[AccelYdata]-125);
drive_speed(Ax + ~Ay,Ax + Ay); // set drive speed
xBee_Data[PingData] = ping_inches(PingPin); // read ping and insert in proper char to send back to ipad
for (i = 0;i < 6; i++) // hopefully, there's 6 bytes stored...
{ // if not, xbee gets garbage returned
fdserial_txChar(xbee,xBee_Data[i]); // echo back data to xbee
}
x = -1; // 1 byte buffer set to false
}
return 0 ;
}
Banjo,
Its sending 6 bytes back to iPad and inserts ping data in one of those bytes.
Here is code w/dead zone
I took a video and trying to figure out where to send it.
Brian
#include "simpletools.h"
#include "fdserial.h"
#include "ping.h"
#include "abdrive.h"
fdserial *xbee;
#define xbee_recieve_pin 9 //xbee to prop Rx (DO)
#define xbee_transmit_pin 8 // xbee to prop Tx (DI)
#define LED1 26 // select activity bot led 1 pin
#define LED2 27 // select activity bot led 2 pin
#define LedCode1 17 // code from ipad to turn on led 1
#define LedCode2 33 // code from ipad to turn on led 2
#define LedCode3 49 // code from ipad to turn on led 1 and led 2
#define PingPin 4 // ping pin
#define LedData 0 // byte for led data
#define AccelXdata 1 // byte for accel x data
#define AccelYdata 2 // byte for accel y data
#define PingData 3 // byte for sending ping data
#define UserData1 4 // byte for user data
#define CheckSum 5 // byte for checksum
int main(void)
{
int i; // iterator
char x ;
int Ay,Ax; // from xbee 1-byte buffer
char xBee_Data[6]={0,0,0,0,0,0}; // command buffer and clear to 0
xbee = fdserial_open(xbee_recieve_pin,xbee_transmit_pin,0,9600);
simpleterm_close(); // close old terminal connections
fdserial_rxFlush(xbee); // clear the xbee buffer, need to start 'anew'
pause(100); // pause 1/10 of a second (2ms) was not enough time
while(1) // run forever
{
if (fdserial_rxChar(xbee) == 'W') // got specific command-byte?
{
for (i = 0; i < 6; i++) // 6 characters in a command string, check them!
{
x = fdserial_rxTime(xbee,20);
if(x != -1)
xBee_Data[i] = x; // if there is a byte, store it, else move on
}
}
switch(xBee_Data[LedData]){ // check data from proper char for controlling leds
case LedCode1:
high(LED1);
low(LED2);
break;
case LedCode2:
high(LED2);
low(LED1);
break;
case LedCode3:
high(LED1);
high(LED2);
break;
default:
low(LED1);
low(LED2);
}
Ax = (xBee_Data[AccelXdata]-125); // scale data to 0 when ipad is flat
Ay = (xBee_Data[AccelYdata]-125); // scale data to 0 when ipad is flat
if(Ax > -10 && Ax < 10){ // if in dead zone ,sit still
drive_speed(0,0);
}
else {
drive_speed(Ax + ~Ay,Ax + Ay); // set drive speed
}
xBee_Data[PingData] = ping_inches(PingPin); // read ping and insert in proper char to send back to ipad
for (i = 0;i < 6; i++) // hopefully, there's 6 bytes stored...
{ // if not, xbee gets garbage returned
fdserial_txChar(xbee,xBee_Data[i]); // echo back data to xbee
}
x = -1; // 1 byte buffer set to false
}
return 0 ;
}
Brian, later today I will try and post a version of the techBasic that will display the Ping data and I will remove the TX/RX data display as that is only a debug feature anyway. Also I will fix orientation to landscape only.
Can you think of anything that would make the GUI better, an emergency stop a speed control anything that comes to mind. Talk to your son I bet he has some good ideas, awesome that he is doing the various disconnect tests.
@ Jeff,
Sounds good ,I'm going to start on a function for dissecting the bits that control the leds.
A nice big red E-stop would be nice (about 1"), it always seems you can't see it when you need it. Maybe throw it in one of the bits in the first Byte.
Btw , I know we still need to work on error checking , I just needed to see something move
@ken,
Jeff ,Tom and the others working on the ipad end would be best to answer that(artwork).
@Brian
Congrat's good test of seeing how it moves with the iPad.
Nice video, it looked stable and controllable. Good that just
a little tilt of the iPad and it leaves the room and you never see
it again was not the case.
I have been out of the loop for a while due to the careless use of smoking materials. I followed this thread very carefully for a while. I have TechBasic installed on my IPhone 4s and have experimented with it, but I don't yet own an iPad. I understand that the primary emphasis is making it easy for student, but I think we should consider things that aren't yet possible on other platforms.
This is a work in progress but I will put it up here because you may want to try it out as it is right now.
The application is designed to allow one to use the iPad to perform the abdrive examples in the Activity Bot
Tutorial Navigation Basics section from an iPad by entering the Right and Left Wheel values and Pause time
into iPad TextFields and then select which abdrive code sequence you want to execute by clicking the button
above the green example text.
For the driving the Activity Bot around by iPad project this tests using iPad controls to get values and sending messages
with 16 bit integers, which is what the abdrive lib functions take as parameters and using a switch to connect/disconnect Wifi.
The edit field showing ip address is editable but does not try and connect if you change it, also it is not remembered
but a file could be added to do that as dgately mentioned. I left it with my ip which you will need to change to yours
in the edit field then click the connect switch to connect.
I also set the keyboard type for the edit fields to numbers to see how that worked. Only works if using iPad keyboard not
a seperate bluetooth keyboard.
Also no checking if you enter something wierd, I would like to be able to set the edit boxes to only take numbers but
Basic does not have that available.
Right now it depends on the human looking at the iPad to know when the AB is through with a command.
If you double tap it may or may not do the sequence twice, depends on how long pause time is.
An ACK NAK protocall could be added, Thinking about this.
In using the app it seems to take a moment to execute the first command and after that it responds right away.
Something to look into. Remember the pause time is in there and if you set it to a large number the AB is dumb pausing
that time .
The P26 and P27 switches turn on and off those Led's on the Activity board.
I put this up before doing the receive of ticks count and ping, I will work on that tomorrow.
A similar TB app like this could be written to do the extra tutorial of triming the AB, much easier than holding the
reset switch and letting go then entering new numbers into code rebuild and download then do it again.
I should add a trim on/off switch to this to experiment with how the Bot drives with and without trim.
All part of learning and testing Tech Basic and C code for driving the AB around with iPad.
In this case manually entering numbers and moving the AB around on the floor, which by itself is good for
experimenting with various numbers in the Navigation Basics Tutorial on the Learn pages
@Jeff
I used your TB connection and error handling code and modified it to use an iPad switch to connect and disconnect.
The switch will be red while trying to connect and then green if a connection is made. If it cannot connect it turns the
switch off . Only waits a second to connect , I need to increase that but it works fine for me.
I show this was as something to look at for larger TextFields to edit in and connect disconnect code idea.
Ignore Ping and Ticks screen fields they only put up test values for positioning fields on screen right now.
Should not have to use iTunes but you can. The zip file contains the TB code which is the same as posted here.
Just email the text of the TB code to your iPad and copy and paste it into a new TB project.
Serial connections on AB board are on pins 8,9 and C code shows using #ifdef to select that at build time as well
as turning on and off the printing to terminal for DEBUG by commenting out the defining of DEBUG
I spoke with Brian today after running all of the example programs from Brian, Tom, Jeff and Rich. I was really impressed about the stability of the whole system once it was properly configured and running. I had a couple of talking points to bring up to see what everybody thinks about next steps:
Between baud rates and timeouts in the TB code, do you think we could make the data exchange a bit more real-time?
For the tilt-pad controller program, would it be possible to integrate the TB graphing options around the dual-axis accelerometer so one could see the sensor effect visually?
I know we should be a bit more formal about some requirements, but I think we're still making lots of improvement and learning quite a bit, so that when the data exchange is fully ironed out it'd be a matter of polishing the TB/C code examples.
In related news, today we successfully downloaded a 32KB Propeller program from an iPad to the Propeller over XBee WiFi. We have had Mike from TechBASIC (ByteWorks) at our office working with Jeff (our internal dev tools engineer) to see what they could achieve. As it stands, the code is sorta clunky and full of debugging bits, but now they'll clean it up and try to formalize the program download process. And this was all done without the use of co-processors to buffer the program!
@Ken
Great you got the examples to run and had Byte Works in house and looking over our stuff.
When you say make the data exchange more real time, what do you mean.
Maybe a better way to ask is do you have some high speed thing in mind or
did it just seem sluggish to you.
I believe Jeff and Brian have the Acell data going out at 0.1 sec right now.
In one of the test I did to test my messaging way and also as a test for Jeff who
was seeing data errors with his code I tried different code to see if I got errors I sent 6 bytes out and back every 0.1 sec with
no errors and experimented with going 0.050 sec and it worked with no errors and the
red and blue led's next to the XBee were on solid. For some reason the XBEE would
pause for a 0.5 sec every once in a while but recover. Both lights would go out then come back on.
So it could go faster on sending Acell data but keep in mind if one aspect is going all out sending
Acell data there is no time left to do anything else.
We will have to experiment.
I view sending Acell data out for steering control the high priority task and receiving data to display on the iPad screen
lower priority. You do not have to send the Acell data to the AB and get it back from the AB to plot it.
We can plot as we send and we do not have to plot every set of data points we send if we are going to send at some taxing speed.
In related news, today we successfully downloaded a 32KB Propeller program from an iPad to the Propeller over XBee WiFi. We have had Mike from TechBASIC (ByteWorks) at our office working with Jeff (our internal dev tools engineer) to see what they could achieve. As it stands, the code is sorta clunky and full of debugging bits, but now they'll clean it up and try to formalize the program download process. And this was all done without the use of co-processors to buffer the program!
I'd sort of lost track of where this project was going. How did you download a 32k program? I had planned on doing that with a program running in a COG so I could write all of hub memory without interference. How did you do it? Did you write the program directly to EEPROM and then reboot?
Hey all,
It looks to me that iOS only supports a sensor sample rate of .01 seconds at the fastest. So I don't know if speeding up baud rates will make it closer to real time.
Brian
There are two different rates involved.
the 0.01 sample rate you tell IOS to sample the Accelerometer sensor in the background with this TB statement
sensors.setAccelRate(0.01)
If I remember the TB manual says to not sample at the fastest rate as it will drag down IOS doing that.
The other rate which control is how often you send the values out the serial port over to the AB in the
nullevent subroutine.
This is the 0.1 sec I was referring to and could go a bit faster.
This statement in SUB null event controls that
IF System.ticks-t>0.1 THEN
I was using setAccelRate(0.05) when putting the values on the screen
I wonder if the sluggishness Ken was referring to was a result of using 0.01
I say that based on what TB Manual said, I need to go reread that section.
@Ken
If you go into the TB code and edit that line to sensors.setAccelRate(0.05) does it improve
the real time response you were thinking of.
Since we are only using the sampled values every 0.1 sec using an IOS sample rate of 0.05 gives two samples
for everyone we use.
Hi Brian
Seems there is an issue with different screen resolutions. When Jeff told me my screen pics of his code looked
right I felt maybe we all were the same.
When doing the code I tried the TB Graphics.Width and backoff of that to position things but it did not work.
So all my positions were hand tweeked.
I have advanced a bit more and am receiving wheel ticks from the AB and will try ping sensor next.
.
Is your iPad2 a Retnia display, I am thinking not
In the TB code you will find this statement
!! Graphics.Width is not the right edge?? so tweeked it
xright = Graphics.Width + 150
xright positions those items where they are try some lower values like get rid of the 150 to start
even try some values totally manual like xright = 200
It would be interesting to know what number for xright puts the items in the same spot on your screen
Edit: One of the switches you are missing you turn on to connect. It turns green when it connects.
xright = Graphics.Width - 100 ,is what it takes for me to see the sliders.
I did get it to connect , I entered 500 for left and right and the aBot took off with no thought of stopping ,may need a estop for people that enter wrong data(Me).
Brian
500 WOW the max speed number for AB abdrive is 128 or -128 .
The test app is designed to allow experimentation of abdrive lib's commands from the iPad screen
using the Learn Activity Bot Tutorial series Navigation Basics http://learn.parallax.com/activitybot/go-certain-distances
Your right I do not test for bad data. The human is responsible for that :thumb:
Thank's for the info on Graphics Width. We will need to figure a way to put things on the iPad
screen on various versions of the iPad. I thought Graphic.Width and then back up the width of the
controls being placed would do it but I needed a fudge factor +150 on Retina and you say -100 on
non Retina.
Late last night I have a new version which displays wheel ticks and ping sensor distance.
Displays values at the end of each operation right now to test getting the right numbers on the screen
Have to look it over some more before posting updated version.
xright = Graphics.Width - 100 ,is what it takes for me to see the sliders.
That is what I would expect and should place the switch at the right of the screen, in view and independant of screen resolution. I don't understand why you are having to add 150 to get it there.
Tom, when I look at the screen shot you provided in post #266 everthing looks proportional and everything looks like it is placed where it should be, the title, activity bot graphic and status bar all fit. Compare it to the screen shots in posts #200 and #219. What values do you get when you assign the screen width and height to a variable for display in the console.
A little later I will try your TB code and see what the results are here.It would be nice to determine what the differences are.
Comments
I did not think you used portrait mode but took a pic just in case. I use the setAllowed Orientations(4)
in my test TB apps. I agree with you we need to limit to one orientation.
I will try your screen again, I tried entering some text in ip text field and it seems a bit tiny and did not work.
Could be that part you have not played with except put it on screen and that is ok.
Could also be be with a fat finger LOL
@dgately
Yes a setup ie config file is a nice idea and Tech Basic can read files. A simple INI style file
IP=192.168.1.23
PORT=9750
and anything else needed.
Tom
We've got an Australian chemical engineer customer at the office today but I'll be back to this project by the end of the week. Great to see that Brian got his WiFi settings sorted out again - hopefully it'll work for me too. Is this an ad hoc connection, or through router?
Ken Gracey
If you are referring to my last post of settings #268 it is DIRECT AD-HOC. I just call it direct the
term ad-hoc I remember from the other wifi module the WIFLY which acted like a router and did DHCP.
The Digi XBEE does not do that.
I am open to being corrected on that but for sure my settings are direct iPad to XBEE .
Tom
Even so I think it might be a good idea to increase the size of the input fields. The graphics are really only there to give a feel for what the finished article could be and there is no reason at all why they can't be replaced or modified. I think Ken mentioned Parallax has an in house graphics artist.
I have a version of source now that contains a sub routine dedicated to transmitting and receiving, this can be simply changed out for any kind of protocol we might want to test.I have also started to put a few comments in place.
Most of the source was patched together trying different samples of code, as it has grown I now see ways to do a few things better and I am working on that.
I may have misworded what I said in an earlier post about standardization especially about the wifi connection. It's not that I think everyone should go with the same IP and wireless set up but I do think that something is needed in place to make it clear and simple how to make the connection. From day one it has been one of the biggest hurdles for people to get by. Ken you said you could talk with the people at Digi that would be great.
Jeff
My last Abot code that used a extra cog was causing the xbee problem. Here is the new drive code with no error checking ,use Jeff's post 220 ipad code and Tom's post 268 xbee setup. My son drove the Abot around for a hour ,completely shutting everything down and restarting it without issue.
Brian
#include "simpletools.h" #include "fdserial.h" #include "ping.h" #include "abdrive.h" fdserial *xbee; #define xbee_recieve_pin 9 // I prefer to define these so I can easily change them later #define xbee_transmit_pin 8 #define LED1 26 // select activity bot led 1 pin #define LED2 27 // select activity bot led 2 pin #define LedCode1 17 // code from ipad to turn on led 1 #define LedCode2 33 // code from ipad to turn on led 2 #define LedCode3 49 // code from ipad to turn on led 1 and led 2 #define PingPin 4 // ping pin #define LedData 0 // byte for led data #define AccelXdata 1 // byte for accel x data #define AccelYdata 2 // byte for accel y data #define PingData 3 // byte for sending ping data #define UserData1 4 // byte for user data #define CheckSum 5 // byte for checksum int main(void) { int i; // iterator char x ; int Ay,Ax; // from xbee 1-byte buffer char xBee_Data[6]={0,0,0,0,0,0}; // command buffer xbee = fdserial_open(xbee_recieve_pin,xbee_transmit_pin,0,9600); simpleterm_close(); // close old terminal connections fdserial_rxFlush(xbee); // clear the xbee buffer, need to start 'anew' pause(100); // pause 1/10 of a second (2ms) was not enough time while(1) // run forever { if (fdserial_rxChar(xbee) == 'W') // got specific command-byte? { for (i = 0; i < 6; i++) // 6 characters in a command string, check them! { x = fdserial_rxTime(xbee,20); if(x != -1) xBee_Data[i] = x; // if there is a byte, store it, else move on } } switch(xBee_Data[LedData]){ // check data from proper char for controlling leds case LedCode1: high(LED1); low(LED2); break; case LedCode2: high(LED2); low(LED1); break; case LedCode3: high(LED1); high(LED2); break; default: low(LED1); low(LED2); } Ax = (xBee_Data[AccelXdata]-125); Ay = (xBee_Data[AccelYdata]-125); drive_speed(Ax + ~Ay,Ax + Ay); // set drive speed xBee_Data[PingData] = ping_inches(PingPin); // read ping and insert in proper char to send back to ipad for (i = 0;i < 6; i++) // hopefully, there's 6 bytes stored... { // if not, xbee gets garbage returned fdserial_txChar(xbee,xBee_Data[i]); // echo back data to xbee } x = -1; // 1 byte buffer set to false } return 0 ; }Jeff
@Brian, are there any specific reasons why ping data is sent back to the iPad in batches of 6?
Its sending 6 bytes back to iPad and inserts ping data in one of those bytes.
Here is code w/dead zone
I took a video and trying to figure out where to send it.
Brian
#include "simpletools.h" #include "fdserial.h" #include "ping.h" #include "abdrive.h" fdserial *xbee; #define xbee_recieve_pin 9 //xbee to prop Rx (DO) #define xbee_transmit_pin 8 // xbee to prop Tx (DI) #define LED1 26 // select activity bot led 1 pin #define LED2 27 // select activity bot led 2 pin #define LedCode1 17 // code from ipad to turn on led 1 #define LedCode2 33 // code from ipad to turn on led 2 #define LedCode3 49 // code from ipad to turn on led 1 and led 2 #define PingPin 4 // ping pin #define LedData 0 // byte for led data #define AccelXdata 1 // byte for accel x data #define AccelYdata 2 // byte for accel y data #define PingData 3 // byte for sending ping data #define UserData1 4 // byte for user data #define CheckSum 5 // byte for checksum int main(void) { int i; // iterator char x ; int Ay,Ax; // from xbee 1-byte buffer char xBee_Data[6]={0,0,0,0,0,0}; // command buffer and clear to 0 xbee = fdserial_open(xbee_recieve_pin,xbee_transmit_pin,0,9600); simpleterm_close(); // close old terminal connections fdserial_rxFlush(xbee); // clear the xbee buffer, need to start 'anew' pause(100); // pause 1/10 of a second (2ms) was not enough time while(1) // run forever { if (fdserial_rxChar(xbee) == 'W') // got specific command-byte? { for (i = 0; i < 6; i++) // 6 characters in a command string, check them! { x = fdserial_rxTime(xbee,20); if(x != -1) xBee_Data[i] = x; // if there is a byte, store it, else move on } } switch(xBee_Data[LedData]){ // check data from proper char for controlling leds case LedCode1: high(LED1); low(LED2); break; case LedCode2: high(LED2); low(LED1); break; case LedCode3: high(LED1); high(LED2); break; default: low(LED1); low(LED2); } Ax = (xBee_Data[AccelXdata]-125); // scale data to 0 when ipad is flat Ay = (xBee_Data[AccelYdata]-125); // scale data to 0 when ipad is flat if(Ax > -10 && Ax < 10){ // if in dead zone ,sit still drive_speed(0,0); } else { drive_speed(Ax + ~Ay,Ax + Ay); // set drive speed } xBee_Data[PingData] = ping_inches(PingPin); // read ping and insert in proper char to send back to ipad for (i = 0;i < 6; i++) // hopefully, there's 6 bytes stored... { // if not, xbee gets garbage returned fdserial_txChar(xbee,xBee_Data[i]); // echo back data to xbee } x = -1; // 1 byte buffer set to false } return 0 ; }Can you think of anything that would make the GUI better, an emergency stop a speed control anything that comes to mind. Talk to your son I bet he has some good ideas, awesome that he is doing the various disconnect tests.
Jeff
Sounds good ,I'm going to start on a function for dissecting the bits that control the leds.
A nice big red E-stop would be nice (about 1"), it always seems you can't see it when you need it. Maybe throw it in one of the bits in the first Byte.
Btw , I know we still need to work on error checking , I just needed to see something move
@ken,
Jeff ,Tom and the others working on the ipad end would be best to answer that(artwork).
Thanks'
Brian
My 8 year old son is at the control's.
http://youtu.be/9eBntyOLwko
Brian
Congrat's good test of seeing how it moves with the iPad.
Nice video, it looked stable and controllable. Good that just
a little tilt of the iPad and it leaves the room and you never see
it again was not the case.
Tom
Jeff
I believe that a more "Hollywood" video is in the works from my kids.
Brian
Arlo's brother.
http://youtu.be/rD9QWIdyFoE
Brian
If we want to have smart robots, they have to be able to see and interpret the world around them. Some time ago, Occipital had one of the
most successful kickstarted launches in history for its Structure Sensor. https://www.kickstarter.com/projects/occipital/structure-sensor-capture-the-world-in-3d
Has anyone looked at linking the Structure Sensor with the Propeller through TechBasic? Seems like a serial link is all that should be required.
Rich
The application is designed to allow one to use the iPad to perform the abdrive examples in the Activity Bot
Tutorial Navigation Basics section from an iPad by entering the Right and Left Wheel values and Pause time
into iPad TextFields and then select which abdrive code sequence you want to execute by clicking the button
above the green example text.
For the driving the Activity Bot around by iPad project this tests using iPad controls to get values and sending messages
with 16 bit integers, which is what the abdrive lib functions take as parameters and using a switch to connect/disconnect Wifi.
The edit field showing ip address is editable but does not try and connect if you change it, also it is not remembered
but a file could be added to do that as dgately mentioned. I left it with my ip which you will need to change to yours
in the edit field then click the connect switch to connect.
I also set the keyboard type for the edit fields to numbers to see how that worked. Only works if using iPad keyboard not
a seperate bluetooth keyboard.
Also no checking if you enter something wierd, I would like to be able to set the edit boxes to only take numbers but
Basic does not have that available.
Right now it depends on the human looking at the iPad to know when the AB is through with a command.
If you double tap it may or may not do the sequence twice, depends on how long pause time is.
An ACK NAK protocall could be added, Thinking about this.
In using the app it seems to take a moment to execute the first command and after that it responds right away.
Something to look into. Remember the pause time is in there and if you set it to a large number the AB is dumb pausing
that time .
The P26 and P27 switches turn on and off those Led's on the Activity board.
I put this up before doing the receive of ticks count and ping, I will work on that tomorrow.
A similar TB app like this could be written to do the extra tutorial of triming the AB, much easier than holding the
reset switch and letting go then entering new numbers into code rebuild and download then do it again.
I should add a trim on/off switch to this to experiment with how the Bot drives with and without trim.
All part of learning and testing Tech Basic and C code for driving the AB around with iPad.
In this case manually entering numbers and moving the AB around on the floor, which by itself is good for
experimenting with various numbers in the Navigation Basics Tutorial on the Learn pages
@Jeff
I used your TB connection and error handling code and modified it to use an iPad switch to connect and disconnect.
The switch will be red while trying to connect and then green if a connection is made. If it cannot connect it turns the
switch off . Only waits a second to connect , I need to increase that but it works fine for me.
I show this was as something to look at for larger TextFields to edit in and connect disconnect code idea.
Ignore Ping and Ticks screen fields they only put up test values for positioning fields on screen right now.
Should not have to use iTunes but you can. The zip file contains the TB code which is the same as posted here.
Just email the text of the TB code to your iPad and copy and paste it into a new TB project.
Serial connections on AB board are on pins 8,9 and C code shows using #ifdef to select that at build time as well
as turning on and off the printing to terminal for DEBUG by commenting out the defining of DEBUG
Tom
I'll try and test your code tonight ,my daughter is using the ipad for school work so I have to wait my turn.
@Jeff,
I was thinking the ping reading could be a meter or bar graph ,the closer the object the higher the meter reading. just thinking .....
@Rich,
Cool sensor ,I think we have some bugs to work out first.
Brian
I spoke with Brian today after running all of the example programs from Brian, Tom, Jeff and Rich. I was really impressed about the stability of the whole system once it was properly configured and running. I had a couple of talking points to bring up to see what everybody thinks about next steps:
- Between baud rates and timeouts in the TB code, do you think we could make the data exchange a bit more real-time?
- For the tilt-pad controller program, would it be possible to integrate the TB graphing options around the dual-axis accelerometer so one could see the sensor effect visually?
I know we should be a bit more formal about some requirements, but I think we're still making lots of improvement and learning quite a bit, so that when the data exchange is fully ironed out it'd be a matter of polishing the TB/C code examples.In related news, today we successfully downloaded a 32KB Propeller program from an iPad to the Propeller over XBee WiFi. We have had Mike from TechBASIC (ByteWorks) at our office working with Jeff (our internal dev tools engineer) to see what they could achieve. As it stands, the code is sorta clunky and full of debugging bits, but now they'll clean it up and try to formalize the program download process. And this was all done without the use of co-processors to buffer the program!
Pretty neat, eh?
Ken Gracey
WOW ,It was great to put a voice behind the name !!
Way off the subject ,but this is how we build Pinewood Derby Cars in MN
Brian
Great you got the examples to run and had Byte Works in house and looking over our stuff.
When you say make the data exchange more real time, what do you mean.
Maybe a better way to ask is do you have some high speed thing in mind or
did it just seem sluggish to you.
I believe Jeff and Brian have the Acell data going out at 0.1 sec right now.
In one of the test I did to test my messaging way and also as a test for Jeff who
was seeing data errors with his code I tried different code to see if I got errors I sent 6 bytes out and back every 0.1 sec with
no errors and experimented with going 0.050 sec and it worked with no errors and the
red and blue led's next to the XBee were on solid. For some reason the XBEE would
pause for a 0.5 sec every once in a while but recover. Both lights would go out then come back on.
So it could go faster on sending Acell data but keep in mind if one aspect is going all out sending
Acell data there is no time left to do anything else.
We will have to experiment.
I view sending Acell data out for steering control the high priority task and receiving data to display on the iPad screen
lower priority. You do not have to send the Acell data to the AB and get it back from the AB to plot it.
We can plot as we send and we do not have to plot every set of data points we send if we are going to send at some taxing speed.
Great on the download possibility.
Tom
It looks to me that iOS only supports a sensor sample rate of .01 seconds at the fastest. So I don't know if speeding up baud rates will make it closer to real time.
Brian
There are two different rates involved.
the 0.01 sample rate you tell IOS to sample the Accelerometer sensor in the background with this TB statement
sensors.setAccelRate(0.01)
If I remember the TB manual says to not sample at the fastest rate as it will drag down IOS doing that.
The other rate which control is how often you send the values out the serial port over to the AB in the
nullevent subroutine.
This is the 0.1 sec I was referring to and could go a bit faster.
This statement in SUB null event controls that
IF System.ticks-t>0.1 THEN
I was using setAccelRate(0.05) when putting the values on the screen
I wonder if the sluggishness Ken was referring to was a result of using 0.01
I say that based on what TB Manual said, I need to go reread that section.
@Ken
If you go into the TB code and edit that line to sensors.setAccelRate(0.05) does it improve
the real time response you were thinking of.
Since we are only using the sampled values every 0.1 sec using an IOS sample rate of 0.05 gives two samples
for everyone we use.
Tom
I'm trying your post 289 code, it doesn't seem like it's connecting and I've checked all of the normal problem areas (pins ,port ,baud ,ect).
I just looked at your screen shot ,I'm missing all the buttons on the upper right side (connect, led, quit) ,I have a ipad 2.
Brian
Seems there is an issue with different screen resolutions. When Jeff told me my screen pics of his code looked
right I felt maybe we all were the same.
When doing the code I tried the TB Graphics.Width and backoff of that to position things but it did not work.
So all my positions were hand tweeked.
I have advanced a bit more and am receiving wheel ticks from the AB and will try ping sensor next.
.
Is your iPad2 a Retnia display, I am thinking not
In the TB code you will find this statement
!! Graphics.Width is not the right edge?? so tweeked it
xright = Graphics.Width + 150
xright positions those items where they are try some lower values like get rid of the 150 to start
even try some values totally manual like xright = 200
It would be interesting to know what number for xright puts the items in the same spot on your screen
Edit: One of the switches you are missing you turn on to connect. It turns green when it connects.
Tom
xright = Graphics.Width - 100 ,is what it takes for me to see the sliders.
I did get it to connect , I entered 500 for left and right and the aBot took off with no thought of stopping
Brian
500 WOW the max speed number for AB abdrive is 128 or -128 .
The test app is designed to allow experimentation of abdrive lib's commands from the iPad screen
using the Learn Activity Bot Tutorial series Navigation Basics
http://learn.parallax.com/activitybot/go-certain-distances
Your right I do not test for bad data. The human is responsible for that :thumb:
Thank's for the info on Graphics Width. We will need to figure a way to put things on the iPad
screen on various versions of the iPad. I thought Graphic.Width and then back up the width of the
controls being placed would do it but I needed a fudge factor +150 on Retina and you say -100 on
non Retina.
Late last night I have a new version which displays wheel ticks and ping sensor distance.
Displays values at the end of each operation right now to test getting the right numbers on the screen
Have to look it over some more before posting updated version.
Tom
That is what I would expect and should place the switch at the right of the screen, in view and independant of screen resolution. I don't understand why you are having to add 150 to get it there.
Tom, when I look at the screen shot you provided in post #266 everthing looks proportional and everything looks like it is placed where it should be, the title, activity bot graphic and status bar all fit. Compare it to the screen shots in posts #200 and #219. What values do you get when you assign the screen width and height to a variable for display in the console.
A little later I will try your TB code and see what the results are here.It would be nice to determine what the differences are.
Jeff