Sorry, I missed this series of posts. It'll take me a while to catch up.
In the meantime, two directions come to mind. (1) Test to find the root of the limitation or (2) set up a system where the Propeller Asks for more as soon as it has buffered a certain amount of data.
(2) set up a system where the Propeller Asks for more as soon as it has buffered a certain amount of data.
Since I have a system where the propeller basically asks for more information, I am not sure why or at what point, or how the buffer gets cleared. I am just wondering if I have to manually clear the XBee buffer, but not sure how to do that in C. Is there a command in the fdserial or simpleserial that does that?
The other thing that I noticed in my test runs, was the one wheel active to make the turn, it really is throwing off the bot as far as using the same values for an exact return trip. The way my script program works, it is going to be a non trivial task to make the bot turn on center. Other than that everything is great.
Since I have a system where the propeller basically asks for more information, I am not sure why or at what point, or how the buffer gets cleared. I am just wondering if I have to manually clear the XBee buffer, but not sure how to do that in C. Is there a command in the fdserial or simpleserial that does that?
The fdserial_txFlush()/fdserial_rxFlush() did not cure the problem. I looked at the XBee specs and I did not see any mention of any kind of buffer in the module itself. So the only other option I have is maybe trying out the CTS/RTS scheme, but I am not really clear on what I would gain by doing that, or how I would implement that on the python side. I thought that the XBee to and fro would be much simpler than what it is turning out to be.
My pyAB_prj program is circling the drain, not down the drain yet, because if I remove the scripting part, the program is still viable, and maybe even interesting. After doing an empirical observation, I have identified the problem to be one of data errors. I seems that at some point in the scripting program segment, the data, either being received or being sent, is prone to error. This problem can be fixed, but it will be introducing a potential command run delay problem.
The way the PropGCC program is set up, is it has an interpreter while loop, that could become a potential problem, which waits for a command, executes that command, then sends a signal for the next command. With a functional code error checking code segment, this would introduce a lag in script file command execution, the larger the script file, the potential for greater accumulated command execution lag. The script file command processing lag problem could be overcome by first sending the correct command sequence to an SD file, on the ActivityBot, and then running the script commands from there. Now a bigger problem presents itself, the SD support adds a lot of code to the general program. At this time the PropGCC program is ~14K, by adding the SD it would probably make the program size ~25K, that will start to put pressure on how fancy the interpreter can become, let alone the code error checking program segment.
So I guess it is time to reevaluate the program structure, and see if some potential problems can be shifted to the pyGUI side, but I doubt that. If only that SD support segment could be a whole bunch smaller in size, maybe...
So, I am sort of back on track again, while looking at the PropGCC code I found a bug that was causing the short runs on the long script file. It's now working as expected, till the next bug. Hopefully there will be an explanation as to how to use the encoder feedback so I can use it for recording the drive distances. In the mean time I will have to implement the data logging code on the pyGUI side.
I am basically concluding the POC pyAB_prj, it turned out to be a very interesting project that showed me that going with a, using what the tool does best approach, is very viable. So I got the scripting concept worked out, and it is proving to be very useful, along with some of the other concepts.
Now it is onto, autonomous behavior of the ActivityBot, which will be referred to as autoAB_prj. I guess the POC or goal is to see how autonomous the ActivityBot can be given the on board resources it has available. Andy came up with a code segment, roaming, that I might make as the core code. What I am thinking is maybe using a concept like the Minix kernel has. Make a core program that would reside in RAM, and then have support programs that would reside on the SD card which could be loaded and run when needed. This could be a challenging POC in itself, let alone working out some of the other details.
At the moment the biggest hurdle would be is to overcome the fact that when you add in SD support, you have committed one third of the RAM resources for that alone. You could probably overcome that by using XMMC, but then ABdrive would have to be reconfigured for that purpose, not an easy prospect to contend with.
This is just a general description of the direction this might be going; I still have to do some more planning before I even have a base program to show.
I've managed to get pyserial running with python3.3 on my Windows7 computer. That is, i've been able to run your programs a little.
Over-all I think the transition from python2.* to python3.* is a disaster from the syntax and multi-os serial port perspective.
Tcl/Tk was much easier to get running on the desktop platforms. IMHO, Tcl/Tk is a more practical language than Python.
Nevertheless, below is some Python serial code that you and others may appreciate.
I had to add this to your code because I couldn't quickly figure out what serial expects for COMn > 9.
def scan():
"""scan for available ports. return a list of tuples (num, name)"""
for i in range(256):
try:
s = serial.Serial(i)
s.close() # explicit close 'cause of delayed GC in java
return s.portstr
except serial.SerialException:
pass
return None
# This is hard coded COM port and BAUD.
myport = scan()
if myport == None:
print("No serial port available")
quit()
else:
ser = serial.Serial(myport,9600)
Thanks for the additional code jazzed, I was not sure as to accomplish that part.
IMHO, Tcl/Tk is a more practical language than Python.
When I started that test I wanted something that I could easily run on my RPi and on my Windows computer, therefore I picked Python, only because I was able to find lots of example code for what I wanted to do. I had never heard of Tcl/Tk, so I cannot make any comments as to how it would have worked for my POC. In some of the Tkinter examples I did see some references to Tcl/Tk, but I had no idea of what that was. I may have to look into that, and if it is easily accessible in the RPi and Windows computers, I just may give it a try.
Comments
Sorry, I missed this series of posts. It'll take me a while to catch up.
In the meantime, two directions come to mind. (1) Test to find the root of the limitation or (2) set up a system where the Propeller Asks for more as soon as it has buffered a certain amount of data.
The other thing that I noticed in my test runs, was the one wheel active to make the turn, it really is throwing off the bot as far as using the same values for an exact return trip. The way my script program works, it is going to be a non trivial task to make the bot turn on center. Other than that everything is great.
Ray
fdserial_flush()
https://propsideworkspace.googlecode.com/hg/Learn/Simple%20Libraries/Text%20Devices/libfdserial/Documentation%20fdserial%20Library.html
Ray
The way the PropGCC program is set up, is it has an interpreter while loop, that could become a potential problem, which waits for a command, executes that command, then sends a signal for the next command. With a functional code error checking code segment, this would introduce a lag in script file command execution, the larger the script file, the potential for greater accumulated command execution lag. The script file command processing lag problem could be overcome by first sending the correct command sequence to an SD file, on the ActivityBot, and then running the script commands from there. Now a bigger problem presents itself, the SD support adds a lot of code to the general program. At this time the PropGCC program is ~14K, by adding the SD it would probably make the program size ~25K, that will start to put pressure on how fancy the interpreter can become, let alone the code error checking program segment.
So I guess it is time to reevaluate the program structure, and see if some potential problems can be shifted to the pyGUI side, but I doubt that. If only that SD support segment could be a whole bunch smaller in size, maybe...
Ray
Ray
Now it is onto, autonomous behavior of the ActivityBot, which will be referred to as autoAB_prj. I guess the POC or goal is to see how autonomous the ActivityBot can be given the on board resources it has available. Andy came up with a code segment, roaming, that I might make as the core code. What I am thinking is maybe using a concept like the Minix kernel has. Make a core program that would reside in RAM, and then have support programs that would reside on the SD card which could be loaded and run when needed. This could be a challenging POC in itself, let alone working out some of the other details.
At the moment the biggest hurdle would be is to overcome the fact that when you add in SD support, you have committed one third of the RAM resources for that alone. You could probably overcome that by using XMMC, but then ABdrive would have to be reconfigured for that purpose, not an easy prospect to contend with.
This is just a general description of the direction this might be going; I still have to do some more planning before I even have a base program to show.
Ray
I've managed to get pyserial running with python3.3 on my Windows7 computer. That is, i've been able to run your programs a little.
Over-all I think the transition from python2.* to python3.* is a disaster from the syntax and multi-os serial port perspective.
Tcl/Tk was much easier to get running on the desktop platforms. IMHO, Tcl/Tk is a more practical language than Python.
Nevertheless, below is some Python serial code that you and others may appreciate.
I had to add this to your code because I couldn't quickly figure out what serial expects for COMn > 9.
def scan(): """scan for available ports. return a list of tuples (num, name)""" for i in range(256): try: s = serial.Serial(i) s.close() # explicit close 'cause of delayed GC in java return s.portstr except serial.SerialException: pass return None # This is hard coded COM port and BAUD. myport = scan() if myport == None: print("No serial port available") quit() else: ser = serial.Serial(myport,9600)When I started that test I wanted something that I could easily run on my RPi and on my Windows computer, therefore I picked Python, only because I was able to find lots of example code for what I wanted to do. I had never heard of Tcl/Tk, so I cannot make any comments as to how it would have worked for my POC. In some of the Tkinter examples I did see some references to Tcl/Tk, but I had no idea of what that was. I may have to look into that, and if it is easily accessible in the RPi and Windows computers, I just may give it a try.
Ray
This file shows an example of interacting with the Propeller and a GUI based on tcl/tk.
https://code.google.com/p/tclbits/source/browse/trunk/tclyzer.tcl