I am waiting for XBEE wifi boards, so I will move to the ActivtyBot code next. I can either send the two raw data values, or I could pass an instruction like:
Bruce,
Seems to work fine ,I did notice a little glitch on the left and right tilt. once in awhile the left hand numbers go missing when you tilt left or right just a little past horizontal.
I have been looking at my first piece of code for this project. The result is a techBASIC non-graphic program to measure movement (tilt) on he iPad.
The program displays four values: number and text representing the movement up or down of the right side of the iPad, number and text representing the movement of the top edge of the iPad away from or toward the user.
It is set so you can hold the iPad at about 45 degrees in front of you and that is neutral. The two numbers that are output range from -125 to125 so they should be usable as right/left, forward/backward movement of the ActivityBot.
Possible updates:
- make it graphical
- add touch so you could 'point' at where you want the ActivityBot to go.
- increase the size o the neutral zone - the area where slight movements do not send movement values to the ActivityBot
- Suggestions welcome
@Br1wr2el3, I posted a similar code a bit earlier and knew that I'd somehow need to adjust the code to get a comfortable 45 degrees neutral position. Now I don't need to invent the wheel for the zillionth time, so thanks!
Monday is Martin Luther King Day and we decided to close Parallax and give everybody a day off. This means I'll be able to jump in on this project, finally! Should be a lot easier to get the basic setup working since everybody else has already poured hours into the effort. Looking forward to Monday - I'll go to bed so the morning arrives faster.
I don't have a activity bot ,but I have 2 servos connected to the PropBoe board , for right now I'm using a modified wifi terminal program (from book) to send letters(from the iPad key pad) to the xBee . The letter "f" makes the servo's go forward ,the letter "r" makes them go backwards and The letter "s" makes them stop.
Although a fairly simple program it gives me the building blocks to build on and yes it's always cool to see something move
Brian
Brian, congrats! If you try some of the GCC examples in this thread you should be able to control the servos through tilting your iPad. That is similar as we are doing on the ActivityBot.
Welcome to our first Open Propeller Project! This project stems from a prior effort we launched in these forums - programming a Propeller from an iPad and a movement quietly underway by banjo, unsoundcode and Mike Cook. You loaded the original discussion thread with every possible solution and educated us about new possibilities we hadn't considered. Many alternatives suggested were quite interesting, including a Propeller web-based programming interface and the concept of a "configurable" robot that completes actions using a serial exchange over XBee S6B modules.
With that in mind, here are the goals for the first Open Propeller Project:
Control an ActivityBot's direction and speed from an iPad using TechBASIC.
Receive data from the Ping))) Ultrasonic Distance Sensor on the iPad and control the ActivityBot in a semi-autonomous fashion. While the robot would roam autonomously with the Ping))) sensor, the user would have the option to re-orient the ActivityBot's speed and direction anytime from the iPad.
And for a bonus round:
Should anybody be so inspired, could the ActivityBot run a fixed set of firmware that is configured with a string of serial commands to define its behavior? As an example: play different wav files when different sensors are actuated.
Ken Gracey
Ken, have you thought about who are in the target group? Students, teenagers, grampies etc.?
Just asking so we know how "flashy" the GUI on iPad should be. I know we are quite free to steer it in whatever directions, but would be good to know your thoughts
Any suggestions are welcome. Generally, if the value goes away it is zero. I may have to update that.
Next is a GUI, and I do not have a clear picture of it yet.
Bruce,
My son has a construction game on his android ,he drives his construction equipment around by turning it like a steering wheel and leaning it forward and back for speed, so that is my general direction I'm headed.
I'm making sure that I have a full understanding how everything is working, because I have a feeling that Ken is still holding onto the other shoe.
Ok, with the below code I'm now able to control an ActivityBot from iPad with only smaller issues.
The timing settings, especially on TechBasic side, are sensitive so they might need some tuning to get it to work. There's for sure some better way to do it, but I've so far not been successful with any other setup.
There's a slight delay every now and then that I don't know how to get rid of. Perhaps a direct connection would work better instead of going through the router, but I've not been able to get that to work.
The only possibility for me to config the XBee is through AT codes as I don't have any USB adapter boards, and it is quite cumbersome and error prone...
This is the relevant part of the GCC code
int x, y;
int i=0;
int cm;
int tx_result, receiving;
short int ping_now = 0;
drive_setRampStep(12); // 7 ticks/sec / 20 ms
while(1)
{
cm = ping_cm(8);
x = fdserial_rxChar(xbee); // receiving x (speed) from iPad
y = fdserial_rxChar(xbee); // receiving y (direction) from iPad
tx_result = fdserial_txChar(xbee, cm); // sends the distance to iPad
if(x != -1)
{
if(y != -1)
if(x > 124 && x < 130) // "dead zone" to avoid jittering speed
drive_speed(0, 0);
if(x > 129)
{
drive_rampStep((0 - (x - 127) - (y - 127)), (0 - (x - 127)) - (127 - y));
}
if(x < 125)
{
drive_rampStep((127 - x) + (y - 127), (127 - x) + (127 - y));
}
}
if(cm < 20) // if too close, then reverse
drive_speed(-15, -15);
}
}
...and in TechBasic
DIM t AS double
url$ = "192.168.178.26"
portnr = 9750
Comm.openTCPIP(1,url$,portnr, 1)
sensors.setAccelRate(0.02)
DIM quit AS Button
quit=Graphics.NewButton(10,10)
quit.setBackGroundColor(1,1,1)
quit.setGradientColor(0.7,0.7,0.7)
! Create a button
DIM wall AS Button
wall = Graphics.newButton(10, 600, 600)
wall.setTitle("This simulates the obstacle")
DIM debug AS TextField
debug=Graphics.newTextField(Graphics.width/2,10,100)
System.ShowGraphics
Sub nullevent(time AS double)
a=sensors.accel
x~ =(a(1)*128)+127
y~ =(a(2)*128)+127
REM sending accelerator info to Propeller
if System.ticks-t >0.01 then
!IF Comm.isreadyforoutput(1) then REM I've tested this with very mixed results
put #1,,x~
put #1,,y~
!end if
!if not eof(1) then REM I've tested this with very mixed results
GET #1,,b~
!end if
end if
t=System.ticks
debug.settext(str(x~) & " " & str(y~) & " " & str(b~))
wall.setFrame (10, 650 - (b~ * 2), 600, 20)
End sub
sub ShowDist
wall.setFrame (10, 650 - (b~ * 2), 600, 20)
end sub
Sub touchUpInside(ctrl AS Button,time AS double)
If ctrl=quit Then
STOP
End If
End Sub
Now I might start looking into the GUI and other areas and let others try to make the communication perfect . Need to brainstorm some ideas first about how the GUI might look like.
Edit: Inserted a line break in the code (thx Brian for finding that).
What I also forgot to mention is that the Ping sensor readings are oscillating. Might perhaps be due to the timing challenges.
What would these commands do? I thought we were talking about controlling an ActivityBot? Anyway, I could give you a framework that would allow you to receive and respond to that sort of command. So are you saying that a command sent from a tablet would be the characters "!ABOT" followed by, say, a byte count and then that number of bytes of data? Then the response would be in a similar format?
David: Agreeing with Jeff, this would be in line what we are looking for. With my current code just sending "raw data" back and forth there seems to be timing issues, lags, disconnections etc. Hopefully those would diminish with a more controlled and standardized framework.
Hi Thomas, I should shortly have the same hardware set up that you have and hopefully be able to assist. The WiFly is working fine and I don't see any reason why the Xbee won't do the same.
Thomas,
I'm trying to fallow the techBasic code , you commented of the variable wall and then used it. Am I reading that wrong ?
Brian
Edit : I broke that one line into 3 lines , now it runs
fallow? you mean like inactive/unused or perhaps you mean follow or even fathom, as in understand
(typos are a normal part of posting but sometimes they have a funny side)
David: Agreeing with Jeff, this would be in line what we are looking for. With my current code just sending "raw data" back and forth there seems to be timing issues, lags, disconnections etc. Hopefully those would diminish with a more controlled and standardized framework.
Hi Thomas,
I'm afraid I'm mired in debugging at the moment. Steve got some ActivityBot control code written using my Xbee frame driver and simple HTTP server but I decided to clean up the server code so everything is now broken. I'll let you know when it comes back to life again! :-)
I'm afraid I'm mired in debugging at the moment. Steve got some ActivityBot control code written using my Xbee frame driver and simple HTTP server but I decided to clean up the server code so everything is now broken. I'll let you know when it comes back to life again! :-)
OK, no problem. I'll move on to other parts in this concept, autonomous navigation on AB and GUI on iPad.
OK, no problem. I'll move on to other parts in this concept, autonomous navigation on AB and GUI on iPad.
Okay, I got the server sorted out. It handles Steve's ActivityBot requests okay but I still have more work to do on loading Spin binaries. The code, as always, is checked into the PropGCC project on Google Code although Steve and I have talked about creating a separate project for those who don't want to check out the entire PropGCC tree.
In any case, it is currently in propgcc/demos/xbee-loader. There is a Makefile there that has many targets but the xabs target builds Steve's ActivityBot server. It works with a web page he designed that he'll have to tell you about.
The progress looks good - really good! Nice job to everybody involved. There were questions about where to go with the iPad application. I'll attempt to define the goals here and see if they stick with any of us well enough to try to make a finished application we can share. The 5th page of this thread posed the questions, in case anybody wants to read back.
We have a need that for an iPad app that we can use in an actual educational environment with lots of WiFi activity, this April. Every couple of years, we go to http://www.usasciencefestival.org (USASEF) where we have a very large, interactive robotics display. Our 10' x 40' display area will be divided into two sections: a large ActivityBot arena and an Arlo arena. Each space will have about a dozen robots. One idea we have is to pass out iPad minis to the students to control the ActivityBots. The idea builds on a very popular application we've used at prior Expo events at Parallax: a tilt controller [accelerometers, Propeller or BASIC Stamp, XBee 802.15.4). It is possible that we hand out some iPad Minis to give the students the chance to control the robots at the USASEF. Let's face it - there's no way to teach programming with five thousand students. But we can certainly attract lots of students and their teachers (who will be interested in much more, of course).
The ActivityBots could be configured as follows:
Standard I/O setup, with two servos, encoders as shown in tutorials.
A Ping))) on the breadboard, facing forward (no rotating turret - we'll keep this simple).
Light following circuit.
Two LEDs on the breadboard.
The iPad techBASIC program would do the following:
Have buttons for three modes of operation: R/C, object avoidance (using the Ping), and Light Following. These could be radio buttons for now. All of these are basic ActivityBot programs.
In the R/C mode, the iPad's X/Y tilt would be sent to the ActivityBot as drive data, with proportional control.
In object avoidance mode, the ActivityBot roams but uses the Ping))) as a sensor, backing up and turning when an object is less than 30cm from the robot.
In light following mode, the ActivityBot follows light.
Direct connection to ActivityBot (no router, unless necessary for some reason).
Bonus ideas:
iPad displays sensor data from ActivityBot.
R/C mode is overridden when Ping))) is activated.
Anything you can think of to make it more interesting - I'm more or less providing a starting point because you asked for input.
Package it up as an executable App on the iPad store.
What do you think? Can it be accomplished from the groundwork completed so far? Is a realistic request?
= =
Other thoughts I have are to use the iPad to show the various ActivityBot sensor builds (encoders, sound playback, Ping))), light following, infrared, etc.) and to give the user a chance to test them with a graphical interface. The ActivityBot would run a super program capable of all of these sensor setups. But we don't need to go this far right now. Ultimately, we'd like to be able to download from the iPad. There are several efforts underway here relative to this big goal already, and you'll know more about them. One forum user (dgately, I think) has compiled OpenSpin on iOS. David Betz is working on an iOS downloader over WiFI (again, not certain - jazzed mentioned it) and Mike from techBASIC is interested in achieving a complete program download over WiFi. If these big efforts come together we might achieve much more than we can individually.
= =
Please let me know what Parallax can do to continue to encourage the progress.
Ken,
I am just following along at the moment. I have an iPad Mini Retina and have downloaded TechBasic and read the info.
In my limited spare time I will look at the GUI in TechBasic - no promises and please don't count on anything.
David Betz is working on an iOS downloader over WiFI (again, not certain - jazzed mentioned it)
Yes, I am working on a way to download the ActivityBot over WiFi from any web-enabled device. Basically, we have a simple web server running on the Propeller that can respond to HTTP requests from a browser. I've defined one request to initiate a code download to hub memory. This is a bit tricky because the download will overwrite the download program so the final stage of the download has to be managed entirely within a COG. This is beginning to work but there are some details to work out. This web server can also respond to other requests and Steve has been using it to control functions on the ActivityBot. This could include all of the functions you mentioned in your post as long as we don't run out of memory. Again, his control program is a web-based application that can run on an iPad but also most other devices with web browsers.
Unfortunately, none of this uses TechBasic and since that is a part of the definition of this project I'm not sure if what we're doing is suitable. Can TechBasic initiate an HTTP request?
Yes, I am working on a way to download the ActivityBot over WiFi from any web-enabled device. Basically, we have a simple web server running on the Propeller that can respond to HTTP requests from a browser. I've defined one request to initiate a code download to hub memory. This is a bit tricky because the download will overwrite the download program so the final stage of the download has to be managed entirely within a COG. This is beginning to work but there are some details to work out. This web server can also respond to other requests and Steve has been using it to control functions on the ActivityBot. This could include all of the functions you mentioned in your post as long as we don't run out of memory. Again, his control program is a web-based application that can run on an iPad but also most other devices with web browsers.
Unfortunately, none of this uses TechBasic and since that is a part of the definition of this project I'm not sure if what we're doing is suitable. Can TechBasic initiate an HTTP request?
SUB readHTTP (channel AS INTEGER, url AS STRING, request AS STRING = "GET",
body AS STRING = "", header AS STRING = "", value AS STRING = "",
username AS STRING = "", password AS STRING = "")
Opens an HTTP stream for input.
channel is the number used to open the stream; it will also be used in input commands used to read the
stream. url is the Internet address of the page to open.
HTTP requests are driven by a command; the command is passed as the request parameter. For example, the
GET command is used to read an HTTP page. Some requests, such as PUT, send data back to the web server. The
body parameter is used to send data to the server. Some requests also use a header and header body; these are
passed as the header and value parameters. The default parameters read the contents of a web page. See
references on the HTTP protocol for a complete description of the various HTTP requests. For an overview, start
with http://en.wikipedia.org/wiki/List_of_HTTP_header_fields.
When used, the username and password fields are used for basic authentication. A typical call to get a web
page from a site that requires authentication would look like this:
Comm.readHTTP(1, http://www.byteworks.us, "GET", "", "", "", "user name",
"password")
HTTP requests also return a status code. See the responseHTTP command for a way to read the status code.
For the most part, all standard commands used to read files can also be used to read HTTP streams. Here is a list
of the available commands and any changes in the way they function.
Command Notes
CLOSE Works just like file I/O.
EOF Works just like file I/O.
GET Works just like file I/O.
INPUT Works just like file I/O.
LINE INPUT Works just like file I/O.
LOC HTTP streams are not random access. This function results in a runtime error.
LOF Returns the number of bytes that have currently been received from the web site that have
not been read.
PRINT HTTP is a read-only service, so this command results in a runtime error.
PUT HTTP is a read-only service, so this command results in a runtime error.
SEEK HTTP streams are not random access. This function results in a runtime error.
While BASIC input commands are synchronous, the underlying implementation of HTTP streams is
asynchronous. Use LOF to implement asynchronous access within BASIC. LOF returns the number of available but
unread bytes for HTTP streams, so a BASIC program can check LOF to see if any bytes are available, proceeding to
do other tasks if not. EOF will return a nonzero value when the entire page has been read. Putting these facts
together, here is a general outline of code that can be placed in, say, the nullEvent subroutine to handle
information from an HTTP stream as it arrives.
IF NOT EOF(1) AND LOF(1) > 0 THEN
processHTML
END IF
The snippet shows a simple synchronous program that prints the source code for the Byte Works landing page.
Snippet
Comm.readHTTP(1, "http://www.byteworks.us")
WHILE NOT EOF(1)
LINE INPUT #1, a$
PRINT a$
WEND
PRINT "Status code: "; Comm.statusHTTP(1)
CLOSE #1
SUB readHTTP (channel AS INTEGER, url AS STRING, request AS STRING = "GET",
body AS STRING = "", header AS STRING = "", value AS STRING = "",
username AS STRING = "", password AS STRING = "")
Opens an HTTP stream for input.
channel is the number used to open the stream; it will also be used in input commands used to read the
stream. url is the Internet address of the page to open.
HTTP requests are driven by a command; the command is passed as the request parameter. For example, the
GET command is used to read an HTTP page. Some requests, such as PUT, send data back to the web server. The
body parameter is used to send data to the server. Some requests also use a header and header body; these are
passed as the header and value parameters. The default parameters read the contents of a web page. See
references on the HTTP protocol for a complete description of the various HTTP requests. For an overview, start
with http://en.wikipedia.org/wiki/List_of_HTTP_header_fields.
When used, the username and password fields are used for basic authentication. A typical call to get a web
page from a site that requires authentication would look like this:
Comm.readHTTP(1, http://www.byteworks.us, "GET", "", "", "", "user name",
"password")
HTTP requests also return a status code. See the responseHTTP command for a way to read the status code.
For the most part, all standard commands used to read files can also be used to read HTTP streams. Here is a list
of the available commands and any changes in the way they function.
Command Notes
CLOSE Works just like file I/O.
EOF Works just like file I/O.
GET Works just like file I/O.
INPUT Works just like file I/O.
LINE INPUT Works just like file I/O.
LOC HTTP streams are not random access. This function results in a runtime error.
LOF Returns the number of bytes that have currently been received from the web site that have
not been read.
PRINT HTTP is a read-only service, so this command results in a runtime error.
PUT HTTP is a read-only service, so this command results in a runtime error.
SEEK HTTP streams are not random access. This function results in a runtime error.
While BASIC input commands are synchronous, the underlying implementation of HTTP streams is
asynchronous. Use LOF to implement asynchronous access within BASIC. LOF returns the number of available but
unread bytes for HTTP streams, so a BASIC program can check LOF to see if any bytes are available, proceeding to
do other tasks if not. EOF will return a nonzero value when the entire page has been read. Putting these facts
together, here is a general outline of code that can be placed in, say, the nullEvent subroutine to handle
information from an HTTP stream as it arrives.
IF NOT EOF(1) AND LOF(1) > 0 THEN
processHTML
END IF
The snippet shows a simple synchronous program that prints the source code for the Byte Works landing page.
Snippet
Comm.readHTTP(1, "http://www.byteworks.us")
WHILE NOT EOF(1)
LINE INPUT #1, a$
PRINT a$
WEND
PRINT "Status code: "; Comm.statusHTTP(1)
CLOSE #1
Cool! It sounds like it might work then. Once we get this stuff moved to a separate repository we'll post a binary you can download to your ActivityBot and a list of HTTP requests you can use to control it.
Cool! It sounds like it might work then. Once we get this stuff moved to a separate repository we'll post a binary you can download to your ActivityBot and a list of HTTP requests you can use to control it.
I guess I should have asked this before but what sorts of things would you like to be able to ask the ActivityBot to do? Obviously Ken mentioned switching it between several different modes of operation. What else? And what requests should be supported in each of the operational modes? I'm assuming that in the RC mode navigation requests will be required. What form should they take?
I guess I should have asked this before but what sorts of things would you like to be able to ask the ActivityBot to do? Obviously Ken mentioned switching it between several different modes of operation. What else? And what requests should be supported in each of the operational modes? I'm assuming that in the RC mode navigation requests will be required. What form should they take?
Just taken from the top of my head to get the discussion rolling:
iPad to ABot:
- Toggle pin # (obviously to toggle pin #nr on/off)
- Left wheel speed (0-255, where <127 is reverse, 127 neutral, >127 forward?)
- Right wheel speed (0-255, where <127 is reverse, 127 neutral, >127 forward?)
- Direction (rotate 0-360 degrees)
- Mode 0,1,2,3 (different modes: 0 = Autonomous 'demo' mode, 1 = Semi autonomous, 2 = R/C, 3 = User defined???)
** All above could include an optional parameter for time = for how long the operation should continue, if empty then 'forever'.
ABot to iPad:
- left wheel ticks (or why not millimeters traveled?)
- right wheel ticks (or why not millimeters traveled?)
- sensor pin# (different sensor readings from pin#)
These requirements - or better call them ideas - are probably too vague and not as exact as you'd like, but hopefully give some food for thoughts.
Just taken from the top of my head to get the discussion rolling:
iPad to ABot:
- Toggle pin # (obviously to toggle pin #nr on/off)
- Left wheel speed (0-255, where <127 is reverse, 127 neutral, >127 forward?)
- Right wheel speed (0-255, where <127 is reverse, 127 neutral, >127 forward?)
- Direction (rotate 0-360 degrees)
- Mode 0,1,2,3 (different modes: 0 = Autonomous 'demo' mode, 1 = Semi autonomous, 2 = R/C, 3 = User defined???)
** All above could include an optional parameter for time = for how long the operation should continue, if empty then 'forever'.
ABot to iPad:
- left wheel ticks (or why not millimeters traveled?)
- right wheel ticks (or why not millimeters traveled?)
- sensor pin# (different sensor readings from pin#)
These requirements - or better call them ideas - are probably too vague and not as exact as you'd like, but hopefully give some food for thoughts.
You could certainly send # ticks per wheel or mm of travel - needn't be speed. I just mentioned speed because I thought it'd be a value that changes quite frequently, so it would be easier to manage with the dynamics of a moving iPad.
In regards to the "what else?" question - I'd start by giving consideration to the overall framework with this project, and perhaps make it an expandable program architecture that can be improved as customers start to come up with their own ideas. The right answer isn't here yet, but it's something that'll show up after we put this project in front of people. If you need any graphics for the iPad interface we can provide them, BTW. Jen is really skilled with this sort of thing.
The progress looks good - really good! Nice job to everybody involved. There were questions about where to go with the iPad application. I'll attempt to define the goals here and see if they stick with any of us well enough to try to make a finished application we can share. The 5th page of this thread posed the questions, in case anybody wants to read back.
....
The ActivityBots could be configured as follows:
Standard I/O setup, with two servos, encoders as shown in tutorials.
A Ping))) on the breadboard, facing forward (no rotating turret - we'll keep this simple).
Light following circuit.
Two LEDs on the breadboard.
The iPad techBASIC program would do the following:
Have buttons for three modes of operation: R/C, object avoidance (using the Ping), and Light Following. These could be radio buttons for now. All of these are basic ActivityBot programs.
In the R/C mode, the iPad's X/Y tilt would be sent to the ActivityBot as drive data, with proportional control.
In object avoidance mode, the ActivityBot roams but uses the Ping))) as a sensor, backing up and turning when an object is less than 30cm from the robot.
In light following mode, the ActivityBot follows light.
Direct connection to ActivityBot (no router, unless necessary for some reason).
Bonus ideas:
iPad displays sensor data from ActivityBot.
R/C mode is overridden when Ping))) is activated.
Anything you can think of to make it more interesting - I'm more or less providing a starting point because you asked for input.
Package it up as an executable App on the iPad store.
What do you think? Can it be accomplished from the groundwork completed so far? Is a realistic request?
= =
Other thoughts I have are to use the iPad to show the various ActivityBot sensor builds (encoders, sound playback, Ping))), light following, infrared, etc.) and to give the user a chance to test them with a graphical interface. The ActivityBot would run a super program capable of all of these sensor setups. But we don't need to go this far right now. Ultimately, we'd like to be able to download from the iPad. There are several efforts underway here relative to this big goal already, and you'll know more about them. One forum user (dgately, I think) has compiled OpenSpin on iOS. David Betz is working on an iOS downloader over WiFI (again, not certain - jazzed mentioned it) and Mike from techBASIC is interested in achieving a complete program download over WiFi. If these big efforts come together we might achieve much more than we can individually.
= =
Thanks Ken for providing an overall picture and directions. I'd say most of the above ideas are possible. Having a direct connection without a router ought to be possible, but I've not been successful. I can only configure XBee through AT commands which is cumbersome and error prone so perhaps someone with the additional USB adapter boards can step in (I believe someone else earlier mentioned about it in this thread)
Packaging it to an executable needs:
- techBasic App Builder, $49
- someone with a Mac (sorry, I don't have one)
- + whatever else might be needed to put something on App Store
- From www.byteworks.us: "Write in techBASIC, Compile on the Mac, Sell on the App Store)
While some effort and time (probably a lot of iterations and testing) is of course required to get everything smoothly integrated, the level of complexity shouldn't be that high once we get a stable communication between iPad and ActivityBot. If I'm overly optimistic I hope someone will take me down on earth again
PS To make it even more interesting, we could consider drawing the traveled path on iPad. With another Ping sensor pointing right we could also draw a "map" of the surroundings. These would most probably not make the first version though unless we start to divide up the work so not everyone is working on same things.
I can only configure XBee through AT commands which is cumbersome and error prone so perhaps someone with the additional USB adapter boards can step in (I believe someone else earlier mentioned about it in this thread)
I wrote a simple program that runs on the ActivityBoard with a Xbee WiFi module plugged in and configures it to use with my HTTP server. It could easily be modified to do whatever configuration you need. You'd just have to load it into the AB and answer some questions on a terminal connected to the AB. At the moment the only questions it asks are SSID and password although I also need to add encryption type to support WEP, WPA and WPA2. What parameters do you need to set to configure your Xbee?
These are the ones I'm using currently when connecting through a router (some commands, like ATTP (temperature) are not really necessary). For a direct connection I don't remember anymore if I've tried with other commands.
These are the ones I'm using currently when connecting through a router (some commands, like ATTP (temperature) are not really necessary). For a direct connection I don't remember anymore if I've tried with other commands.
Comments
I am waiting for XBEE wifi boards, so I will move to the ActivtyBot code next. I can either send the two raw data values, or I could pass an instruction like:
F 10 R 15
Seems to work fine ,I did notice a little glitch on the left and right tilt. once in awhile the left hand numbers go missing when you tilt left or right just a little past horizontal.
Brian
@Br1wr2el3, I posted a similar code a bit earlier and knew that I'd somehow need to adjust the code to get a comfortable 45 degrees neutral position. Now I don't need to invent the wheel for the zillionth time, so thanks!
-Thomas
Ken Gracey
Brian, congrats! If you try some of the GCC examples in this thread you should be able to control the servos through tilting your iPad. That is similar as we are doing on the ActivityBot.
-Thomas
Ken, have you thought about who are in the target group? Students, teenagers, grampies etc.?
Just asking so we know how "flashy" the GUI on iPad should be. I know we are quite free to steer it in whatever directions, but would be good to know your thoughts
-Thomas
Next is a GUI, and I do not have a clear picture of it yet.
Bruce,
My son has a construction game on his android ,he drives his construction equipment around by turning it like a steering wheel and leaning it forward and back for speed, so that is my general direction I'm headed.
I'm making sure that I have a full understanding how everything is working, because I have a feeling that Ken is still holding onto the other shoe.
Brian
The timing settings, especially on TechBasic side, are sensitive so they might need some tuning to get it to work. There's for sure some better way to do it, but I've so far not been successful with any other setup.
There's a slight delay every now and then that I don't know how to get rid of. Perhaps a direct connection would work better instead of going through the router, but I've not been able to get that to work.
The only possibility for me to config the XBee is through AT codes as I don't have any USB adapter boards, and it is quite cumbersome and error prone...
This is the relevant part of the GCC code
int x, y; int i=0; int cm; int tx_result, receiving; short int ping_now = 0; drive_setRampStep(12); // 7 ticks/sec / 20 ms while(1) { cm = ping_cm(8); x = fdserial_rxChar(xbee); // receiving x (speed) from iPad y = fdserial_rxChar(xbee); // receiving y (direction) from iPad tx_result = fdserial_txChar(xbee, cm); // sends the distance to iPad if(x != -1) { if(y != -1) if(x > 124 && x < 130) // "dead zone" to avoid jittering speed drive_speed(0, 0); if(x > 129) { drive_rampStep((0 - (x - 127) - (y - 127)), (0 - (x - 127)) - (127 - y)); } if(x < 125) { drive_rampStep((127 - x) + (y - 127), (127 - x) + (127 - y)); } } if(cm < 20) // if too close, then reverse drive_speed(-15, -15); } }...and in TechBasicDIM t AS double url$ = "192.168.178.26" portnr = 9750 Comm.openTCPIP(1,url$,portnr, 1) sensors.setAccelRate(0.02) DIM quit AS Button quit=Graphics.NewButton(10,10) quit.setBackGroundColor(1,1,1) quit.setGradientColor(0.7,0.7,0.7) ! Create a button DIM wall AS Button wall = Graphics.newButton(10, 600, 600) wall.setTitle("This simulates the obstacle") DIM debug AS TextField debug=Graphics.newTextField(Graphics.width/2,10,100) System.ShowGraphics Sub nullevent(time AS double) a=sensors.accel x~ =(a(1)*128)+127 y~ =(a(2)*128)+127 REM sending accelerator info to Propeller if System.ticks-t >0.01 then !IF Comm.isreadyforoutput(1) then REM I've tested this with very mixed results put #1,,x~ put #1,,y~ !end if !if not eof(1) then REM I've tested this with very mixed results GET #1,,b~ !end if end if t=System.ticks debug.settext(str(x~) & " " & str(y~) & " " & str(b~)) wall.setFrame (10, 650 - (b~ * 2), 600, 20) End sub sub ShowDist wall.setFrame (10, 650 - (b~ * 2), 600, 20) end sub Sub touchUpInside(ctrl AS Button,time AS double) If ctrl=quit Then STOP End If End SubNow I might start looking into the GUI and other areas and let others try to make the communication perfectEdit: Inserted a line break in the code (thx Brian for finding that).
What I also forgot to mention is that the Ping sensor readings are oscillating. Might perhaps be due to the timing challenges.
I'm trying to fallow the techBasic code , you commented of the variable wall and then used it. Am I reading that wrong ?
Brian
Edit : I broke that one line into 3 lines , now it runs
Sorry for that, my bad. I cleaned a lot of unused code while posting and was too successful in cleaning...
Jeff T.
(typos are a normal part of posting but sometimes they have a funny side)
I'm afraid I'm mired in debugging at the moment. Steve got some ActivityBot control code written using my Xbee frame driver and simple HTTP server but I decided to clean up the server code so everything is now broken. I'll let you know when it comes back to life again! :-)
OK, no problem. I'll move on to other parts in this concept, autonomous navigation on AB and GUI on iPad.
In any case, it is currently in propgcc/demos/xbee-loader. There is a Makefile there that has many targets but the xabs target builds Steve's ActivityBot server. It works with a web page he designed that he'll have to tell you about.
The progress looks good - really good! Nice job to everybody involved. There were questions about where to go with the iPad application. I'll attempt to define the goals here and see if they stick with any of us well enough to try to make a finished application we can share. The 5th page of this thread posed the questions, in case anybody wants to read back.
We have a need that for an iPad app that we can use in an actual educational environment with lots of WiFi activity, this April. Every couple of years, we go to http://www.usasciencefestival.org (USASEF) where we have a very large, interactive robotics display. Our 10' x 40' display area will be divided into two sections: a large ActivityBot arena and an Arlo arena. Each space will have about a dozen robots. One idea we have is to pass out iPad minis to the students to control the ActivityBots. The idea builds on a very popular application we've used at prior Expo events at Parallax: a tilt controller [accelerometers, Propeller or BASIC Stamp, XBee 802.15.4). It is possible that we hand out some iPad Minis to give the students the chance to control the robots at the USASEF. Let's face it - there's no way to teach programming with five thousand students. But we can certainly attract lots of students and their teachers (who will be interested in much more, of course).
The ActivityBots could be configured as follows:
- Standard I/O setup, with two servos, encoders as shown in tutorials.
- A Ping))) on the breadboard, facing forward (no rotating turret - we'll keep this simple).
- Light following circuit.
- Two LEDs on the breadboard.
The iPad techBASIC program would do the following:- Have buttons for three modes of operation: R/C, object avoidance (using the Ping), and Light Following. These could be radio buttons for now. All of these are basic ActivityBot programs.
- In the R/C mode, the iPad's X/Y tilt would be sent to the ActivityBot as drive data, with proportional control.
- In object avoidance mode, the ActivityBot roams but uses the Ping))) as a sensor, backing up and turning when an object is less than 30cm from the robot.
- In light following mode, the ActivityBot follows light.
- Direct connection to ActivityBot (no router, unless necessary for some reason).
Bonus ideas:- iPad displays sensor data from ActivityBot.
- R/C mode is overridden when Ping))) is activated.
- Anything you can think of to make it more interesting - I'm more or less providing a starting point because you asked for input.
- Package it up as an executable App on the iPad store.
What do you think? Can it be accomplished from the groundwork completed so far? Is a realistic request?= =
Other thoughts I have are to use the iPad to show the various ActivityBot sensor builds (encoders, sound playback, Ping))), light following, infrared, etc.) and to give the user a chance to test them with a graphical interface. The ActivityBot would run a super program capable of all of these sensor setups. But we don't need to go this far right now. Ultimately, we'd like to be able to download from the iPad. There are several efforts underway here relative to this big goal already, and you'll know more about them. One forum user (dgately, I think) has compiled OpenSpin on iOS. David Betz is working on an iOS downloader over WiFI (again, not certain - jazzed mentioned it) and Mike from techBASIC is interested in achieving a complete program download over WiFi. If these big efforts come together we might achieve much more than we can individually.
= =
Please let me know what Parallax can do to continue to encourage the progress.
Sincerely,
Ken Gracey
I am just following along at the moment. I have an iPad Mini Retina and have downloaded TechBasic and read the info.
In my limited spare time I will look at the GUI in TechBasic - no promises and please don't count on anything.
Unfortunately, none of this uses TechBasic and since that is a part of the definition of this project I'm not sure if what we're doing is suitable. Can TechBasic initiate an HTTP request?
iPad to ABot:
- Toggle pin # (obviously to toggle pin #nr on/off)
- Left wheel speed (0-255, where <127 is reverse, 127 neutral, >127 forward?)
- Right wheel speed (0-255, where <127 is reverse, 127 neutral, >127 forward?)
- Direction (rotate 0-360 degrees)
- Mode 0,1,2,3 (different modes: 0 = Autonomous 'demo' mode, 1 = Semi autonomous, 2 = R/C, 3 = User defined???)
** All above could include an optional parameter for time = for how long the operation should continue, if empty then 'forever'.
ABot to iPad:
- left wheel ticks (or why not millimeters traveled?)
- right wheel ticks (or why not millimeters traveled?)
- sensor pin# (different sensor readings from pin#)
These requirements - or better call them ideas - are probably too vague and not as exact as you'd like, but hopefully give some food for thoughts.
You could certainly send # ticks per wheel or mm of travel - needn't be speed. I just mentioned speed because I thought it'd be a value that changes quite frequently, so it would be easier to manage with the dynamics of a moving iPad.
In regards to the "what else?" question - I'd start by giving consideration to the overall framework with this project, and perhaps make it an expandable program architecture that can be improved as customers start to come up with their own ideas. The right answer isn't here yet, but it's something that'll show up after we put this project in front of people. If you need any graphics for the iPad interface we can provide them, BTW. Jen is really skilled with this sort of thing.
Ken Gracey
Packaging it to an executable needs:
- techBasic App Builder, $49
- someone with a Mac (sorry, I don't have one)
- + whatever else might be needed to put something on App Store
- From www.byteworks.us: "Write in techBASIC, Compile on the Mac, Sell on the App Store)
While some effort and time (probably a lot of iterations and testing) is of course required to get everything smoothly integrated, the level of complexity shouldn't be that high once we get a stable communication between iPad and ActivityBot. If I'm overly optimistic I hope someone will take me down on earth again
PS To make it even more interesting, we could consider drawing the traveled path on iPad. With another Ping sensor pointing right we could also draw a "map" of the surroundings. These would most probably not make the first version though unless we start to divide up the work so not everyone is working on same things.
Would you want those settings written using ATWR? Otherwise, they'll go away when you power cycle the board and maybe even when you reset it.