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
repeat

high 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) then

Comp_y = Comp_y - %11111111111

endif

if (Comp_x.bit10 = 1) then

Comp_x = Comp_x - %11111111111

endif

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.

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.

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.

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.

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.

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 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.