Nov. 18, 2010
The purpose of the Robot Diagnostic program is primarily to test the correct functioning of the different parts of the robot. The students often add new code to their programs and find the robot stops working in ways they don't think are related to their new code. It is nessesary to have a program that can test all aspects of the robot to ensure it works. That is the puropse of the diagnostic program. It was designed to be easy to use by students, lab instructors and technicians.
The program was written to be used with hyperterminal(although I have also written a Perl/TK script that includs a GUI and can be run on a PC that has Strawbarry Hill Perl installed [as well as the following perl modules Tk and Win32::SerialPort] ---- note that Tk must be compiled and installed and this takes some time -- more at PerlTkGUIdiag.html ).The robot is connected to a PC with a simple passive cable. The program uses a menu system that is easy to navigate.
Oct. 26, 2010 (rev. Oct 27, 2010)
Significant changes to main.c were made for version 4.001 (4.002 fixed a bug). The state machine for the menu system has been retained but it is now the default state of a more encompassing state machine. The function pointer for the new robot diagnostic state machine is called diagnostic_state and as of this version of the program it can point at one of the four possible states. The function pointer concept is presented in some detail with regard to the menu system function pointer. The idea is the same here.
state transition diagram
The menu system runs within the process_command state. The menu system must be in the motor menu1 state in order for the jog option to be available. Restructuring the program in this way should permit the addition of other non menu driven states. For example the simple line follower program itself could be added as a new state of the diagnostic program.
Note that the ovals in the state transition diagram indicate program states. The arrows indicate possible state transitions. The letters adjacent to the arrows indicate a keyboard press in hyperterminal (or a graphical button activated by a mouse press if using the Perl/tk GUI). The arrow without a letter indicates an automatic state transition.
The jog1 and jog2 states both themselves contain a series of sequential sub-states.
Before the diagnostic state machine is started an initialzation function from sumovore.c is run. As part of the initialization of the robot hardware flags are read to determine what type of reset has occured. More on this at Changes to sumovore.c and Sumovore.h .
Oct. 22, 2010
Files specific to version 4.002 can be found at this link
Sept. 2, 2010
Bluetooth restults moved to a new page see bluetooth.html
August 24, 2010
Considering modifying a brainboard to use bluetooth.
<added Oct. 22, 2010> Note that while I have done this out of curiosity it is not needed to use the diagnositc program; however, it could be used to remove the tether between the robot and the PC and allow the PC to gather data as the robot moves around a course or maze.
July 30, 2010
Created a simple graphical interface that allows one to interact with the Robot Diagnostic program with mouse clicks rather than typing keyboard keys. More at the link -> gui/PerlTkGUIdiag.html or in this iframe
July 6, 2010
Version 4.001 of the Robot Diagnostic program now allows one to stop the jog cycle using either a "u" or a "U" on the PC keyboard. It also allows one to switch from a jog1 sequence to a jog2 sequence by typing a "2" (one can switch back by typing a "1". At the moment the difference between jog1 an jog2 is only in the motor speed. jog2 is at full speed while jog1 is a medium speed.
To accommodate different jog sequences (and the possibility of additional sequences) a simple state machine was added to main.c. The new state variable is called diagnostic_state. diagnostic_state is a pointer to a function. In this version diagnostic_state can be one of four values (shown in the table below).
diagnostic_state = jog1_state;
diagnostic_state = jog2_state;
diagnostic_state = process_command;
diagnostic_state = stop_state;
same as version 3.000 jog sequence
new jog sequence
process_command is the same function used in version 3
new state used for transition from jog1 and jog2 back to process_command
The file command_list.h has also been updated with new commands. The commands were added so that the function pointer variable diagnostic_state could have limited scope (only in the file main.c).
The files menu.c, sumovore.c and interrupts.c have also been updated.
all files in version 4.001
An updated version of the diagnostic program will be coming soon for two reasons.
- The existing jog sequence created BrownOut Resets on version 1.0 robots before I started added an extra 22 microFarad capacitor to the output of that regulator. Now this capacitor is in place it appears a different jog sequence is more likely to cause trouble.
- The output of the regulator was somewhat unstable when it lacked a large capacitor near the output pins. This problem showed up at medium speed. It seems plausible the reason was the PWM created a lot of edges and the transients associated with those edges feed the instability in the regulator.
- With the instability fixed BORs are not happening with fresh batteries. As the batteries become depleted the chances of the Low Voltage Detect being activated becomes greater. The event most likely to cause this is having both motors reverse direction at the same time (this draws a lot of current). This could be tested for with a Jog sequence that runs the motors at full speed and allows the motors to obtain full speed before reversing. The new version of the program will probably have two or more jog sequences.
The changes to sumovore.c and interupts.c should be incorparated into the simple curve follower project. In that project the need for further tweeks to sumovore.c are apparent and it would be best to have only one sumovore.c file so that will result in further small changes in the diagnostic project.At the moment I have the sense that we can avoid the addition of a extra battery for the brainboard. Additional testing would be helpful to see how much difference it would make. I suspect that it would allow the use of more depleted batteries but the question remains of how useful that would be. Would it be worth the addition of the extra battery?
April 23, 2010
On April 22 a new feature was added to the diagnostic program that is intended to find a value for the threshold that will ensure the line can not be lost between two sensors. (this works well on the Richmond robots with adjusted sensor resistors but not on the Surrey robot I tested).
Files for this project can be found at the following links:
main.c menu.c menu.h robot_diagnostic.hex process_command.c process_command.h motor_control.c motor_control.h sensor.c sensor.h sumovore.c sumovore.h
osc.c and osc.h are also needed and are expected to be found in the folder "..\Functions".(added April 27, 2010) The source files contain few comments. For an overview of how the program works click on this link or on the image of the State Diagram for the Menu system of the Diagnostic Program for the Robot (see below in April 26, 2010).
Communication with the robot is accomplished with hyperterminal. The configuration file for hyperterminal is here:
A simple passive cable is needed to connect between the robot and the PC COM1 port. Page 13 of the PIC brainboard V 2.0 manual PIC brainboard V 2.0 manual shows the connections between the DB9 connector and pins that fit into the brainboard. As suggested I used a cable from a dead serial mouse for the connector and cable.
Note the level shifter is built into the new Brainboard version 2's so there is no need for the spark fun level shifter.
(image added Nov. 11, 2010)
April 26, 2010
The diagnostic program that runs on a robot works through a menu system. The robot must be connected to a computer with a simple passive cable.
The menu system has been inplemented as a state machine. Click on image below for a link that gives the details. (rev. May 14, 2010 -- there is more detail for both the Motor Menu 1 state and the Sensor Menu 1 state; these have been put into new images -- click on image below ).
The top menu of the menu system looks like this screen shot below. There are essentially two choices at this level: motor or sensor.
- The robot should be on a block if motor is chosen. An empty breadboard works well as a block.
- The robot should be on a test track if sensor is chosen.
In hyperterminal you must enter either m or S for motor or sensor.
In this HTML page you can click on the link to see the next menu...
Kwantlen Polytechnic University
program by Dan Peirce B.Sc.
version 1.100 April 22, 2010
Top Level Menu
m => motor
S => sensor
? or h => help print this menu
May 3, 2010
The documentation has not kept up with the new versions of the diagnositic program.
- In version 2 a feature was added to the motor menu to automatically jog the robot to the left and right. This was intended to be used to check for reliable program execution. (added June 15, 2010 -- set usart to 9600 b ps )
- In version 3 a reliability features were added to watch for brownout conditions, low voltage conditions, and stack overflow . The watchdog timer feature was also enabled. ( added June 15, 2010 -- set usart back to 115200 bps).
v3 code, .HEX & ht file
- I was working out details of using these version 3 features of the PIC in 2008 and only now have picked it up again -
(There is an index of PIC features I investigated in 2008 at http://www3.telus.net/danpeirce/c_18/stdout_change/changing_stdout.html )
Low voltage interupt If the supply voltage should drop 4.5 volts a a low voltage service routine is called. Watchdog timer The program is written so that the watchdog timer is reset frequently. If something interferes with normal program execution and the timer is not reset before it times out the timer will reset the PIC. The timeout could occur when there is a bug in the program or if the PIC itself does not execute the program correctly. brownout reset If the supply voltage drops below 4.3 volts the PIC is held in reset until the voltage returns to normal. This is to avoid possible unpredictable behavior below 4.2 volts. stack overflow reset The PIC has a hardware stack to retain return addresses when C function calls are made. The stack has room for 31 return values. After that the stack will overflow and code will not be executed as expected. This stack overflow reset is intended to alert the programmer that an overflow has occured.
- at that time I wrote the pages linked above I was using the EEPROM data to retain messages -- The diagnostic program is menu (hyperterminal) driven so I am now sending the messages to the USART for the diagnostic program. The new PIC board V2.0 makes comunication between the robot and a PC easier (only a passive cable is needed with the new PIC board.It has been found that brown out conditions can be created. An extra battery was added so that the PIC had a separate 5v supply but the brownouts persisted (prior to June this had only be tried on version 1.0 robots -- added June 17, 2010). The next step is to add optical isolation between the PIC and the motor driver IC (the L293D). It appears this can be done without modifying the existing boards if new boards are added between the mainboard and Brainboard. (it does not now seem that is will be necessary!!! -- added June 17, 2010)
rev. Nov. 18, 2010
Perhaps I should make clear that I have concluded that optical isolation is not needed in our case. I also don't expect an additional battery will be needed. Those ideas are discussed below but the result of that investigation was to add a capacitor to the mainboard of version 1.0 robots and to enable features already built into the microcontroller to improved reliability.
In my experience optical isolation is typically used when:
I believe that the motor driver IC provides sufficient isolation in our case with small PM motors and very short wires. This is in regard to the quote of Mazidi, Mckinlay and Causey down below! These issues were investigated and I think we can now put them to rest.
- interfacing to AC circuits.
- in industrial installations in which it might be possible for control wiring and power wiring to be accidentally shorted together in a mishap.
- when the wires are very long (meaning they go beyond the interior of a single building).
Note at battery_replacement.html#optoisolation
I should point out that in PIC Microcontroller and Embedded Systems by Mazidi, McKinlay and Causey it is suggested that "the PIC18 is protected from EMI created by the motor brushes by using an optoisolator and a separate power supply."
In Figure 17-18 page 656 they show an opto isolator used with the L293 (same driver chip used on the sumovore) and separate power supplies are suggested PIC and the L293 driver. I have run into hobbyists who recommend modifying the sumovore to use a separate battery for the PIC to avoid unexpected resets.
(rev. May 14, 2010) The plan that was outlined in the box shown below is starting to seem like too much work. Last night I thought of an alternate plan which would require fewer optical isolators (just 3 rather than 6) and would require no further changes to the existing robot or brain board 2! One would add circuits and a battery to an expansion board available from microchip.
In this scenario the PIC on the brain board would continue to control the robot as before; however, the student program would be run in a second PIC on an add-on board. The add-on board would have it's own power supply and would connect to the brain board through optical isolators so it would in fact be completely electrically isolated from the robot!
The PIC on the brain board v2 would have just one reliability feature enabled; the watchdog timer would be enabled. This would mean that if the program running on this PIC stopped executing the code in the normal way the watchdog timer would time out causing the PIC to reset and so reenter a known state. This would occur in the order of 30 to 40 ms.
I have found that if I enable the brownout reset the resets occur to frequently with the existing setup. The brownout circuit must be sensitive to conditions that actually only rarely cause the PIC fail. This can be tolerated except when it is important not to lose any values stored in RAM. On reset all values in RAM are lost. This is not important with regard to the low level control close to the hardware as long as the condition does not persist for too long. It is only on the order of 30 ms I think this would hardly be noticeable as long as it does not happen too frequently.
At a higher level one must maintain flags and other variables regarding if the robot has recently seen a line off to the right or the left. In the case of a maze one would keep an internal map of the maze. No resets can be tolerated. If the higher functionality was maintained in a PIC completely isolated from the electric EMI of the motors is should be robust and reliable.
(rev. May 18, 2010)
Having looked at using the I2C interface or the RS232 interface I have decided it would be simpler to use the RS232 interface although this will require the addition of one jumper to the version 2 brain board.
Using the I2C interface would not have required any change to the version 2 brain board; however, it would be much more complex to build an isolation circuit given the bi-directional nature of the I2C interface lines.
From a softward point of view the RS232 seems more straight forward. The purpose of I2C is to allow a microcontroller to talk to several peripherals over the same two line interface. That adds complexity that is not required here. For example the I2C message includes an address so the specified peripheral will respond. The microcontroller is the master and the peripherals are slaves (they only send information reqested).
The intent of RS232 is more our actual situation. We will have two microcontrollers talking to each other peer to peer. RS232 will allow messages to be going in both directions at the same time. This will allow the software to be simpler. The complication is the built in level shifting interface intended to let the brain board talk to a PC. That can be worked around. For example the expansion board can be removed when the diagnostic program is being run on the robot.
(rev. June 16, 2010) On the 15th tests showed very different results for version 1.0 robots and version 1.1 robots (currently there are only 2 version 1.1 robots in Richmond.
from email from me to Mike C.
I have setup the diagnostic program to test for brownouts and got some surprising results when comparing old version 1 robots to the newer version 1.1 robots.
I only have two of the newer robots at the Richmond campus but in testing today so far I have found my jog sequence always causes a brown out reset on version 1 robots and never does on version 1.1 robots (with fresh batteries). I did the test with fresh out of the box batteries and batteries that had a total of 8.7 volts (voltage measured when the robot was on and the motors were disabled).
Note that I tried moving a brainboard from an the new 1.1 robot to the old 1.0 robot and the result was the same; there was a reset on the 1.0 version robot.
The first implication of this is that the version 1.1 robots may be a great deal more reliable than the version 1.0 robots. The new version of the robot main board has what looks like a more logical layout with shorter ground traces. see http://www.kwantlen.ca/science/physics/faculty/dpeirce/notes/sumovore_maintenance_log/sumovoreVersions.html
More on this below at Low votage detect
I guess the question then would be is the isolation still necessary with version 1.1 of the robot (it may be a lot easier to simply use version 1.1 robots if that is all it takes to get better reliability).
I should try more tests with older batteries.
indication of brownout reset <BOR> (running version 1.0 robot)
Note it should say version 3.000 (guess I forgot to change the message in the program).
Where as the version 1.1 robot just kept going and going (I stoped it after 1000 jogs -- <POR> indicates a power on reset i.e. I turned the power off and back on)
When I ran tried the jog sequence on a new version 1.1 robot with old batteries I found I started to get low voltage detection when the total voltage on the batteries was drained to about 6.1 volts. Initially the voltage was higher but after 3069 jog cycles the batteries had discharged down to 6.1 volts and the LVD's started to occur. Initially they were occurring every 200 or so jog cycles. As the batteries continued to discharge the frequency of LVD's increased.
There is a significant difference between the LVD and the BOR.
The voltage difference between the two is small.The LVD causes an interrupt. The interrupt service routine turns off most of the IO of the PIC as quickly as possible in an attempt to slow down the voltage drop. If a BOR occurs it means there was insufficient time to avoid having the voltage drop to the BOR level. If a LVD is indicated then the interrupt service routine was able to avoid a BOR by turning off the motors (and LED's). This means the BOR is an indication of a large dV/dt and a LVD is an indication of a smaller dV/dt.It appears that changing the layout for the version 1.1 robot reduced the
If a low voltage condition last longer than TBOR then a BOR condition exists. The datasheet gives only a minumum value for TBOR .
[correction made on Feb. 25th. 2011 -- including the strike out of characters above]
TBOR > 200 micro seconds dV/dt[correction --- repaced dv/dt with duration] duration that the PIC sees a low voltage condition on the 5 volt supply. I'm guessing that on the ground lines the high current path to the motor controller and the low current path to the PIC was separated so that noise on the ground of the high current path would have less effect on the PIC and the brainboard in general. Also, it is possible the the location of the large filter capacitor is more effective on the version 1.1 board.
I have had a close look at the layout of the version 1.0 and version 1.1 boards and it appears that the version 1.1 board has a smaller dv/dt because the 1000 micro farad capacitor C1 is connected very close to the output of the regulator. On the version 1.0 board the capactor C1 is a long way from the regulator and the motor driver is between (a bad layout). See http://www.kwantlen.ca/science/physics/faculty/dpeirce/notes/apsc1299/2010/mainboard/ground_layout.html
In the image below black indicates a highlighted ground trace on the component side of the board. Gray is a highlighted trace ground trace that is on the solder side of the board (dark gray is a trace I could see -- light gray is a trace I am guessing must be there -- I'm guessing because I don't currently have access to one of these boards that does not have a bracket obscuring where I think the trace most likely is and the manual is no help because it does not show the solder side of the new board; the solder side photo is clearly the old 1.0 version board).
Bob brought over a robot from Richmond today. I used the diagnostic program to look at readings from the sensors. I found the sensors on that robot were saturated as I would expect. The automatic threshold selection option of the diagnostic program will not work with the highly saturated sensors. I tried setting the threshold manually and found with a setting of 35 the line could not be lost between any two sensors but with a setting of 40 it could be. The setting for the calibrated richmond sensors typically is between 450 and 512 and the automatic setting procedure works. (prior to May 14) Solarbotics calls the controller board a brainboard and I have been doing the same. I am considering starting to call it the PIC board or microcontroller board. The new boards could be called isolation boards 1 and 2. It seems two boards will be needed because the connectors to the mainboard need to be in the same relative position as the connectors to the PIC board.
The plan is (was prior to May 14 -- it was noted on May 14 that this would be too much work hardware wise -- see alternet plan May 14 and 18 above -- note as of June 15 this has not yet been implemented) to make the isolation between the main board and the PIC board as compleate as reasonably possible. Motor control outputs will go to optical isolators.The one point where isolation will not be complete is the IR emitters and IR sensors share a common ground. This would not necessary but the sensor board is designed such that there is a copper trace directly between the IR emitter and IR sensor under each IR reflective sensor. The only way to separate these would be to make a new replacement boards. I think we should be able to tolerate the point of contact between the two supply systems without getting Brownout conditions since it will be the only point of contact. I am considering running a ground wire from the sensor board to the PIC board to provide the return path for the sensors.
The five volt supply for the LED's will come from the PIC board independed supply. The supply for the sensor side of the IR refective sensors will also come from the PIC board supply. The IR emitters will be supplied from the main board supply.
I should test the new version of the main board to see if the brownout reset is an issue with it as well. I have been testing on Robot 07 (version 1 robot) because that was the one I was testing on back in 2008.
May 4, 2010
Version 3 of diagnostic program.
- At the time I posted this there are two version of jogx.c and motor_controlx.c. I am still deciding which I want to include and at any given time only one of the two varients of both files should be included in the project workspace.
- the bit rate for the USART is set in sumovore.c. The rate for this version of the program is 115200 bps. (for version 2 only it had been changed to 9600 bps).
main.c menu.c menu.h command_list.h interrupts.c interrups.h process_command.c process_command.h jog1.c jog2.c jog.h robot_diagnostic.ht motor_control1.c motor_control2.c motor_control.h robot_diagnostic3000.hex sensor.c sensor.h sumovore.c sumovore.h