Here is the my iPad app Post #266 that now displays values sent back from the AB on the iPad screen
It is displaying left and right wheel ticks and ping distance in inches.
It displays after an operation not on the fly for this version.
For set up you need to change the #defines to match your pins in the C code.
ABOT is defined in the file now.
// Comment or UnComment the next line to move the bot
#define MOVBOT
#define MAXCHARS 78
// Serial connection of XBEE Wifi to Activity Board or Board of Education
// Comment or Uncomment to select one
//#define BOE
#define ABOT
#ifdef BOE // XBEEwifi connected pins
#define RX 10
#define TX 9
#define PINGPIN 7
#endif
#ifdef ABOT // XBEEwifi connected pins
#define RX 9
#define TX 8
#define PINGPIN 7
#endif
It takes a few moments on the first movement command after connect to move but after that it responds right away.
I do not know if the Wifi is waiting to see if more is coming or what?
Every once in awhile clicking the goto buttton to execute a goto sequence I disconnect. Assume it is my code but
I do not see a difference between that and other movement execution?
I do not know if Andy is following this thread but I wonder if there is a way to clear the wheel ticks count other than
resetting the AB. It is acumulating right now. Good for going out several feet with 128,128 then backing up the same
pause time with -128,-128 and seeing how close to 0,0 it is. For me +/- 2 counts. Using ramping.
As I stated earlier the app is for experimenting with abdrive commands and moving the bot around.
Also sending and getting back info from the AB.
I am using my A3 message to send info back one var at a time sending several messages rather than one big
message. I wanted to test how that worked. It is a style of screen updating where everything is not absolute in sync
but you do not need to know ahead everything you ever want to display. The other way you have to think of everything
in the beginning and then later when you think of something else you have to go in and modify the code to send more
bytes. Humans do not see things updating on the screen fast enough to not know it came in at different times if at
least send them individually at a reasonable rate.
@jeff Good to hear from you, I wondered if a storm had got your power
tdlivings said, "...is there a way to clear the wheel ticks count before each sequence of operations other than resetting the AB?"
Sorry, not currently. Will be doing maintenance in a couple weeks and added it to the list. The main file can currently track distance for a given maneuver like this:
int leftOld, leftNow, left, rightOld, rightNow, right;
drive_getTicks(&leftNow, &rightNow);
leftOld = leftNow;
rightOld = rightNow;
drive_goto(128, 128);
drive_getTicks(&leftNow, &rightNow);
left = leftNow - leftOld;
right = rightNow - rightOld;
[edit] drive_getTicks(leftNow, rightNow); changed to drive_getTicks(&leftNow, &rightNow); in code. [/edit]
Jeff: techBASIC is currently available for the iPhone and iPad, but we are looking at ports. If you would like to vote for a port or a feature, drop me a note at support@byteworks.us.
Probably not a problem, but I don't know for certain.
My experience with embedded WiFi was both challenging and disappointing by watching our engineers work on a project for several years that never saw completion. The Wifly and XBee S6B devices likely operate similarly as far as techBASIC is concerned, but I really wouldn't know. Perhaps the most important reason to use the XBee devices is because that's what we're selling and supporting at Parallax. Drop me an e-mail kgracey@parallax.com and I'll get you the XBee S6B (choose chip or wire antenna) so you're using the same hardware.
Even if you have an XBee WiFi, I think it's good to have that SparkFun Wifly device as well. We really don't know if either of these devices have issues. And if our efforts serve both hardware platforms that'd be great.
I think it'd be best if you had both pieces of hardware. Drop me your info.
Ken Gracey
That's actually correct. techBASIC is just talking over a TCP/IP port. I tested my initial XBee and Propeller code using the WiFly Terminal sample app built into techBASIC. I had to change the IP address and port, but everything else worked as-is.
For what it's worth, if the XBee is set up on your local network, the default TCP/IP port is 9750. Keep in mind that the XCTU software used to configure the XBee shows the port number in hexadecimal, while it is (unusually) encoded in decimal in techBASIC. The TCP/IP address depends on your network, but XCTU will show you the address, and let you change it if you need to for some reason.
It's not that Apple has restrictions on file types. It's that iOS does not have UI methods for file access outside of apps (no Finder or Desktop and no Open/Save dialogs built into the OS). Most apps that handle specific file types can accept files directly from other apps such as the Mail app. If techBASIC is set to handle files with a specific extension (.bas ?), then you should be able to press the attachment box in the Mail message, which brings up an "Open in AppName" chooser, listing all of the apps that can open that file type.
I'm sending .spin files to my own app, which opens them as well as .zip archives of libraries, with out issue!
Here's an example of opening an attached .spin file in an email message, with my test app named 'spinTab':
I wish that were true. Unfortunately, it really is an issue with Apple's restrictions, not a technical one. For example, for a long time we had the ability to move source code to and from the iPad using iTunes--you could just dump a program file over there, or move one back. You can still do that for data files, but Apple made us remove that feature.
The specific restriction relates to source code of any kind. We are not allowed to download it to the iPad in any form whatsoever. Supporting apps that would move files to and from techBASIC would apparently count, since they made us remove iTunes support.
It's probably in the manual somewhere but I discovered that a transmitted string is terminated with a newline character decimal 10, there is no programming this newline its just added even on a single ASCII character. Something else that surprised me, and this may be something with the Wifly I don't know, but the characters that were echoed back were transposed and all I can think right now is that the Wifly was delivering data in a last in first out manner. That is something I will look at closer a little later.
Jeff T.
The newline character comes from the PRINT statement. For example,
PRINT "Hello"
will print the characters in the string followed by a newline character. You can suppress the newline character by placing a ; at the end of the line, like this:
PRINT "Hello";
If you want to append a carriage return (or whatever), the line might look like this:
PRINT "Hello"; CHR(13);
You can also move to the PUT command, which is a bit more complicated for strings, but offers true bye-by-byte control over the output stream, including support for sending numbers.
Jeff,
Got my xbee hooked up ,loaded your code on the ipad & ran it :
Comm.openTCPIP(1,"my_xbee_ip",my_xbeeport)
sensors.setAccelRate(0.01)
DIM quit AS Button
quit=GraphicsNewButton(10,10) <<<< getting "Runtime error: Type mismatch"
Thanks' Brian
Hi Brian,
Someone else may have already pointed this out, but you need a dot between graphics and newButton, like this:
Are any of you using the Digi Xbee Wi-Fi module that Parallax now sells? I've been working with it for a while and am having a problem with transfers of large amounts of data to the module from the PC. It seems like the Xbee throws away data when it's buffers fill up without attempting to do TCP/IP flow control back to the host. Have you noticed that? I'm trying to determine if this is a characteristic of the Xbee module or if it is a bug in my code. I'm using API mode which means that I receive data in frames rather than just a continuous stream of data. Are you using transparent mode where you just get the data sent by the PC and no header information containing the source IP address, port, etc?
Hi David,
I've been doing some work with the XBee using TCP/IP. What I've found is there is a 2K (roughly) buffer. The slowest part of the techBASIC-iOS-Wifi_XBee-serial-Propeller link is the serial port. That means the program can easily overflow that buffer, leading to lost characters.
My solution, which seems to work pretty well, is to start a timer when I send the first chunk of bytes to the XBee. I then track how many bytes the serial port can send. Periodically, I send another packet of bytes-but only enough to fill the buffer to about 90% capacity. I've had really good luck keeping the pipeline full this way so the serial port is performing at full speed.
Also, the largest packet size for the communication is 1400 bytes. This is hard-coded in the XBee. If you send too many very small packets too quickly, iOS "helps" you by bundling them up into chunks. I'd wait until there were at least 100 bytes to send before writing them using TCP/IP.
Jeff
On the Tech Basic side we only have an array of bytes and no way to cleanly define message content.
The matching C data type for integer and TB is int16_t or uint16_t . On the C side they are 4 bytes for integers not two.
My experiment is to send -1000 as an integer from TB and see if I get $FC18 which is -1000 or $18FC which is 6396 indicating the two sides
are not the same byte order wise.
Tom
More later
Tom
Hi Tom,
Take a look a the openTCPIP command in the manual. There is an optional bigEndian parameter that might help. Specifically, if you code
openTCP/IP(1, <host>, <port>, 0)
techBASIC will flip the byte order.
While a techBASIC INTEGER type is 2 bytes, you also have a LONG type. That's a 4-byte signed integer.
If you really want to get down and dirty and use GET and PUT to get full control of the binary I/O stream, take a look at the helper functions in the Math class, like packInt and packDbl. Also, techBASIC has bit operations that can be used to peel apart or pack integers.
Let me know if any of this doesn't quite make sense, or if you are missing something you need.
As you can tell from the large number of posts, I've been away from the thread for a while. I'll try to stay more current.
Meanwhile, I read through the posts pretty quickly. If I missed a question or problem that relates to techBASIC, let me know, either by reprompting me here or dropping me a line at support@byteworks.us.
Incidentally, this all looks very cool. Jumping back in at this date, can someone point me to the most recent hardware configuration/spin code/techBASIC code so I can catch up?
I've been doing some work with the XBee using TCP/IP. What I've found is there is a 2K (roughly) buffer. The slowest part of the techBASIC-iOS-Wifi_XBee-serial-Propeller link is the serial port. That means the program can easily overflow that buffer, leading to lost characters.
My solution, which seems to work pretty well, is to start a timer when I send the first chunk of bytes to the XBee. I then track how many bytes the serial port can send. Periodically, I send another packet of bytes-but only enough to fill the buffer to about 90% capacity. I've had really good luck keeping the pipeline full this way so the serial port is performing at full speed.
Also, the largest packet size for the communication is 1400 bytes. This is hard-coded in the XBee. If you send too many very small packets too quickly, iOS "helps" you by bundling them up into chunks. I'd wait until there were at least 100 bytes to send before writing them using TCP/IP.
Thanks for the explanation. I'm using TCP mode as well but I'm using the frame-based API mode. I've been successful at downloading large programs but only if I pace the data coming from the PC. Unfortunately, this isn't easy to do if a web browser is sending the data with HTTP requests. I guess I could have it send lots of tiny HTTP requests but my guess is that would be very slow. How do you handle loading 32k of hub memory? Does your code that receives the data run entirely in a COG? Or maybe you write the program to the EEPROM first?
I wish that were true. Unfortunately, it really is an issue with Apple's restrictions, not a technical one. For example, for a long time we had the ability to move source code to and from the iPad using iTunes--you could just dump a program file over there, or move one back. You can still do that for data files, but Apple made us remove that feature.
The specific restriction relates to source code of any kind. We are not allowed to download it to the iPad in any form whatsoever. Supporting apps that would move files to and from techBASIC would apparently count, since they made us remove iTunes support.
So, you're saying that the only way to move source code to the iPad TechBasic app is to send ".txt" files via email or some other app and then copy/paste to get your code into TechBasic? So, basically, it's better to just build a controller type app to send commands and receive data from a bot...
Mike
Thank's for the info and all the posts.
I did get 16bit values back and forth from iPad and AB in my messages without the optional Big Endian parameter.
I will take a look at the math lib you mentioned.
One issue we are having with TB is positioning of controls on various versions of the iPad.
We have been fixing the orentation to one way to avoid the hassle of covering how one is holding the iPad
but I may have not understood the TB statement Graphics.Width
I figured I could get the right side of the screen and then when defining a control back up from that to put the control
on the right side.
See my screen shot in post #289 for the controls in upper right of screen. The latest version of that test app is in post #302
I have a 4th gen iPad Retina and others an iPad2 . I needed to fudge Graphics.Width by adding 150 and Brian needed to use -100
See posts #297 - #299
Could be Graphics.Width does not mean screen pixels ?
Could be Graphics.Width does not mean screen pixels ?
Hi Tom, thats what I was trying to say in an earlier post. The screen coordinates are measured in "points" and from what i gather all iPads are 1024 x 768 points.
When it comes to pixels the Retina have a resolution of 2048 x 1536 pixels and non retina have a resolution of 1024 x 768 pixels. Even though the Retina has doubled the width and height in pixels the screen coordinates still remain at 1024 x 768 points. The clarity is better on the Retina because it has 4 pixels for every point whereas the non Retina has 1 pixel per point.
This is why I am confused that when you use Graphics.Width to position a switch it does not display where you would think it would. Ken, Brian and myself are not seeing what you are seeing, as far as I can tell, so there is some subtle difference. We need to pin down whats happening, maybe Mike has the answer.
Here is a work in progress to test.
I need to put in the ping sensor code and a couple of times for me it went into weeds
even though it seemed to be still connected, something to debug .
The short is I was driving the AB around on the floor with this and post it for you to test
and let me know how it works for you.
I edited the TB code so xright is -100 and I have the ip address everyone is using, if not just edit it on screen.
I will post more detail on what I did but the short is I used a look up table to give me ticks to add to speed for
turning angles of 0 to 90 deg clockwise and counter clockwise.
Same as my previous program connect by clicking the connect switch and it turns green on connect.
The iPad only steers the AB by twisting like a steering wheel. I am using Y accel.
There is a slider for throttle position, slide it up to move at throttle value 0 to 128
I have to move it a couple of times on first run of app, do not know why , just move it up and move it a little again.
After that it responds right away.
Had same issue with previous app not taking right off on first connect.
Best to select Forward or Reverse when stopped, After hitting All Stop.
Start off with slow speed like 40 to 64.
Hold iPad at an angle and it turns in a circle
Remember when it is coming at you turn iPad in oppisite direction you want to turn
Let me know. I have only had it working tonight 1am now in Mich
Tom
I added the Ping sensor to the previous post code to show updating the iPad display with sensor data.
Only one sensor in this case but could be more.
The sensor processing code runs in it's own cog and updates a globel var in main which the main loop reads
to update the iPad .
Sending and receiving messages in multiple cogs could cause overwrite of message buffer data so the sensor
processing does not send the values to the iPad
The basic operation of the main loop is to
Wait for a message
Process the message
Update iPad with sensor data.
Go back and wait for a message
The program becomes event driven by messages coming in.
The iPad sends in Accel values at tpause rate of 0.1 sec other messages are user paced.
The TB code is the same for this version as the last so no need to install TB code on iPad a second time.
The reason for the look up table for steering angle is to adjust the steering sensitivity without trying to calculate
some math expression to do it. Right now it is linear 0 to 90 deg.
Right now it is one linear file for the C code with all the message processing for all my experiments, for example
the A7 message is not used for steering program. The TB code for this program never sends that message. I left it
in the switch case because that was easier than messing it up by editing it out.
Has anyone actually tried driving around using the code to test steering .
Did the change to xright -100 work out for your ipad's or did it mess things up for those with retina displays
like mine.
I find it drives around my basement quite well. Drives like a car with iPad doing steering although you have to be carefull
in walking around following AB as you send accel values by your own movements.
I figured out what I was doing wrong with calculating xright to get the GUI controls on the right edge.
I was looking at the Example accelerometer in Mike's book and it jumped out at me that the example was executing
Graphics.ShowGraphics before defining the GUI elements and orientation.
My thought process from other programming of non iPad things was that when you executed Graphics.ShowGraphics
that is when it switched to the graphics screen so I did that last after defining everything.
BUT not so it appears. It appears it must be in the graphics screen for a given orientation to have Graphics.Width be the
right value.
I did some experimenting and it works when I moved the following code above defining GUI elements.
I can place the switches right on the right edge by using xright = Graphics.Width - 80 because the switches have a
width of 79. I moved them over a bit more with -120 to get away from the tools wrench.
REM **** FIX FOR GETTING GUI ELEMEMTS ON RIGHT SIDE ****
REM USE FULL SCREEN
REM Tools wrench still in upper right
System.showGraphics(1)
REM SHOW GRAPHICS WITH DEBUGGER TOOLBAR
!System.showGraphics
!Only allow landscape home on right
System.setAllowedOrientations(4)
Graphics.setFont("Monospaced",18,1)
xcenter = Graphics.Width/2
! Place controls at GUI right edge - 120 pixels
! right - 80 would put the left side of switches
! at the right edge but tools wrench then overlays
xright = Graphics.Width -120
REM Define GUI elements after showing graphics
DIM quit AS Button
quit = Graphics.newButton(xright,250)
quit.setTitle("Quit")
I replaced the project zip file in my previous post with updated TB code and renamed it to show it is the fixed version
@Tom,
Sorry it took so long to test ,I've been trying to find the right molecular sieve for a project I'm working on (long story). Seems to work fine ,I'll give it to the kids to test and then I'll report back.
Brian Hi
I have not thought about this in awhile, project seemed to be in a time out.
You say the Tech Basic side just stays on the source view when you hit run.
My guess is it will do that if there is an error in the code but I do not see any when
I use the code. I wonder if my fix for getting the control elements on the right side has
produced some x,y values that crash the code.
I will go look at the code and refresh myself later.
When I am driving my AB around with the code I have to wiggle the speed slider a second time on first
launch and after that it responds right away. I have not had it lose comm in driving around in my basement.
Are the red and blue lights flashing by the XBEE when this happens.
@Jeff with your ipad2 does the TB code switch to the run screen with the controls on the right side or does it
crash like Brian is seeing
Being I don't know what happened here I'm picking up at the last good code I have. That would be Ipad code from post #220 and Actbot code from #279 , I'm going to add a ping readout to the ipad code.
Comments
It is displaying left and right wheel ticks and ping distance in inches.
It displays after an operation not on the fly for this version.
For set up you need to change the #defines to match your pins in the C code.
ABOT is defined in the file now.
It takes a few moments on the first movement command after connect to move but after that it responds right away.
I do not know if the Wifi is waiting to see if more is coming or what?
Every once in awhile clicking the goto buttton to execute a goto sequence I disconnect. Assume it is my code but
I do not see a difference between that and other movement execution?
I do not know if Andy is following this thread but I wonder if there is a way to clear the wheel ticks count other than
resetting the AB. It is acumulating right now. Good for going out several feet with 128,128 then backing up the same
pause time with -128,-128 and seeing how close to 0,0 it is. For me +/- 2 counts. Using ramping.
As I stated earlier the app is for experimenting with abdrive commands and moving the bot around.
Also sending and getting back info from the AB.
I am using my A3 message to send info back one var at a time sending several messages rather than one big
message. I wanted to test how that worked. It is a style of screen updating where everything is not absolute in sync
but you do not need to know ahead everything you ever want to display. The other way you have to think of everything
in the beginning and then later when you think of something else you have to go in and modify the code to send more
bytes. Humans do not see things updating on the screen fast enough to not know it came in at different times if at
least send them individually at a reasonable rate.
@jeff Good to hear from you, I wondered if a storm had got your power
Tom
Sorry, not currently. Will be doing maintenance in a couple weeks and added it to the list. The main file can currently track distance for a given maneuver like this:
[edit] drive_getTicks(leftNow, rightNow); changed to drive_getTicks(&leftNow, &rightNow); in code. [/edit]
That's actually correct. techBASIC is just talking over a TCP/IP port. I tested my initial XBee and Propeller code using the WiFly Terminal sample app built into techBASIC. I had to change the IP address and port, but everything else worked as-is.
For what it's worth, if the XBee is set up on your local network, the default TCP/IP port is 9750. Keep in mind that the XCTU software used to configure the XBee shows the port number in hexadecimal, while it is (unusually) encoded in decimal in techBASIC. The TCP/IP address depends on your network, but XCTU will show you the address, and let you change it if you need to for some reason.
I wish that were true. Unfortunately, it really is an issue with Apple's restrictions, not a technical one. For example, for a long time we had the ability to move source code to and from the iPad using iTunes--you could just dump a program file over there, or move one back. You can still do that for data files, but Apple made us remove that feature.
The specific restriction relates to source code of any kind. We are not allowed to download it to the iPad in any form whatsoever. Supporting apps that would move files to and from techBASIC would apparently count, since they made us remove iTunes support.
The newline character comes from the PRINT statement. For example,
will print the characters in the string followed by a newline character. You can suppress the newline character by placing a ; at the end of the line, like this:
If you want to append a carriage return (or whatever), the line might look like this:
You can also move to the PUT command, which is a bit more complicated for strings, but offers true bye-by-byte control over the output stream, including support for sending numbers.
Hi Brian,
Someone else may have already pointed this out, but you need a dot between graphics and newButton, like this:
Hi David,
I've been doing some work with the XBee using TCP/IP. What I've found is there is a 2K (roughly) buffer. The slowest part of the techBASIC-iOS-Wifi_XBee-serial-Propeller link is the serial port. That means the program can easily overflow that buffer, leading to lost characters.
My solution, which seems to work pretty well, is to start a timer when I send the first chunk of bytes to the XBee. I then track how many bytes the serial port can send. Periodically, I send another packet of bytes-but only enough to fill the buffer to about 90% capacity. I've had really good luck keeping the pipeline full this way so the serial port is performing at full speed.
Also, the largest packet size for the communication is 1400 bytes. This is hard-coded in the XBee. If you send too many very small packets too quickly, iOS "helps" you by bundling them up into chunks. I'd wait until there were at least 100 bytes to send before writing them using TCP/IP.
Hi Tom,
Take a look a the openTCPIP command in the manual. There is an optional bigEndian parameter that might help. Specifically, if you code
techBASIC will flip the byte order.
While a techBASIC INTEGER type is 2 bytes, you also have a LONG type. That's a 4-byte signed integer.
If you really want to get down and dirty and use GET and PUT to get full control of the binary I/O stream, take a look at the helper functions in the Math class, like packInt and packDbl. Also, techBASIC has bit operations that can be used to peel apart or pack integers.
Let me know if any of this doesn't quite make sense, or if you are missing something you need.
Meanwhile, I read through the posts pretty quickly. If I missed a question or problem that relates to techBASIC, let me know, either by reprompting me here or dropping me a line at support@byteworks.us.
Incidentally, this all looks very cool. Jumping back in at this date, can someone point me to the most recent hardware configuration/spin code/techBASIC code so I can catch up?
John Abshier
So, you're saying that the only way to move source code to the iPad TechBasic app is to send ".txt" files via email or some other app and then copy/paste to get your code into TechBasic? So, basically, it's better to just build a controller type app to send commands and receive data from a bot...
Thanks Mike!
dgately
Thank's for the info and all the posts.
I did get 16bit values back and forth from iPad and AB in my messages without the optional Big Endian parameter.
I will take a look at the math lib you mentioned.
One issue we are having with TB is positioning of controls on various versions of the iPad.
We have been fixing the orentation to one way to avoid the hassle of covering how one is holding the iPad
but I may have not understood the TB statement Graphics.Width
I figured I could get the right side of the screen and then when defining a control back up from that to put the control
on the right side.
See my screen shot in post #289 for the controls in upper right of screen. The latest version of that test app is in post #302
I have a 4th gen iPad Retina and others an iPad2 . I needed to fudge Graphics.Width by adding 150 and Brian needed to use -100
See posts #297 - #299
Could be Graphics.Width does not mean screen pixels ?
Tom
Hi Tom, thats what I was trying to say in an earlier post. The screen coordinates are measured in "points" and from what i gather all iPads are 1024 x 768 points.
When it comes to pixels the Retina have a resolution of 2048 x 1536 pixels and non retina have a resolution of 1024 x 768 pixels. Even though the Retina has doubled the width and height in pixels the screen coordinates still remain at 1024 x 768 points. The clarity is better on the Retina because it has 4 pixels for every point whereas the non Retina has 1 pixel per point.
This is why I am confused that when you use Graphics.Width to position a switch it does not display where you would think it would. Ken, Brian and myself are not seeing what you are seeing, as far as I can tell, so there is some subtle difference. We need to pin down whats happening, maybe Mike has the answer.
Jeff
I need to put in the ping sensor code and a couple of times for me it went into weeds
even though it seemed to be still connected, something to debug .
The short is I was driving the AB around on the floor with this and post it for you to test
and let me know how it works for you.
I edited the TB code so xright is -100 and I have the ip address everyone is using, if not just edit it on screen.
I will post more detail on what I did but the short is I used a look up table to give me ticks to add to speed for
turning angles of 0 to 90 deg clockwise and counter clockwise.
Same as my previous program connect by clicking the connect switch and it turns green on connect.
The iPad only steers the AB by twisting like a steering wheel. I am using Y accel.
There is a slider for throttle position, slide it up to move at throttle value 0 to 128
I have to move it a couple of times on first run of app, do not know why , just move it up and move it a little again.
After that it responds right away.
Had same issue with previous app not taking right off on first connect.
Best to select Forward or Reverse when stopped, After hitting All Stop.
Start off with slow speed like 40 to 64.
Hold iPad at an angle and it turns in a circle
Remember when it is coming at you turn iPad in oppisite direction you want to turn
Let me know. I have only had it working tonight 1am now in Mich
Tom
Only one sensor in this case but could be more.
The sensor processing code runs in it's own cog and updates a globel var in main which the main loop reads
to update the iPad .
Sending and receiving messages in multiple cogs could cause overwrite of message buffer data so the sensor
processing does not send the values to the iPad
The basic operation of the main loop is to
Wait for a message
Process the message
Update iPad with sensor data.
Go back and wait for a message
The program becomes event driven by messages coming in.
The iPad sends in Accel values at tpause rate of 0.1 sec other messages are user paced.
The TB code is the same for this version as the last so no need to install TB code on iPad a second time.
The reason for the look up table for steering angle is to adjust the steering sensitivity without trying to calculate
some math expression to do it. Right now it is linear 0 to 90 deg.
Right now it is one linear file for the C code with all the message processing for all my experiments, for example
the A7 message is not used for steering program. The TB code for this program never sends that message. I left it
in the switch case because that was easier than messing it up by editing it out.
Has anyone actually tried driving around using the code to test steering .
Did the change to xright -100 work out for your ipad's or did it mess things up for those with retina displays
like mine.
I find it drives around my basement quite well. Drives like a car with iPad doing steering although you have to be carefull
in walking around following AB as you send accel values by your own movements.
Tom
I was looking at the Example accelerometer in Mike's book and it jumped out at me that the example was executing
Graphics.ShowGraphics before defining the GUI elements and orientation.
My thought process from other programming of non iPad things was that when you executed Graphics.ShowGraphics
that is when it switched to the graphics screen so I did that last after defining everything.
BUT not so it appears. It appears it must be in the graphics screen for a given orientation to have Graphics.Width be the
right value.
I did some experimenting and it works when I moved the following code above defining GUI elements.
I can place the switches right on the right edge by using xright = Graphics.Width - 80 because the switches have a
width of 79. I moved them over a bit more with -120 to get away from the tools wrench.
REM **** FIX FOR GETTING GUI ELEMEMTS ON RIGHT SIDE **** REM USE FULL SCREEN REM Tools wrench still in upper right System.showGraphics(1) REM SHOW GRAPHICS WITH DEBUGGER TOOLBAR !System.showGraphics !Only allow landscape home on right System.setAllowedOrientations(4) Graphics.setFont("Monospaced",18,1) xcenter = Graphics.Width/2 ! Place controls at GUI right edge - 120 pixels ! right - 80 would put the left side of switches ! at the right edge but tools wrench then overlays xright = Graphics.Width -120 REM Define GUI elements after showing graphics DIM quit AS Button quit = Graphics.newButton(xright,250) quit.setTitle("Quit")I replaced the project zip file in my previous post with updated TB code and renamed it to show it is the fixed version
We need someone to test on an iPad2 .
Tom
Jeff.
Sorry it took so long to test ,I've been trying to find the right molecular sieve for a project I'm working on (long story). Seems to work fine ,I'll give it to the kids to test and then I'll report back.
Brian
I was on vacation and forgot to post before I left.
The first version I downloaded from post 318 ,would work for awhile and then lock up leaving the abot still wandering around.
I downloaded the version that is posted now and can't get it to start ,is doesn't give a error, it just stay's at the source code screen.
Brian
I have not thought about this in awhile, project seemed to be in a time out.
You say the Tech Basic side just stays on the source view when you hit run.
My guess is it will do that if there is an error in the code but I do not see any when
I use the code. I wonder if my fix for getting the control elements on the right side has
produced some x,y values that crash the code.
I will go look at the code and refresh myself later.
When I am driving my AB around with the code I have to wiggle the speed slider a second time on first
launch and after that it responds right away. I have not had it lose comm in driving around in my basement.
Are the red and blue lights flashing by the XBEE when this happens.
@Jeff with your ipad2 does the TB code switch to the run screen with the controls on the right side or does it
crash like Brian is seeing
Thank's for the update
Tom
Ken does the offer for artwork still stand?
Brian