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.
Well, I suppose I'd mostly want to store the settings, but would be a bonus if it would be optional.
Once in a while when trying some other scenario it has been a PITA to restore it to factory defaults through ATRE. I'm always initializing the XBee in the C code so it is easier to try some other scenario without going through the factory default resetting.
Well, I suppose I'd mostly want to store the settings, but would be a bonus if it would be optional.
Once in a while when trying some other scenario it has been a PITA to restore it to factory defaults through ATRE. I'm always initializing the XBee in the C code so it is easier to try some other scenario without going through the factory default resetting.
Sorry, I guess I'm confused. You say you've been initializing your Xbee module in C code but that's all I'm offering too. Do you actually need my Xbee configuration code? It is also C code that sends AT commands to the Xbee module.
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.
Thanks Thomas for your comment on this point, and I agree. Direct download from iOS to the device isn't a requirement (or a request) from my point of view. I change my mind on this point, and consider it a "bonus" kind of feature. Jeff Martin pointed out to me this morning "well, Ken, if you have a WiFi connection from the iPad directly to the Propeller then you have no internet access" so I happily rescind the request for direct iOS to Propeller programming.
Thanks Thomas for your comment on this point, and I agree. Direct download from iOS to the device isn't a requirement (or a request) from my point of view. I change my mind on this point, and consider it a "bonus" kind of feature. Jeff Martin pointed out to me this morning "well, Ken, if you have a WiFi connection from the iPad directly to the Propeller then you have no internet access" so I happily rescind the request for direct iOS to Propeller programming.
Ken Gracey
You can still program the Propeller over the WiFi link even if you connect to it through a router and then you maintain your internet connection as well. That's what I'm doing.
Sorry, I guess I'm confused. You say you've been initializing your Xbee module in C code but that's all I'm offering too. Do you actually need my Xbee configuration code? It is also C code that sends AT commands to the Xbee module.
Sorry, I responded to your questions without really thinking what I'm looking after in the end...
The thing is that I've been living in a graphical world for ~20 years (starting from Win 2.1-Win 7, OS/2, iGadgets etc.), and now coming back to the command prompt world (which was OK in the 80's) makes me loose the overview of the settings I already have in the XBee and what else I might want to tune if I have issues.
So unless you happen to have a framework ready for pulling out all configuration from the XBee and present it in a tabular format with short descriptions, I suppose your code might not help me that far. Instead of putting a lot of effort into this type of framework, it is obviously easier that I purchase the needed USB-adapter from my favourite vendor. This provided that the adapter is bundled with some kind of UI instead of still another command prompt.
Sorry, I responded to your questions without really thinking what I'm looking after in the end...
The thing is that I've been living in a graphical world for ~20 years (starting from Win 2.1-Win 7, OS/2, iGadgets etc.), and now coming back to the command prompt world (which was OK in the 80's) makes me loose the overview of the settings I already have in the XBee and what else I might want to tune if I have issues.
So unless you happen to have a framework ready for pulling out all configuration from the XBee and present it in a tabular format with short descriptions, I suppose your code might not help me that far. Instead of putting a lot of effort into this type of framework, it is obviously easier that I purchase the needed USB-adapter from my favourite vendor. This provided that the adapter is bundled with some kind of UI instead of still another command prompt.
Parallax has that USB adapter and I think it's pretty inexpensive. You're right that the Digi utility is probably the easiest tool for adjusting the settings.
FYI,
I'm running straight from ipad to xbee , no router. Seems to be working ok, although I am only using simple commands right now.
Brian
I've done that too from a MacBook Pro but I didn't like the fact that I had to disconnect from the Internet to connect to the ActivityBot. I don't know of a way to get the Mac or an iPad to maintain two WiFi connections at the same time.
@Dave
There is only one WiFi on an iPad and you switch back and forth. Makes sense and I agree with you on this.
Direct connection does mean your iPad is only a controller for Activity Bot until you disconnect it and put it
back on the real internet connection
@ Ken
On the issue of not doing a direct connection and only through a router what router?
When in your own house it is an easy choice and your WiFi router becomes your Sensor and Control
router and is a good way to go. I wonder about real time control speed and delays but that is an issue to
be tested but it is a slick way to go.
On the other hand away from home at a show where you have a booth are you going to be able to get all
the security setup info for the building router in order to connect to it. Or are hot spots at these places wide
open and you just need to know it is there and what ip address it is at.
@Banjo
The Parallax USB Adapter works very well with Digi XCTU software. You need the latest version of XCTU. Of which there are two
One in the old style and a new re-written GUI version. I have both and they work with the SB6 XBEE.
I did get some XBEE's late yesterday to play with and have been trying things out. At first I got no where in the connection
world. The reason for most of my issues was that I forgot I had set security on my router to only allow certain MAC addresses
to connect. This has bit me before and I mention it in case someone else forgets to add the MAC address of the XBEE to
the router's only allow these devices to connect.
I never did get Digi XCTU to find it by Scanning even after adding the MAC address to the router. It found my neighbors but
not me. So I just entered all the info manually into XCTU and I was able to connect with Tech Basic running Banjo's send a string
code and watching it on the XCTU terminal, It worked fine. No Activity bot just iPad to Parallax USB Adapter with XBEE and
to XCTU.
Great for what seems like 10,000 trys at what one thinks it wants to see as one learns.
XCTU works but I do have to reload it once in a while and unplug the XBEE to reboot it pwr it down. Then again some of
those reboots may not have been needed as it was me thinking it would fix something .
I then switched to trying to get a direct connection to work and that has not worked yet.
@Brian_B curious what you did and attached some XCTU screen captures of how I set up direct connect, again
not working yet . Did you do the same and if not what is different. By the way I just pulled the direct connect ip address
out of the air, made one up close the the WiFly one to stay away from anything close to my home router ones.
Provide both direct and via-AccessPoint connection, if possible. This gives the user something that works when away from an AP, but provides full internet access when they are within an AP's domain.
Users will be running their robots for demonstrations away from APs, right? At the same time, it's good to have access to the internet while you are developing your project.
Since this is a tool for the education world, remember that students may not have access to school networks. You do not want to bind them to a connection method that they cannot use, right?
@tom
This might sound a little odd .Use your xbee to usb adapter to configure the xbee ,don't try and use it to see if the xbee is working. For some reason it does not work all the time
I have one xbee running direct and one running though my router and both only work part time on the usb adapter but work perfect in the Propboe board.
Brian
Thank's for the info.
I see you have DHCP set, I will try that tomorrow. When I did that in connecting with home router I
had to do an ATMY after connecting to get the actual ip address, which was different than on the XCTU
screen but became same after I refreshed the XCTU values by doing a read of the radio .
My thoughts on the fixed ip were to stay away from the 192.168 range as that is the same range the router
which we want to ignore us is putting out by it's DHCP to things connected to it.
Yes I intend to add the Activity Board in tomorrow with some C code to respond to some button pushes on
iPad and send some values back. I stuck with the XCTU terminal today so as to not at the complexity of
which side is not working until I connected a few times in a row .
@tom
This might sound a little odd .Use your xbee to usb adapter to configure the xbee ,don't try and use it to see if the xbee is working. For some reason it does not work all the time
I have one xbee running direct and one running though my router and both only work part time on the usb adapter but work perfect in the Propboe board.
@Brian, for the direct connection, would you mind sharing your settings on iPad, in TechBasic and on XBee. I'd like to get it to work as well to exclude router introduced delays or issues when troubleshooting.
Thanks Brian, the screenshots with settings is exactly what I need, will try them as soon as I can make time.
With the comment about Xbee dropping off on low power, is only the Xbee dropping off, or also the Propeller board?
FYI When developing and for quick testing I use USB power and when testing more I'm running with 5 Ni-Mh new batteries. Charging them every second day.
I'm pretty sure it's the xbee (it's power hungry) , If I command the servo's to move on a low battery they will start and keep turning ,but my iPad loses the xbee and defaults back to my home network. I don't know how many times that I was fighting with code only to find out the iPad switched Wi-Fi on me.
That's one good thing about running through a router, you don't have to keep checking if it's still connected.
I wonder how many times you can switch the iPad WiFi connection back and forth before you brick your iPad. I must have done it
10 times in a couple of hours debugging the direct connection.
Would seem like it would be designed to be switched a lot but that might mean 4 or 5 times a day max.
FWIW my iPad has cellular connection so I can maintain WiFi as well as internet connection concurrently. However, I would not expect the schoolies to have those iPad versions.
You could take a cheap router to the show(s) and as long as you can setup a hotspot using your phone (or tablet, etc) you should be fine (delays excepted). There is a cheap ~$20 wifi router on eBay WR703N that is quite useful and is often hacked.
Banjo, myself and techBASIC's Mike have had a bit of offline discussion in the last couple of days about some of the issues we're experiencing. Appears that some new issues may have been introduced with iOS 7 that create memory leaks. Mike is taking a look at our code, his code and we also think that Apple will make any fixes in due course, too, as we'd be far from alone since there are many projects around the iPad.
How to collaborate on next steps - a simple ActivityBot Tilt-Pad GUI introduced in Page 6, post 109?
You'll all need to let me know if I'm asking too much, okay? Banjo asked "what's the best way for us to collaborate on the project" so that several of us could attach different pieces of it. From what I've read, I view this as having two pieces, and a third that explains the setup.
1- ActivityBot and associated C code, which is really quite simple.
2- iPad ActivityBot control system.
3- Instructions on how to set it up.
And perhaps the biggest piece is actually #2, setting up a graphical control system on the iPad. Brian already showed a graphic, so we seem to have a start. Could this piece be done in stages, so that the first step is to access the iPad's X/Y accelerometer values, and send them to ActivityBot while showing them on the iPad, translated to 0-100 values for both motors? Then, we could add buttons for the different modes: light following or ultrasonic.
Seems that we'd need a communication protocol, too.
We don't need fancy graphics now - just a proof of concept that can be grown and improved.
Who is having the most success with the techBASIC side? Banjo? If so, Brian or David may want to attack the ActivityBot side of this. For the ActivityBot, I'd first get the basic sensors installed, and tested, then merge a couple of our C code examples in a loop that can listen for XBee WiFi serial. Not sure if this will need to get COG'd or not.
1- ActivityBot and associated C code, which is really quite simple.
...
If so, Brian or David may want to attack the ActivityBot side of this. For the ActivityBot, I'd first get the basic sensors installed, and tested, then merge a couple of our C code examples in a loop that can listen for XBee WiFi serial. Not sure if this will need to get COG'd or not.
What I have is an HTTP server that runs on the Propeller and communicates through the Xbee Wi-Fi module. I'm not sure if HTTP is going to be responsive enough to use as a realtime control for the robot so maybe Brian's approach would be more appropriate for this. My code was developed with the idea of using the Xbee to load code into the Propeller. However, Steve (jazzed) may have more to say about this since he's used my HTTP server framework to build a robot control system using a web-based IDE. This may actually have an advantage over the TechBasic UI that you have been experimenting with since it is not tied to the iPad.
David, is this the same code base you've been developing that's being used for program download to Propeller? If it can download code - something that seems to includes lots of bytes and be very timing critical - how could it not also work as a near-real time control interface for iPad to ActivityBot?
David, is this the same code base you've been developing that's being used for program download to Propeller? If it can download code - something that seems to includes lots of bytes and be very timing critical - how could it not also work as a near-real time control interface for iPad to ActivityBot?
Thanks,
Ken Gracey
Yes it's the same code I'm using for program download but I can't download the Propeller using the ROM loader when the Xbee server is already running on the same Propeller. Instead, I have a COG receiving data from the Xbee module and writing it directly to hub memory. After the load is complete, that COG uses Mike Green's scheme from FemtoBasic to start the Spin interpreter in ROM to run the code already in hub memory. The ROM loader isn't used so there are no timing constraints.
And perhaps the biggest piece is actually #2, setting up a graphical control system on the iPad. Brian already showed a graphic, so we seem to have a start. Could this piece be done in stages, so that the first step is to access the iPad's X/Y accelerometer values, and send them to ActivityBot while showing them on the iPad, translated to 0-100 values for both motors? Then, we could add buttons for the different modes: light following or ultrasonic
The above is already done on the iPad end. It seems to me the biggest issue at the moment is for everyone to get in line with their wifi setup so that we can share source and expect the same results. Im assuming that is where some of the disconnects and slow program response comes from. I am not experiencing the disconnects but holding off on commiting to that until I have tried the Xbee.
Memory leaks sounds scary, is there any way of telling if that is a problem or not.
For lack of anything better I have been using the protocol I mentioned in an earlier thread and that is working out nicely.
I would like to share ideas with Thomas on the techBasic side of things and look forward to seeing what Mike of Byte Works has to say.
Here is Bruce's code sending back to xbee ,his is a lot nicer to work with. I had some spin code running on my activity bot , and while I can't say I had total control of it ,I could get it to end up where I wanted it to go.
Also activity Bot code for watching sensor info.
****** Memory leak shows it's face after about 1/2 hour ,screen quits updating. Still sending data to activity Bot though.
Brian
#include "simpletools.h"
#include "fdserial.h"
#include "abdrive.h"
int main(void)
{
extern text_t *dport_ptr; // default debug port pointer gets reassigned to fdserial.
char ch;
fdserial *xbee = fdserial_open(11,10,0,9600); // P13 connected to DO, P12 connected to DI
simpleterm_close();
dport_ptr = (fdserial_open(31,30,0,115200));
What I have is an HTTP server that runs on the Propeller and communicates through the Xbee Wi-Fi module. I'm not sure if HTTP is going to be responsive enough to use as a realtime control for the robot so maybe Brian's approach would be more appropriate for this. My code was developed with the idea of using the Xbee to load code into the Propeller. However, Steve (jazzed) may have more to say about this since he's used my HTTP server framework to build a robot control system using a web-based IDE. This may actually have an advantage over the TechBasic UI that you have been experimenting with since it is not tied to the iPad.
Yesterday Jeff, Andy, Stephanie, Jessica and I met at Parallax. The main topic was SimpleIDE priorities, but we also had a chance to have fun with wireless.
I spent a few days working on a web-app (ABS Wifi Demo) for controlling the Wifi enabled ActivityBot last week. We played with that before lunch. I passed around my iPad and had the page on my computer at the same time. We drove the bot around a little, clicked on/off the LEDs, checked the battery voltage with the ADC, did some tiny solar-cell experiments. Video of the web app is here: http://youtu.be/AmsbMqEXHNI
The ABS Wifi Demo web-app servo control system was a little bit sluggish. Part of the problem was my being very conservative about ramping the servo speed so the bot wouldn't reset. There were some clear network infrastructure induced delays though. We were able to control the bot from more than one client at a time most of the time. In one case that was helpful because I could hit the stop button from keeping the bot from lurching off the edge of the conference table. The web-app is here: https://propgcc.googlecode.com/hg/demos/xbee-abs/html/index.html The IP Address would be IP address of your ActivityBot at home - this requires some configuration of the XBee S6B Wifi module and a propeller server program running before it will work. Besides configuration, all you need is to point the Chrome/Safari (PC, Android, iPAD, iPhone) browser to the web page link mentioned.
The best non-accelerometer ActivityBot user interface in my opinion comes from Dennis Gately. He turned his iPhone into an RC car-like controller. His concept uses BluetoothLE for controlling the BOT. I visited Dennis Thursday and we swapped some hardware. BLE is definitely an option for control from an iPhone or Android app. Dennis posted a communication app demo video here: http://vimeo.com/84914492
In addition to web and iphone apps for controlling the ActivityBot, we have spent time on IDEs. I demo'd the PC based SpinaWeb (Spinny Weby Devy) browser app at Parallax which requires a server running on the local PC to work for the moment http://www.youtube.com/watch?v=ko3HLUlxo-Q . It worked probably a little too good because it was a very short demo. In the near future I hope to have a version that uses Heater's Javascript version of the OpenSpin compiler. Here is a better video of the SpinaWeb app: http://youtu.be/Ew009kdbmxU
What I didn't get a chance to show was Dennis' iPhone BluetoothLE SpinTab demo which I missed because it was in my less frequently used Yahoo mail. Here's a video demo Dennis made of SpinTab: http://vimeo.com/84916113
I'm attaching some pics of the different pages mentioned above.
Steve that all looks awesome. What kind of price have you been looking at for Bluetooth LE modules?
@ Ken,Thomas,Brian,Bruce and Tom , guys will you try this code out and give me some feedback, the sample runs with or without wifi. If you want to try the wifi scroll down to the Comm command and make sure your ip and port are entered.
The zip file attached contains three images that will need copying to your iPad. I am not concerned what the images look like but they are there to serve the example. Also in the zip file is the full techBasic source and a simple spin file for testing the wifi. Again if you dont want to try the wifi just use the techBasic source and the images.
Almost everything is separated into sub routines and the idea is that these sub routines can be modified or discarded depending on what your thoughts are.
The example demonstrates 6 bytes transmitted and 6 bytes echoed back.
Byte 0 uses its bits as digital switches that contain the status of the segmented control (R/C,Ping,Light and Halt) and the status of LED 1 and LED 2, bits 0-3 for the segmented control and bits 4 and 5 for the LEDs.
Bytes 1 and 2 are x and y accelerometer data.
The LEDs have a touch area, tapping the graphic will change its "brightness" and change the value of data byte 0.
I have it running on the iPad .Did you crank up the serial comm speed from the xbee to prop ?( spin code shows 115200) I have yet gotten it to connect to prop, I'm checking my end for problems.
Comments
Once in a while when trying some other scenario it has been a PITA to restore it to factory defaults through ATRE. I'm always initializing the XBee in the C code so it is easier to try some other scenario without going through the factory default resetting.
Thanks Thomas for your comment on this point, and I agree. Direct download from iOS to the device isn't a requirement (or a request) from my point of view. I change my mind on this point, and consider it a "bonus" kind of feature. Jeff Martin pointed out to me this morning "well, Ken, if you have a WiFi connection from the iPad directly to the Propeller then you have no internet access" so I happily rescind the request for direct iOS to Propeller programming.
Ken Gracey
The thing is that I've been living in a graphical world for ~20 years (starting from Win 2.1-Win 7, OS/2, iGadgets etc.), and now coming back to the command prompt world (which was OK in the 80's) makes me loose the overview of the settings I already have in the XBee and what else I might want to tune if I have issues.
So unless you happen to have a framework ready for pulling out all configuration from the XBee and present it in a tabular format with short descriptions, I suppose your code might not help me that far. Instead of putting a lot of effort into this type of framework, it is obviously easier that I purchase the needed USB-adapter from my favourite vendor. This provided that the adapter is bundled with some kind of UI instead of still another command prompt.
I'm running straight from ipad to xbee , no router. Seems to be working ok, although I am only using simple commands right now.
Brian
There is only one WiFi on an iPad and you switch back and forth. Makes sense and I agree with you on this.
Direct connection does mean your iPad is only a controller for Activity Bot until you disconnect it and put it
back on the real internet connection
@ Ken
On the issue of not doing a direct connection and only through a router what router?
When in your own house it is an easy choice and your WiFi router becomes your Sensor and Control
router and is a good way to go. I wonder about real time control speed and delays but that is an issue to
be tested but it is a slick way to go.
On the other hand away from home at a show where you have a booth are you going to be able to get all
the security setup info for the building router in order to connect to it. Or are hot spots at these places wide
open and you just need to know it is there and what ip address it is at.
@Banjo
The Parallax USB Adapter works very well with Digi XCTU software. You need the latest version of XCTU. Of which there are two
One in the old style and a new re-written GUI version. I have both and they work with the SB6 XBEE.
I did get some XBEE's late yesterday to play with and have been trying things out. At first I got no where in the connection
world. The reason for most of my issues was that I forgot I had set security on my router to only allow certain MAC addresses
to connect. This has bit me before and I mention it in case someone else forgets to add the MAC address of the XBEE to
the router's only allow these devices to connect.
I never did get Digi XCTU to find it by Scanning even after adding the MAC address to the router. It found my neighbors but
not me. So I just entered all the info manually into XCTU and I was able to connect with Tech Basic running Banjo's send a string
code and watching it on the XCTU terminal, It worked fine. No Activity bot just iPad to Parallax USB Adapter with XBEE and
to XCTU.
Great for what seems like 10,000 trys at what one thinks it wants to see as one learns.
XCTU works but I do have to reload it once in a while and unplug the XBEE to reboot it pwr it down. Then again some of
those reboots may not have been needed as it was me thinking it would fix something .
I then switched to trying to get a direct connection to work and that has not worked yet.
@Brian_B curious what you did and attached some XCTU screen captures of how I set up direct connect, again
not working yet . Did you do the same and if not what is different. By the way I just pulled the direct connect ip address
out of the air, made one up close the the WiFly one to stay away from anything close to my home router ones.
Tom
Users will be running their robots for demonstrations away from APs, right? At the same time, it's good to have access to the internet while you are developing your project.
Since this is a tool for the education world, remember that students may not have access to school networks. You do not want to bind them to a connection method that they cannot use, right?
dgately
This might sound a little odd .Use your xbee to usb adapter to configure the xbee ,don't try and use it to see if the xbee is working. For some reason it does not work all the time
I have one xbee running direct and one running though my router and both only work part time on the usb adapter but work perfect in the Propboe board.
Brian
Thank's for the info.
I see you have DHCP set, I will try that tomorrow. When I did that in connecting with home router I
had to do an ATMY after connecting to get the actual ip address, which was different than on the XCTU
screen but became same after I refreshed the XCTU values by doing a read of the radio .
My thoughts on the fixed ip were to stay away from the 192.168 range as that is the same range the router
which we want to ignore us is putting out by it's DHCP to things connected to it.
Yes I intend to add the Activity Board in tomorrow with some C code to respond to some button pushes on
iPad and send some values back. I stuck with the XCTU terminal today so as to not at the complexity of
which side is not working until I connected a few times in a row .
Nice iPad screen in your last post.
Tom
Xbee settings for direct connection are in post #133 ,most of them where default. I think I only changed to soft ap and no password.
Here is my techBasic and prop code, sorry about the spin I'm testing a c version right now. These programs are simple, but I'm just testing.
Brian
ps: make sure you have a good power supply or battery pack , xbee will drop off with low power.
With the comment about Xbee dropping off on low power, is only the Xbee dropping off, or also the Propeller board?
FYI When developing and for quick testing I use USB power and when testing more I'm running with 5 Ni-Mh new batteries. Charging them every second day.
@banjo ,Thanks'
I'm pretty sure it's the xbee (it's power hungry) , If I command the servo's to move on a low battery they will start and keep turning ,but my iPad loses the xbee and defaults back to my home network. I don't know how many times that I was fighting with code only to find out the iPad switched Wi-Fi on me.
That's one good thing about running through a router, you don't have to keep checking if it's still connected.
Brian
10 times in a couple of hours debugging the direct connection.
Would seem like it would be designed to be switched a lot but that might mean 4 or 5 times a day max.
Tom
You could take a cheap router to the show(s) and as long as you can setup a hotspot using your phone (or tablet, etc) you should be fine (delays excepted). There is a cheap ~$20 wifi router on eBay WR703N that is quite useful and is often hacked.
Banjo, myself and techBASIC's Mike have had a bit of offline discussion in the last couple of days about some of the issues we're experiencing. Appears that some new issues may have been introduced with iOS 7 that create memory leaks. Mike is taking a look at our code, his code and we also think that Apple will make any fixes in due course, too, as we'd be far from alone since there are many projects around the iPad.
How to collaborate on next steps - a simple ActivityBot Tilt-Pad GUI introduced in Page 6, post 109?
You'll all need to let me know if I'm asking too much, okay? Banjo asked "what's the best way for us to collaborate on the project" so that several of us could attach different pieces of it. From what I've read, I view this as having two pieces, and a third that explains the setup.
1- ActivityBot and associated C code, which is really quite simple.
2- iPad ActivityBot control system.
3- Instructions on how to set it up.
And perhaps the biggest piece is actually #2, setting up a graphical control system on the iPad. Brian already showed a graphic, so we seem to have a start. Could this piece be done in stages, so that the first step is to access the iPad's X/Y accelerometer values, and send them to ActivityBot while showing them on the iPad, translated to 0-100 values for both motors? Then, we could add buttons for the different modes: light following or ultrasonic.
Seems that we'd need a communication protocol, too.
We don't need fancy graphics now - just a proof of concept that can be grown and improved.
Who is having the most success with the techBASIC side? Banjo? If so, Brian or David may want to attack the ActivityBot side of this. For the ActivityBot, I'd first get the basic sensors installed, and tested, then merge a couple of our C code examples in a loop that can listen for XBee WiFi serial. Not sure if this will need to get COG'd or not.
Thoughts?
Ken Gracey
What I have is an HTTP server that runs on the Propeller and communicates through the Xbee Wi-Fi module. I'm not sure if HTTP is going to be responsive enough to use as a realtime control for the robot so maybe Brian's approach would be more appropriate for this. My code was developed with the idea of using the Xbee to load code into the Propeller. However, Steve (jazzed) may have more to say about this since he's used my HTTP server framework to build a robot control system using a web-based IDE. This may actually have an advantage over the TechBasic UI that you have been experimenting with since it is not tied to the iPad.
Thanks,
Ken Gracey
The above is already done on the iPad end. It seems to me the biggest issue at the moment is for everyone to get in line with their wifi setup so that we can share source and expect the same results. Im assuming that is where some of the disconnects and slow program response comes from. I am not experiencing the disconnects but holding off on commiting to that until I have tried the Xbee.
Memory leaks sounds scary, is there any way of telling if that is a problem or not.
For lack of anything better I have been using the protocol I mentioned in an earlier thread and that is working out nicely.
I would like to share ideas with Thomas on the techBasic side of things and look forward to seeing what Mike of Byte Works has to say.
Jeff T.
Comm.openTCPIP(1, "192.168.1.10",9750)
system.setallowedorientations(8)
while(1)
a=sensors.accel
print a(1),a(2),a(3)
print #1, "X"
print #1 ,a(1)
print #1 , "Y"
print #1 ,a(2)
print #1 , "Z"
print #1 ,a(3)
system.wait(0.2)
system.clearconsole
wend
Also activity Bot code for watching sensor info.
****** Memory leak shows it's face after about 1/2 hour ,screen quits updating. Still sending data to activity Bot though.
Brian
#include "simpletools.h"
#include "fdserial.h"
#include "abdrive.h"
int main(void)
{
extern text_t *dport_ptr; // default debug port pointer gets reassigned to fdserial.
char ch;
fdserial *xbee = fdserial_open(11,10,0,9600); // P13 connected to DO, P12 connected to DI
simpleterm_close();
dport_ptr = (fdserial_open(31,30,0,115200));
putLine("Starting terminal");
while(1) {
if(fdserial_rxReady(xbee)) {
ch = readChar(xbee);
writeChar(xbee,ch);
putChar(ch);
}
if(fdserial_rxReady(dport_ptr)) {
ch = getChar();
putChar(ch);
writeChar(xbee, ch);
}
}
return 0;
I spent a few days working on a web-app (ABS Wifi Demo) for controlling the Wifi enabled ActivityBot last week. We played with that before lunch. I passed around my iPad and had the page on my computer at the same time. We drove the bot around a little, clicked on/off the LEDs, checked the battery voltage with the ADC, did some tiny solar-cell experiments. Video of the web app is here: http://youtu.be/AmsbMqEXHNI
The ABS Wifi Demo web-app servo control system was a little bit sluggish. Part of the problem was my being very conservative about ramping the servo speed so the bot wouldn't reset. There were some clear network infrastructure induced delays though. We were able to control the bot from more than one client at a time most of the time. In one case that was helpful because I could hit the stop button from keeping the bot from lurching off the edge of the conference table. The web-app is here: https://propgcc.googlecode.com/hg/demos/xbee-abs/html/index.html The IP Address would be IP address of your ActivityBot at home - this requires some configuration of the XBee S6B Wifi module and a propeller server program running before it will work. Besides configuration, all you need is to point the Chrome/Safari (PC, Android, iPAD, iPhone) browser to the web page link mentioned.
The best non-accelerometer ActivityBot user interface in my opinion comes from Dennis Gately. He turned his iPhone into an RC car-like controller. His concept uses BluetoothLE for controlling the BOT. I visited Dennis Thursday and we swapped some hardware. BLE is definitely an option for control from an iPhone or Android app. Dennis posted a communication app demo video here: http://vimeo.com/84914492
In addition to web and iphone apps for controlling the ActivityBot, we have spent time on IDEs. I demo'd the PC based SpinaWeb (Spinny Weby Devy) browser app at Parallax which requires a server running on the local PC to work for the moment http://www.youtube.com/watch?v=ko3HLUlxo-Q . It worked probably a little too good because it was a very short demo. In the near future I hope to have a version that uses Heater's Javascript version of the OpenSpin compiler. Here is a better video of the SpinaWeb app: http://youtu.be/Ew009kdbmxU
What I didn't get a chance to show was Dennis' iPhone BluetoothLE SpinTab demo which I missed because it was in my less frequently used Yahoo mail. Here's a video demo Dennis made of SpinTab: http://vimeo.com/84916113
I'm attaching some pics of the different pages mentioned above.
@ Ken,Thomas,Brian,Bruce and Tom , guys will you try this code out and give me some feedback, the sample runs with or without wifi. If you want to try the wifi scroll down to the Comm command and make sure your ip and port are entered.
The zip file attached contains three images that will need copying to your iPad. I am not concerned what the images look like but they are there to serve the example. Also in the zip file is the full techBasic source and a simple spin file for testing the wifi. Again if you dont want to try the wifi just use the techBasic source and the images.
Almost everything is separated into sub routines and the idea is that these sub routines can be modified or discarded depending on what your thoughts are.
The example demonstrates 6 bytes transmitted and 6 bytes echoed back.
Byte 0 uses its bits as digital switches that contain the status of the segmented control (R/C,Ping,Light and Halt) and the status of LED 1 and LED 2, bits 0-3 for the segmented control and bits 4 and 5 for the LEDs.
Bytes 1 and 2 are x and y accelerometer data.
The LEDs have a touch area, tapping the graphic will change its "brightness" and change the value of data byte 0.
Jeff T.
Looks awesome !!
I have it running on the iPad .Did you crank up the serial comm speed from the xbee to prop ?( spin code shows 115200) I have yet gotten it to connect to prop, I'm checking my end for problems.
Brian