While working on obstacle avoidance code for the autonomous mode, it became desirable to have a way to detect the amount of time that has expired. This is especially useful for detecting how long the robot has been stopped and how long it has been walking in a given direction.
Adding a timer interrupt in Basic Atom Pro code is actually quite easy - there is an example in the Basic Atom Pro manual.
The following two commands configure a timer interrupt on the Basic Atom Pro:
ONINTERRUPT TIMERAINT,handle_timerA
TMA= (TMA & 0xF0) 0x4 ;sets timera to increment once every 256 clock cycles
Here is the code that will run each time the interrupt is triggered:
handle_timerA
currenttimerval = currenttimerval + 1
resume
In the code listed above, TIMERAINT is an overflow interrupt and when this interrupt occurs, handle_timerA routine is executed and returned from by the resume command - the routine just counts 256 clock cycle clumps as one interval called currenttimerval.
Here is the code that starts the timer timing:
ENABLE TIMERAINT
Simple stuff. Stopping the timer is just as easy:
DISABLE TIMERAINT
So, we now have an easy to use timer that we just enable to start it ticking and disable to stop it. By the way, there is no explanation in the Basic Atom Pro manual regarding TMA other than a comment in a code listing. For an explanation on TMA, it is necessary to look in the h83664 manual. At first glance, it was a little challenging to understand but as with many things it was just a matter of staring at it long enough until the picture became clear, so to speak. There is also a comprehensive tutorial on the Lynxmotion forums that helped.
It wasn't until I stumbled upon the interrupts tuturial posted by a user in the Lynxmotion forums at http://www.lynxmotion.net/viewtopic.php?t=3496 that I found a caveat about using interrupts on the Basic Atom Pro. It seems that serout commands on the Basic Atom Pro are not always reliable when using interrupts. I confirmed this to be true after watching the Midnight Prowlerbot spasm and twitch in a random fit instead of walking as programmed. At first, I thought that maybe I had done something wrong in my code. After putting DISABLE TIMERAINT before every serout command and ENABLE TIMERAINT after each serout command, I found that everything worked fine. The robot walked as expected. The timer worked.
Unfortunately, enabling and disabling the timer interrupt before each serout command really affects accuracy of the timing. For instance, if the robot is instructed to perform a command that isn't executed each loop, such as an attack sequence, then the amount of time that the timer has been disabled has been changed when compared to just a walking sequence. Although this is not a crucial problem for things such as telling the robot to stop for a few seconds, it could be a problem if more accurate timing was needed.
Since I found the enable/disable interrupts before and after each serout to be an annoyance, I decided that it would be best to simply not use the interrupt. Instead, the Midnight Prowlerbot now counts the number of steps that it has taken when attempting to avoid an obstacle. For instance, this allows the robot to walk left three steps when any forward obstacle is detected instead of attempting to walk left for two seconds. In the future, more complex avoidance sequences than the left turn algorithm will be attempted.
Monday, June 2, 2008
Monday, May 5, 2008
CMUCam2+ with Basic Atom Pro continued...
After initializing, calibrating, and configuring the CMUCam2+, it is now ready for service to do object tracking, motion sensing, or even histogram capture. The code samples provided use the CMUCam in polled mode so that the CMUCam is not continuously dumping information the Basic Atom Pro. This allows the Basic Atom Pro to request the data when ready, rather than using interrupt code.
Since the CMUCam does not work with the hardware serial port functions (hserin,hserout) on the Basic Atom Pro, it could be a little tricky using an interrupt and using the software serial port functions to get data that is being sent as fast as the CMUCam can send it. Since the Midnight Prowlerbot is now using a connection to a laptop from the CMUCam instead, data is no longer polled, but is sent as fast as possible and the laptop buffers it up. The code presented is code that was used on the Midnight Prowlerbot when the CMUCam2+ was connected to the Basic Atom Pro instead of a laptop.
To get a color using the following code, the Midnight Prowlerbot generated a sound which permitted the user up to 10 seconds to place the object directly in front of the CMUCam. After the ten seconds expired, a sound was generated to let the user know that the color was being obtained. A final sound occurs to let the user know that the color was obtained. Here is the code:
The tracking code is very simple but is in a seperate subroutine for convenience. Note that since raw mode on the CMUCam2+ was configured for raw data that the data obtained through tracking will not be readable. The benefit of the raw data mode is that the TC response length will always be the same, whereas in non-raw mode, or readable mode, the response length varies depending on whether the values returned are single digit, two digit, or three digit. here is the code:
And finally, here is the main code that was used. Please note that functions such as searching for the object being tracked and other functions have been removed because this code is just showing how the previously posted subroutines are being used together to make the CMUCam2+ usable with the Basic Atom Pro. Besides, I found that using the CMUCam2+ built in tracking was much faster and more reliable than trying to respond quickly enough to overcome the communications delays between the CMUCam2+ and Basic Atom Pro and track reliably.
Instead, I eventually just used the built in tracking to automatically move the pan and tilt servos and acquired the values through the TC responses. This allowed tracking to be responsive and allowed the Basic Atom Pro to also be responsive since it wasn't bogged down trying to do tracking, which required even more communication. Here is the code:
Since the CMUCam does not work with the hardware serial port functions (hserin,hserout) on the Basic Atom Pro, it could be a little tricky using an interrupt and using the software serial port functions to get data that is being sent as fast as the CMUCam can send it. Since the Midnight Prowlerbot is now using a connection to a laptop from the CMUCam instead, data is no longer polled, but is sent as fast as possible and the laptop buffers it up. The code presented is code that was used on the Midnight Prowlerbot when the CMUCam2+ was connected to the Basic Atom Pro instead of a laptop.
To get a color using the following code, the Midnight Prowlerbot generated a sound which permitted the user up to 10 seconds to place the object directly in front of the CMUCam. After the ten seconds expired, a sound was generated to let the user know that the color was being obtained. A final sound occurs to let the user know that the color was obtained. Here is the code:
The tracking code is very simple but is in a seperate subroutine for convenience. Note that since raw mode on the CMUCam2+ was configured for raw data that the data obtained through tracking will not be readable. The benefit of the raw data mode is that the TC response length will always be the same, whereas in non-raw mode, or readable mode, the response length varies depending on whether the values returned are single digit, two digit, or three digit. here is the code:
And finally, here is the main code that was used. Please note that functions such as searching for the object being tracked and other functions have been removed because this code is just showing how the previously posted subroutines are being used together to make the CMUCam2+ usable with the Basic Atom Pro. Besides, I found that using the CMUCam2+ built in tracking was much faster and more reliable than trying to respond quickly enough to overcome the communications delays between the CMUCam2+ and Basic Atom Pro and track reliably.
Instead, I eventually just used the built in tracking to automatically move the pan and tilt servos and acquired the values through the TC responses. This allowed tracking to be responsive and allowed the Basic Atom Pro to also be responsive since it wasn't bogged down trying to do tracking, which required even more communication. Here is the code:
Using Basic Atom Pro with CMUCam2+
Since formatting program code within the blog editor is such a challenge, I'm just including snapshots of the code. I would prefer otherwise so that it would be easy to copy-and-paste the code, but formatting the code properly for display just does not seem to be possible. Note that all of the code snippets were developed and tested on version 8.0.1.0 of the IDE for the Basic Atom Pro. Click on the code snippets to see the printout full-sized.
Next is calibration of the CMUCam2+ and here is the code for it:
At this point, the CMUCam2+ is ready to do things such as color tracking, motion tracking, histogram and other functions. The next posting will cover color tracking.
Here is the code that I used to initialize the CMUCam2+:
Next is calibration of the CMUCam2+ and here is the code for it:
Next, the CMUCam2+ is configured as follows:
At this point, the CMUCam2+ is ready to do things such as color tracking, motion tracking, histogram and other functions. The next posting will cover color tracking. Monday, April 21, 2008
Using Basic Atom Pro with PING Ultrasonic Sensor
I've actually found a lot of information on using the PING ultrasonic sensor. There is even a forum topic in the Lynxmotion forums that goes through the whole process of developing code to get the Basic Atom Pro to work with the PING sensor located at http://www.lynxmotion.net/viewtopic.php?t=1819&postdays=0&postorder=asc&highlight=pro+ping+code&start=0
This code is posted here just to document what is used in the Midnight Prowlerbot. Here is the code that I used:
'Ultrasonic module - PING available from Lynxmotion or Parallax
Sonar_Pulse_Dat con P10
GetDistance
Please forgive the lack of proper indentation in the above code listing and previous code listings. I couldn't get the posting tool to cooperate enough to do proper indentations and I didn't want to take snapshots because I wanted people to be able to copy-and-paste the listings. The measurement result will be in the cms variable in centimeters.
The most significant difference between the code listed above for the PING and the code that is often listed on other websites for the Basic Atom non-Pro is the use of the rctime command instead of using pulsin. This is done because pulsin seems to be buggy on the Basic Atom Pro whereas rctime works fine. The pulsin bug is mentioned in several places on the Lynxmotion and Basic Micro forums.
The other difference in the above code and code that would be used on a non-Pro Basic Atom is that pulsout uses 10 for the time instead of 5. This is because the time is in 0.5 microsecond increments on the Basic Atom Pro compared to 1.0 microsecond increments on the Basic Atom.
This post is the last of three code listings for the different sensors currently used on the Midnight Prowlerbot. I still have a Memsic 2125 accelerometer that I could connect, but I can't see a real use for it at the moment on the Midnight Prowlerbot and I have my hands full with projects for the CMUCam2+. Posts from this point forward will be mostly about different projects with the CMUCam2+ and related code unless I decide to reconfigure the robot or add another sensor.
This code is posted here just to document what is used in the Midnight Prowlerbot. Here is the code that I used:
'Ultrasonic module - PING available from Lynxmotion or Parallax
Sonar_Pulse_Dat con P10
GetDistance
Low Sonar_Pulse_Datreturn
pulsout Sonar_Pulse_Dat, 10
RCTIME Sonar_Pulse_Dat, 1,rawDist
if rawDist > 65000 then
goto ErrorDist
endif
RCTIME Sonar_Pulse_Dat, 0, rawDist
PING_Scale.highword = 0
PING_Scale.lowword= 2260
cms = (rawDist */ PING_Scale ) / 2
goto GetDistanceExit
ErrorDist
cms = 0
GetDistanceExit
Please forgive the lack of proper indentation in the above code listing and previous code listings. I couldn't get the posting tool to cooperate enough to do proper indentations and I didn't want to take snapshots because I wanted people to be able to copy-and-paste the listings. The measurement result will be in the cms variable in centimeters.
The most significant difference between the code listed above for the PING and the code that is often listed on other websites for the Basic Atom non-Pro is the use of the rctime command instead of using pulsin. This is done because pulsin seems to be buggy on the Basic Atom Pro whereas rctime works fine. The pulsin bug is mentioned in several places on the Lynxmotion and Basic Micro forums.
The other difference in the above code and code that would be used on a non-Pro Basic Atom is that pulsout uses 10 for the time instead of 5. This is because the time is in 0.5 microsecond increments on the Basic Atom Pro compared to 1.0 microsecond increments on the Basic Atom.
This post is the last of three code listings for the different sensors currently used on the Midnight Prowlerbot. I still have a Memsic 2125 accelerometer that I could connect, but I can't see a real use for it at the moment on the Midnight Prowlerbot and I have my hands full with projects for the CMUCam2+. Posts from this point forward will be mostly about different projects with the CMUCam2+ and related code unless I decide to reconfigure the robot or add another sensor.
Using Basic Atom Pro with Sharp GP2D12 IR Sensor
Here is a listing of code used in the Midnight Prowlerbot for handling the Sharp GP2D12 infrared sensor readings.
'Infrared module - GP2D12 IR Sensor available from Lynxmotion
IR_LDat con P16 'AX2 (analog)
IR_RDat con P17 'AX3 (analog)
'Infrared reading conversion - this module is not linear and this compensates for it
IRconverttable bytetable 80,80,80,80,80,80,80,80,80,78,76,74,72,70,68,66,64,62,60, 59,58,57,55,53,52,51,50,49,48,47,45,43,42,41,40,39,38,37,35,33,
32,31,30,30,29,29,28,28,27,27,26,26,26,25,25,25,24,24,24,23,
23,22,22,21,21,20,20,20,19,19,18,18,18,17,17,16,16,16,15,15,
15,14,14,13,13,13,12,12,11,11,11,10,10,10,10,10,10,10,10,10
GetIRDistance
Notice that IR_RDat and IR_LDat do not use analog in pins that might be expected - they are using P16 and P17, not AX2 and AX3 as would be used on a Basic Atom. When I used AX2 and AX3, or even just 2 and 3 as in the manual, I couldn't get the sensors to work at all. Little did I realize that the adin command prefers a 'P' identified pin to work.
Since I rarely look for information on a device before using it, other than the manual or device sheet, I had no idea that the adin command had a quirk. It was after hours of frustration that I found a post on the Lynxmotion forums at http://www.lynxmotion.net/viewtopic.php?t=570&highlight=gp2d12 that described the pin identification problem.
Incidentally, the pin identifiers are mentioned in the Basic Atom Pro manual under the adin description, but what isn't mentioned is that if an 'AX#' identifier is used instead of a 'P#' identifier that the adin command will not work; however, the 'AX#' identifier works fine with the adin command on the Basic Atom non-Pro.
Oddly, I've had identifier issues with other commands also. It appears that using an assigned constant to identify a pin, such as using IR_RDat to identify P17, does not always work. For instance, serin does not seem to work with assigned constant identifiers, but works fine with 'P#' identifiers. Unfortunately, there is no indication that things aren't working as the code compiles and programs just fine.
I've even had a similar issue come up with 'if' statements only to find that not using an assigned constant identifier fixed the non-working code. This type of thing has happened on several occassions and failing to be aware of it caused frustration nearly to the point of forcible hair removal and uncontrollable mumbling. By the way, the identifier bug was on version 8.0.1.0 of the IDE. I'm not sure if it exists in the latest version.
'Infrared module - GP2D12 IR Sensor available from Lynxmotion
IR_LDat con P16 'AX2 (analog)
IR_RDat con P17 'AX3 (analog)
'Infrared reading conversion - this module is not linear and this compensates for it
IRconverttable bytetable 80,80,80,80,80,80,80,80,80,78,76,74,72,70,68,66,64,62,60, 59,58,57,55,53,52,51,50,49,48,47,45,43,42,41,40,39,38,37,35,33,
32,31,30,30,29,29,28,28,27,27,26,26,26,25,25,25,24,24,24,23,
23,22,22,21,21,20,20,20,19,19,18,18,18,17,17,16,16,16,15,15,
15,14,14,13,13,13,12,12,11,11,11,10,10,10,10,10,10,10,10,10
GetIRDistance
adin IR_RDat, IR_RRawreturn
IR_RFcms = tofloat(IR_RRaw) / 5.12
IR_Rcms = IRconverttable(toint IR_RFcms)
if IR_RRaw > 512 then
IR_Rcms = 99
endif
adin IR_LDat, IR_LRaw
IR_LFcms = tofloat(IR_LRaw) / 5.12
IR_Lcms = IRconverttable(toint IR_LFcms)
if IR_LRaw > 512 then
IR_Lcms = 99
endif
Notice that IR_RDat and IR_LDat do not use analog in pins that might be expected - they are using P16 and P17, not AX2 and AX3 as would be used on a Basic Atom. When I used AX2 and AX3, or even just 2 and 3 as in the manual, I couldn't get the sensors to work at all. Little did I realize that the adin command prefers a 'P' identified pin to work.
Since I rarely look for information on a device before using it, other than the manual or device sheet, I had no idea that the adin command had a quirk. It was after hours of frustration that I found a post on the Lynxmotion forums at http://www.lynxmotion.net/viewtopic.php?t=570&highlight=gp2d12 that described the pin identification problem.
Incidentally, the pin identifiers are mentioned in the Basic Atom Pro manual under the adin description, but what isn't mentioned is that if an 'AX#' identifier is used instead of a 'P#' identifier that the adin command will not work; however, the 'AX#' identifier works fine with the adin command on the Basic Atom non-Pro.
Oddly, I've had identifier issues with other commands also. It appears that using an assigned constant to identify a pin, such as using IR_RDat to identify P17, does not always work. For instance, serin does not seem to work with assigned constant identifiers, but works fine with 'P#' identifiers. Unfortunately, there is no indication that things aren't working as the code compiles and programs just fine.
I've even had a similar issue come up with 'if' statements only to find that not using an assigned constant identifier fixed the non-working code. This type of thing has happened on several occassions and failing to be aware of it caused frustration nearly to the point of forcible hair removal and uncontrollable mumbling. By the way, the identifier bug was on version 8.0.1.0 of the IDE. I'm not sure if it exists in the latest version.
Sunday, April 20, 2008
Using Basic Atom Pro with HM55B compass module
I've seen code for every sensor that the Midnight Prowlerbot is using available for Basic Stamp modules and most of it available for Basic Atom modules, but not Basic Atom Pro modules. Below is a listing of the HM55B code that I use in the Midnight Prowlerbot:
'Compass Module - HM55B available from Parallax
'Note: the module would not work accurately without the pause commands
'pin constants
Comp_En con P5
Comp_Clk con P6
Comp_DinDout con P7
'compass constants
Comp_Reset con 00
Comp_Measure con %1000
Comp_Report con %1100
Comp_Ready con %1100
'variables
Comp_x var sword
Comp_y var sword
Comp_status var Nib
fangle var float
Comp_angle var Word
GetCompass
'this routine gets the axes from the compass module for calculating direction.
'Note: software calibration may be needed
'clear variables first Comp_status = 0
Comp_x = 0
Comp_y = 0'send reset command to module
high Comp_En
pause 2
low Comp_En
shiftout Comp_DinDout,Comp_Clk,MSBFIRST,[Comp_Reset\4]
pause 2'start measuring command
high Comp_En
pause 2
low Comp_En
shiftout Comp_DinDout,Comp_Clk,MSBFIRST,[Comp_Measure\4]
pause 2'loop until the module tells us that it is ready with the data
repeathigh Comp_En
pause 2
low Comp_En'measurement status command
shiftout Comp_DinDout,Comp_Clk,MSBFIRST,[Comp_Report\4]
'reply to status request
shiftin Comp_DinDout,Comp_Clk,MSBPOST,[Comp_status\4]until Comp_status = Comp_Ready
'get the x and y values from the module
shiftin Comp_DinDout,Comp_Clk,MSBPOST,[Comp_x\11,Comp_y\11]'disable the module
high Comp_En'store 11 bits as a signed word (both axis)
if (Comp_y.bit10 = 1) thenComp_y = Comp_y - %11111111111endif
if (Comp_x.bit10 = 1) thenComp_x = Comp_x - %11111111111endif
fatan2 tofloat Comp_x\tofloat Comp_y + 0.1, fangle
Comp_angle = toint(fangle / 3.1416) * 180 + 179
return
I cannot take credit for originating the code for each of the modules used in the Midnight Prowlerbot, but I can take credit for developing code based on what I found, testing it, and modifying it and verifying that it works. Some of the code is based on what I was able to find in the Lynxmotion forums and some is based on information from a variety of other websites as well as of course based on original code for Basic Stamp modules.
When I was trying to integrate the related modules into the Midnight Prowlerbot, I just wish that I could have gone somewhere to get the necessary code and plug it in instead of spending hours debugging and trying different things; so, I've made the code available here, in one place, for anyone that is trying to get such modules to work with a Basic Atom Pro.
Friday, April 11, 2008
BlueSmirf and Basic Atom Pro
The BlueSmirf bluetooth modem available from Sparkfun (http://www.sparkfun.com/) provides an easy way to add wireless communications to a robot that doesn't need to communicate beyond about 30 feet. The current version of the Midnight Prowlerbot uses a BlueSmirf connected to the CMUCam2+ to allow wireless control of the camera from a laptop.
It seems that every module or device has some sort of gotcha and the gotcha with the BlueSmirf is that if it is not in fast data mode that the CMUCam2+ will overrun the buffer of the BlueSmirf and cause it to freeze when transferring an image. This is easily fixed by going into command mode and issuing ATMF to cause the BlueSmirf to use fast data transfer mode wherein it ignores BlueSmirf commands and simply transfers data. This applies to BlueSmirf v1 - I'm not sure if it applies to BlueSmirf v2.
I wanted more direct control of the Midnight Prowlerbot by communicating directly with the Atom Bot Board (ABB) instead of using the CMUCam2+ servo output to signal commands to the ABB. The goal was simply to split the receive line from the BlueSmirf to the CMUCam2+ and the ABB. Using a resistor to buffer between the ABB and the BlueSmirf while having a direct connection from the BlueSmirf to the CMUCam2+ achieved the goal. Any commands received through the BlueSmirf would be sent to both devices and each device would just ignore messages not intended for it.
The gotcha is that the Basic Atom Pro will not receive from the BlueSmirf any faster than 38400 baud. This was the limit using the hardware serial port. The max for the software serial port is 57600 baud anyway, so I didn't even bother with it. It did not matter if the BlueSmirf was in fast data mode or not, 38400 was the max for communicating with the Basic Atom Pro. It also didn't matter if the Basic Atom Pro was the only thing connected to the BlueSmirf or if the connection was being shared with the CMUCam2+, the limit was 38400. This appeared to be the true when using just a Basic Atom 28 instead of the Pro as well.
The 38400 baud limit would not be a problem if it was not for the desire to transfer images from the camera and have motion detection and color updates that would update as quickly as possible. So in the interest of not giving up these features, I just reconfigured the Midnight Prowlerbot back to the way it was using the servo output from the CMUCam2+ as the command pipeline.
The next revision of the bot is apparently going to need a second BlueSmirf since I can't seem to get both the CMUCam2+ and ABB/Basic Atom Pro to receive at the same speed without sacrificing more than I'm willing to tolerate. By not having to send commands through the CMUCam2+, it will no longer be necessary to interrupt color or motion tracking to update the robot position.
It seems that every module or device has some sort of gotcha and the gotcha with the BlueSmirf is that if it is not in fast data mode that the CMUCam2+ will overrun the buffer of the BlueSmirf and cause it to freeze when transferring an image. This is easily fixed by going into command mode and issuing ATMF to cause the BlueSmirf to use fast data transfer mode wherein it ignores BlueSmirf commands and simply transfers data. This applies to BlueSmirf v1 - I'm not sure if it applies to BlueSmirf v2.
I wanted more direct control of the Midnight Prowlerbot by communicating directly with the Atom Bot Board (ABB) instead of using the CMUCam2+ servo output to signal commands to the ABB. The goal was simply to split the receive line from the BlueSmirf to the CMUCam2+ and the ABB. Using a resistor to buffer between the ABB and the BlueSmirf while having a direct connection from the BlueSmirf to the CMUCam2+ achieved the goal. Any commands received through the BlueSmirf would be sent to both devices and each device would just ignore messages not intended for it.
The gotcha is that the Basic Atom Pro will not receive from the BlueSmirf any faster than 38400 baud. This was the limit using the hardware serial port. The max for the software serial port is 57600 baud anyway, so I didn't even bother with it. It did not matter if the BlueSmirf was in fast data mode or not, 38400 was the max for communicating with the Basic Atom Pro. It also didn't matter if the Basic Atom Pro was the only thing connected to the BlueSmirf or if the connection was being shared with the CMUCam2+, the limit was 38400. This appeared to be the true when using just a Basic Atom 28 instead of the Pro as well.
The 38400 baud limit would not be a problem if it was not for the desire to transfer images from the camera and have motion detection and color updates that would update as quickly as possible. So in the interest of not giving up these features, I just reconfigured the Midnight Prowlerbot back to the way it was using the servo output from the CMUCam2+ as the command pipeline.
The next revision of the bot is apparently going to need a second BlueSmirf since I can't seem to get both the CMUCam2+ and ABB/Basic Atom Pro to receive at the same speed without sacrificing more than I'm willing to tolerate. By not having to send commands through the CMUCam2+, it will no longer be necessary to interrupt color or motion tracking to update the robot position.
Thursday, April 10, 2008
Third Generation Bot and Netbeans
This is the most recent schematic for the Midnight Prowlerbot. I decided that it was best to simply control the CMUCam2+ using the Java GUI available from http://www.cs.cmu.edu/~cmucam2/downloads.html. Besides, it is interesting to be able to access video from the camera and actually see it - in some cases it has helped identify lighting issues that could never have been observed any other way. Incidentally, proper lighting is absolutely crucial for getting good results with the CMUCam 2+.
Instead of directly controlling the robot through bluetooth as was once done, now the robot is controlled indirectly through bluetooth to the CMUCam 2+ and eventually to the ABB. By sending servo settings for servo 2 on the CMUCam2+, it is possible to instruct the ABB. The ABB just polls the servo 2 output from the CMUCam 2+ for instruction. Of course the robot can also be controlled directly by wireless PS2 controller. However, the intent of controlling the robot through the servo 2 output is to allow the CMUCam 2+ GUI to make decisions for the robot based upon video processing feedback.
At first, an attempt to port the Java GUI to VB.Net was tried and failed. It didn't fail miserably, and it actually worked somewhat, but the serial port event handling in VB.Net seemed quirky and unreliable so I gave up on it. In some cases, an event would trigger when only a single character was in the buffer while in other cases an event would trigger only one time when there were multiple messages received. Apparently, carriage return (chr 13) does not necessarily indicate the end of a message even if every attempt is made to assure that it should.
I wanted the program to be in VB.Net simply because the GUI editing in VB.Net is far easier than it is in Java. After one too many frustrations with serial port control and VB.Net, I gave up and just started editing the Java program instead. However, trying to add any GUI object to an existing Java program can be a crapshoot if your Java is as rusty as mine. So, I decided to simplify the existing Java GUI for my benefit by converting it to a Netbeans (http://www.netbeans.org/) based program.
As I understand the Java community, and I'm no Java pro but more of a Java hack, Netbeans is loved or hated with no in between. Netbeans is a GUI answer for the difficult to use GUI functions of Java. Although there are GUI assistants available for other IDE's, such as Eclipse, I've come to prefer the GUI development in Netbeans. It may have something to do with the fact that I used to use Netbeans long ago when it was the only IDE with GUI support.
Unfortunately, to use the GUI assistant in Netbeans I had to first redo the CMUCam GUI program using the Netbeans GUI assistant - I couldn't just convert the existing program to use the GUI assistant. This went fairly smoothly, but the more that I used Netbeans the more it annoyed me because it seems to snag and just stop every so often, even with the autosave turned off.
I eventually got the CMUCam GUI converted to Netbeans anyway and found it very easy to add robot control to the GUI for sending the robot in a compass direction, and added functions for controlling the robot just as I was able to with the first generation control program that I wrote. I even added the ability to load an area layout, place the robot in a room of the layout, place the robot goal, and have the robot automatically navigate to the goal. Screenshots of the modified Java GUI and program explanations will be posted later.
Instead of directly controlling the robot through bluetooth as was once done, now the robot is controlled indirectly through bluetooth to the CMUCam 2+ and eventually to the ABB. By sending servo settings for servo 2 on the CMUCam2+, it is possible to instruct the ABB. The ABB just polls the servo 2 output from the CMUCam 2+ for instruction. Of course the robot can also be controlled directly by wireless PS2 controller. However, the intent of controlling the robot through the servo 2 output is to allow the CMUCam 2+ GUI to make decisions for the robot based upon video processing feedback.
At first, an attempt to port the Java GUI to VB.Net was tried and failed. It didn't fail miserably, and it actually worked somewhat, but the serial port event handling in VB.Net seemed quirky and unreliable so I gave up on it. In some cases, an event would trigger when only a single character was in the buffer while in other cases an event would trigger only one time when there were multiple messages received. Apparently, carriage return (chr 13) does not necessarily indicate the end of a message even if every attempt is made to assure that it should.
I wanted the program to be in VB.Net simply because the GUI editing in VB.Net is far easier than it is in Java. After one too many frustrations with serial port control and VB.Net, I gave up and just started editing the Java program instead. However, trying to add any GUI object to an existing Java program can be a crapshoot if your Java is as rusty as mine. So, I decided to simplify the existing Java GUI for my benefit by converting it to a Netbeans (http://www.netbeans.org/) based program.
As I understand the Java community, and I'm no Java pro but more of a Java hack, Netbeans is loved or hated with no in between. Netbeans is a GUI answer for the difficult to use GUI functions of Java. Although there are GUI assistants available for other IDE's, such as Eclipse, I've come to prefer the GUI development in Netbeans. It may have something to do with the fact that I used to use Netbeans long ago when it was the only IDE with GUI support.
Unfortunately, to use the GUI assistant in Netbeans I had to first redo the CMUCam GUI program using the Netbeans GUI assistant - I couldn't just convert the existing program to use the GUI assistant. This went fairly smoothly, but the more that I used Netbeans the more it annoyed me because it seems to snag and just stop every so often, even with the autosave turned off.
I eventually got the CMUCam GUI converted to Netbeans anyway and found it very easy to add robot control to the GUI for sending the robot in a compass direction, and added functions for controlling the robot just as I was able to with the first generation control program that I wrote. I even added the ability to load an area layout, place the robot in a room of the layout, place the robot goal, and have the robot automatically navigate to the goal. Screenshots of the modified Java GUI and program explanations will be posted later.
Monday, March 10, 2008
CMUCam2+ and Basic Atom arghh...
After several weeks of reading, experimentation, search, and more experimentation, the CMUCam2+ finally worked with the Basic Atom module. It even worked with the Basic Atom Pro module without any changes necessary. For those that have worked with both the Basic Atom and Basic Atom Pro, this concern will sound familiar - for those that have not, the problem is simply that the Basic Atom Pro chip is not based on a Microchip Pic as the Basic Atom is and thus it has different characteristics and quirks. Fortunately, none of those quirks surfaced in this case.
Shown is a view of the CMUCam 2+ board that is available from Acroname. Most of the information needed on this sensor can be obtained from either Acroname or Carnegie Mellon University. Carnegie Mellon University developed the technology that the CMUCam 2+ is based on and licenses it.
The first tip to getting the CMUCam2+ working with a Basic Atom module is to buy or build a RS232 to TTL interface to allow connecting the CMUCam 2+ to a computer. Acroname offers a RS232 to TTL interface, but Futurlec has a similar module for less than $5.00 as of 12/2007. The GUI for the CMUCam devices is invaluable and essentially required for focusing the lens and assessing the light levels needed for accurate detection. There are models of the CMUCam that include the RS232 interface, but they are a little bulkier.
Now connect the GND’s on the Basic Atom module or Atom Bot Board to the CMUCam2+ serial connector, ignore the 5V pin on the serial connector, and connect OUT on the serial connector to your IN input on the Basic Atom module and IN on the serial connector on the CMUCam2+ to OUT on the Basic Atom module.
The baud rate has to be 38400 or less on the Basic Atom for communications to be reliable. Using “I38400” provided the greatest speed that was reliable. The hardware port does not seem to work, even when using an interface chip.
It is crucial to use the following command to the CMUCam 2+ from the Basic Atom for communications to work: “DM 20”. This is a delay command that instructs the CMUCam 2+ to delay before starting a transmission. The DM command had to be “DM 100” for the Basic Atom Pro. The DM command MUST be issued after any RS command (reset) or communications will not work properly—even at lower baud rates.
Friday, February 15, 2008
Second Generation Schematic
The first generation of the Midnight Prowlerbot used bluetooth as a means of communication directly with the Atom Bot Board (and Basic Atom Pro), while the CMUCam2+ also communicated with the Basic Atom Pro. Polling bluetooth and the CMUCam2+ slowed down robot response more than I was willing to tolerate. By the way, the CMUCam2+ would work with the Basic Atom or Basic Atom Pro at a max of 38400 baud (I38400) with the CMUCam2+ using a delay (DM 10) - no settings worked without the delay and the hardware serial port did not work.The resulting frustration turned the robot into the schematic shown above where two Atom Bot Boards are used to basically do multithreading. The one board handled motion while the other board handled sensors and video. The two ABB boards communicated with each other using serial but with a notifier input to allow programs to avoid even checking for serial input until it was actually available.
However, a drawback of this configuration is that using the video functions requires too much experimentation during programming since it isn't possible to actually see what the camera is seeing while programming.
Tuesday, February 12, 2008
Midnight Prowlerbot Control Description
The screenshot displays the main screen for the Midnight ProwlerBot Control program. Each of the buttons shown perform the same function as the corresponding buttons on the PS2 controller.
The Joysticks section simulates joystick action by using slidebars. The slidebars maintain their position so that the robot can be set walking in a direction without being held as would be done with a joystick. Since it can be difficult to slide all of the bars back to zero position quickly in the event that the robot is about to collide with something, a Stop button is provided that acts as an emergency stop for the robot.
The sensors section displays the direction that the robot is facing in degrees. For instance, it may display W=270, which would mean that the robot is facing west which is also 270 degrees.
Distances to objects are displayed in centimeters with the topmost object displaying the distance sensed by the ultrasonic sensor and the infrared sensor distance displayed below. Two types of sensors are used primarily because of expense. Ultrasonic sensors cost at least twice the price of a Sharp GP2D12 IR sensor.
The ultrasonic sensor is used for obstacle checking directly in front of the robot while IR sensors are used on either side of the robot. Currently, only one IR sensor is installed on the robot but a second IR sensor will soon be installed. By using IR sensors on the sides at approximately a 30 degree angle from center, it is possible to make sure that the robot can walk through an opening without interference. By using the ultrasonic sensor on the front, it is possible to look for obstacles or objects at longer distance than with inexpensive IR sensors.
WinCVS was used for version control and change tracking for both the Midnight ProwlerBot VB.Net program and the Basic Atom Pro code in the robot.
The Joysticks section simulates joystick action by using slidebars. The slidebars maintain their position so that the robot can be set walking in a direction without being held as would be done with a joystick. Since it can be difficult to slide all of the bars back to zero position quickly in the event that the robot is about to collide with something, a Stop button is provided that acts as an emergency stop for the robot.
The sensors section displays the direction that the robot is facing in degrees. For instance, it may display W=270, which would mean that the robot is facing west which is also 270 degrees.
Distances to objects are displayed in centimeters with the topmost object displaying the distance sensed by the ultrasonic sensor and the infrared sensor distance displayed below. Two types of sensors are used primarily because of expense. Ultrasonic sensors cost at least twice the price of a Sharp GP2D12 IR sensor.
The ultrasonic sensor is used for obstacle checking directly in front of the robot while IR sensors are used on either side of the robot. Currently, only one IR sensor is installed on the robot but a second IR sensor will soon be installed. By using IR sensors on the sides at approximately a 30 degree angle from center, it is possible to make sure that the robot can walk through an opening without interference. By using the ultrasonic sensor on the front, it is possible to look for obstacles or objects at longer distance than with inexpensive IR sensors.
WinCVS was used for version control and change tracking for both the Midnight ProwlerBot VB.Net program and the Basic Atom Pro code in the robot.
Sunday, January 27, 2008
The main control screen of the Midnight ProwlerBot Control attempts to emulate the controls on a PS2 controller. This is done to ease the transition from using the PS2 controller to using the Midnight ProwlerBot Control—there is no need to memorize a new control scheme.
Naturally, there are significant differences between a PS2 controller and the Midnight ProwlerBot Control. The most obvious is joystick control, which had to be provided in the program using sliders. It is certainly possible to create a custom joystick control instead of using sliders, but sliders are convenient and easy to use. The sliders may be replaced a joystick control at some point in the future.
The lower left side of the main screen provides sensor readings as they are received from the Basic Atom Pro 28. Currently, there is no logic acting based upon the readings, but there will be in the future. For instance, the Midnight ProwlerBot will be able to chase and kick a colored ball into a goal by identifying the colored object and remembering the location of the goal and kicking in the direction of the goal.
Although the logic from the main screen of the program is an emulation of the same functions available on the PS2 controller, the program will eventually provide more autonomous control and retain the PS2 functionality for convenience and testing.
The servo ranges may be set by accessing the Servo Ranges screen. Not only may the upper and lower ranges for individual servos be set, which is not available in the original Basic Atom code, but the zero points of individual servos may also be set. There are also buttons available to reset the ranges to their original ranges and to set the zero points to zero.
The Servo Control screen provides the ability control servos individually or as a group and outputs the resulting command in a textbox to be viewed or copied for possible use later. This functionality is provided mainly as a convenience for the programmer to be able to easily create a sequence and copy the commands to program code. This screen will be used in developing the kicking motions and celebration motions that will eventually exist in the Midnight ProwlerBot.Thursday, January 10, 2008
The first generation...
The Midnight ProwlerBot is based on a hexapod kit available from Lynxmotion, but with additional sensors and programming written in VB.Net using Bluetooth to communicate with the robot.
The original kit consisted of 18 servos, the robot structure, an SSC-32 servo control board, and an Atom Bot Board main control board with a Basic Atom 28 module doing the logic processing.
The original programming provided with the kit is based upon inverse kinematics, which provides smooth motions that can execute simultaneously and sometimes look creepily life-like.
Unfortunately most of the memory of the Basic Atom 28 module was used for the motion control although there was space available to add some simple sensors. However, space quickly ran out as more sensors were added and more logic was added based upon feed back from the sensors. As a result, the Basic Atom Pro 28 was purchased and installed.
The Basic Atom 28 Pro module provided plenty of space for most things, but adding video processing pushed memory requirements to the limits. Besides, there simply wasn’t enough memory to store a large number of motion sequences, in addition to the “praying mantis” and the “flying” sequences included with the original program.
By using Bluetooth to communicate with a laptop and offloading the processing to a custom program on the laptop, it became possible to store a nearly infinite number of motion sequences as well as add complex logic based on sensor values and combinations. The resulting VB.Net program, Midnight ProwlerBot Control, obtains sensor values and data from the Basic Atom Pro 28 and sends motion sequences to the SSC-32 servo controller.
The Midnight ProwlerBot Control is basically a port of the original Basic Atom 28 BASIC code to VB.Net with some added features.
The ability to switch from Bluetooth/laptop control back to Basic Atom Pro 28 control is provided and allows the Midnight ProwlerBot to also be used with a wireless PS2 controller without a laptop. This feature is available to provide the ability to do quick, easy demonstrations of the features that the robot originally came with, although the more advanced features in the original code had to be removed to allow for additional sensor support.
The original kit consisted of 18 servos, the robot structure, an SSC-32 servo control board, and an Atom Bot Board main control board with a Basic Atom 28 module doing the logic processing.
The original programming provided with the kit is based upon inverse kinematics, which provides smooth motions that can execute simultaneously and sometimes look creepily life-like.
Unfortunately most of the memory of the Basic Atom 28 module was used for the motion control although there was space available to add some simple sensors. However, space quickly ran out as more sensors were added and more logic was added based upon feed back from the sensors. As a result, the Basic Atom Pro 28 was purchased and installed.
The Basic Atom 28 Pro module provided plenty of space for most things, but adding video processing pushed memory requirements to the limits. Besides, there simply wasn’t enough memory to store a large number of motion sequences, in addition to the “praying mantis” and the “flying” sequences included with the original program.
By using Bluetooth to communicate with a laptop and offloading the processing to a custom program on the laptop, it became possible to store a nearly infinite number of motion sequences as well as add complex logic based on sensor values and combinations. The resulting VB.Net program, Midnight ProwlerBot Control, obtains sensor values and data from the Basic Atom Pro 28 and sends motion sequences to the SSC-32 servo controller.
The Midnight ProwlerBot Control is basically a port of the original Basic Atom 28 BASIC code to VB.Net with some added features.
The ability to switch from Bluetooth/laptop control back to Basic Atom Pro 28 control is provided and allows the Midnight ProwlerBot to also be used with a wireless PS2 controller without a laptop. This feature is available to provide the ability to do quick, easy demonstrations of the features that the robot originally came with, although the more advanced features in the original code had to be removed to allow for additional sensor support.
Subscribe to:
Posts (Atom)