April 18, 2002

Hardware (Randall)

The platform is nearly complete.  The aluminum has be bolted together, the  motors mounted, the batteries mounted, the electronics mounted, wire harness has been created and installed, and charging circuitry has been completed.  All of the electronics are on board and working, H bridges are mounted, and the vehicle does move to commands given.  The control system needs some fine tuning but it does work.  Also one of the casters is rubbing, and that will be taken care of along with fixing the levelness of it.  Currently the vehicle is too level and traction is being lost on the not-so-even Jobst halls.  One of the bearing will be shaved down to allow for some “slop” in the casters, and more traction along with better handling of non-ideal surfaces.

The CPLD program was divided onto two different CPLDs since it does not fit on one.  Eight registers are still being used, but now there are 4 on each CPLD.  Both have been interfaced to the EMAC and have been providing accurate feedback.  Calibration will be done starting today, to correct the accuracy of distance and angle calculations.  Currently a command to turn 360degrees, yields 225degrees.  This is a minor problem that can easily be fixed with an update to the CPLDs.

The EXPO has also been completed, with a second place finish which is good.  The display board is done and the presentation for the second practice session has also been revised to bring it very near to ready for the final presentation.  The abstract has been written and submitted to Dr. Dempsey also.

Software (Rob)

TBA

 

April 4, 2002

Hardware (Randall)

The platform has been cut, milled and folded.  It is currently being painted to give it a nice finished look.  Starting on Monday the assembly will commence by mounting the motors and the batteries along with the wheels and the casters.  Most of this is straight forward, except the drive wheels which will require some custom parts to mount.

Also the CPLD was updated to fix some errors in the counting and to create a distance code that counts in both meters and centimeters to make it easier to program than in centimeters only.  The angle code still does not fit, but work has begun on starting to shrink that down.  After the vehicle is assembled, the angle code will be worked on.  Currently there is a need for 12 more macro cells to fit angle code on.

The precision of the angle code has been increased to 1degree which is more accurate the 5degrees because of the count.  Also the accuracy of the distance code and the angle code was determined to be 0.007% error and 0.03% error respectively.  This corresponds to about 6.7mm per 100meters and 0.1degree per 360.  the accuracy will change when the actual platform is tested due to things like slip and tolerances of the width of the vehicle and while circumference, but is should still be very good and less that 0.5%.

Software (Rob)

I soldered 2 new H-bridges while wearing dress clothing.  I also played around with the control system.  Other than that, I helped Randall with the platform.  Basically, I took a week off because everything kept dieing, or subsystems suddenly stopped working and I got sick of fixing it.  I think our project is temperature sensitive or maybe it only works during the equinox.  Once we get the platform built, and we connect everything up on the platform, I hope to finish the rest of the software.  I hope to have the vehicle doing some type of command by the EXPO.  Other than that, I hope a meteorite falls from the sky and lands on the EMAC/CPLD/H-Bridge system, and then I hope it bounces a few times and takes out my car too.  I love insurance claims, but I hate my controls take home test.  I also received a 97% on my presentation, but Randall received a 99%, so I am mad.  Is it to late to switch to BCS, or EET???

 

March 14, 2002

Hardware (Randall)

The VHDL program has been loaded to the CPLD successfully and has also been interfaced to the microprocessor successfully.  There were a few errors in the code that were fixed, mainly that if there was no frequency in, there would still be a frequency read by the microprocessor, and the 16bit distance counter would work only in 8bit (turned out to be a typo, 256 was there instead of 255).

Both motors can be controlled very well with the CPLD as the feedback path, and much of the encoder noise has disappeared.  The distance code works, but one of the motors is introducing some noise that is causing it to randomly reset the count.

The platform design has been completed; it is an octagon shape which will be folded up on four sides.  These will provide a place for the top piece to be attached.  The top piece will wrap around the outside of the wheels to provide more support and avoid extra stress on the motor shafts.  All of the electronics will be attached to the top piece with stand offs.  The batteries will be stored between the two plates with the motors.  Two casters will be attached on the sides that are not housing wheels.  This will be assembled using sheet aluminum and will be screwed together. Assembly will start on Thursday March 28th.  The hope is to complete it by Thursday April 4th.

 Software (Rob)

The CPLD has been interfaced to the EMAC.  All data transfer seems to be working well.  There are still a few bugs associated with the reset of the distance calculation and frequency calculations.  Some of the issues may be noise related.  I began to write code for controlling the motors when a “Forward X” command is given.  So far, the motors will turn on, and the data from the CPLD is continuously monitored.  When the distance is within a specific range of the final distance, the motor speed is set to control signal 10, and the motors slowly approach the desired distance.  Once the desired distance is reached, the motors turn off.  The program can distinguish between both motors, so each motor must reach the desired distance, and each motor is individually controlled by the program.  Since the motors do not run identically, each must have individual control.  The distance feedback will also be used to speed up the slower motor, thus making the control system better, thus keeping the motor shafts perfectly lined up.

 

March 14, 2002

Hardware (Randall)

The VHDL program was written.  This consists of a frequency counter that scales 0 to 42Khz to 0 to 255 and then stores it in a register that can be accessed by the micro.  This register is accessed through the main program that decodes three address lines along with read bar and the external IO select line.  The main program also takes care of tri stating the bus.  The entire program was put on to a CPLD since that is what can be compiled and tested on my workstation so the software can be developed with out having to be in lab.  However the program would also work on an FPGA if needed.

Along with the frequency counting program that replaces the freq to voltage converters, the is a distance code that calculates distance.  This is done by toggling a micro port bit which enables a count.  That count increments a register on the CPLD that is then read by the micro.  It is actually two registers since it is a 16 bit count.  This is in 1cm increments giving a max distance per command of 65,536cm which should suffice for any application.  The angle code was also started and will do the same type of incrementing as the distance code but will be calibrated every 5 degrees.

The freq count code was tested and seemed to work well, however the address and interface code seems to have some problems.  This will be addressed on Thursday and should be corrected at that time.  The distance code has not been tested yet nor has the angle code both should be done Thursday also.  Once tested and working, the freq to voltage converter will be replaced and work on the platform will be finished.

The platform design has been started, more information on the assembly and construction of it will be gathered and construction is hoped to be completed the week after break.  This should be about the time that the whole vehicle can be assembled and more through testing can be done.  The noise issue is however still prevalent.

Software (Rob)

This week, I spent several hours with Randall working on the FPGA planning and design.  We came up with a solid plan, which should enable us to make huge headway once the FPGA is interfaced to the EMAC.  Our current design will simultaneously calculate both motor speeds and distance traveled, and possibly calculate the degrees turned.  The EMAC simply grabs the data from the FPGA through the bus interface.  Each piece of information will be associated with a specific address in memory.  Simply put, the FPGA will act like a memory device and all information calculated will be accessible as a memory location in the assembly program.  This will allow for the use of simple commands to access the data, such as: "MOV A, Address."

 

March 7, 2002

Hardware (Randall)

The last bit of noise problems that we have occurring has to do with the brushes of the motor at low PWM signals.  These brush bounces are causing voltage spikes to exceed the 55volt rating of the H bridges and could cause permanent damage to the H bridges if this is not taken care of.  This information was learned from Professor Gutschlag, who also suggested that a snubber circuit would cure these ailments.  After spending all of Tuesday and a good amount of last Thursday on the snubber design and implementation, we have yet to get it to operate as intended and remove the noise caused by the brush bounce.  This problem has consumed a large amount of time and will be continually worked with in order to avoid H bridge damage again, but work will also be done on the rest of the project to avoid falling behind even more.

The FPGA that will be replacing the analog circuitry will be coded and interfaced to the EMAC board.  This will be done by putting it on the BUS and setting it up to have 8 registers starting at memory location 7000.  The FPGA will consist of 4 counters to start with, 2 that will count the frequency and 2 that will do distance calculation.  Also the platform design will be done by next week, and the assembly logistics worked out.

 

Software (Rob)

This week, I work with Randall on the snubber circuitry.  We also met with Professor Gutschlag several times.  However, the snubber circuit had little effect on the H-bridge output. 

We also discussed the functionality of the FPGA design.  We also planned out and calculated some ratios we are going to use in the FPGA design. We related encoder-wheel-pulses to the exact distance traveled by the wheels of the vehicle.  Once the ratios are found, they can be used in the pulse counting functions of the FPGA.  The FPGA will be interfaced to the EMAC data bus, and appropriate address lines will be used to control the data flow.

 

February 28, 2002

Hardware (Randall)

The noise problems of the past have been isolated and mostly taken care of.  By adding filtration capacitors to the H bridge power supplies, the large changing current spike was removed.  Design for a snubber circuit is in the works that will take care of noise from the brushes of the motor.  Also the new H bridges arrived and have been installed, which cured even more noise problems and allows for the direction function to work again.  Rewiring the work station area has also yielded better results.

The frequency to voltage chips will also soon be replaced with an FPGA that will allow the inaccuracies and drift of the analog signal to be removed.  This is a more direct implementation and should yield more accuracy and an overall better control system.  The current setup will remain for test purposes of the code and will be replaced when the FPGA design is finalized and tested.

Software (Rob)

This week, the software has not been changed.  I spent the entire week helping Randall with the hardware.  We have a serious noise problem caused by the brushes on the DC motor.  After consulting with Professor Gutschlag, we have determined the problem and solution.  We must use a snubber circuit on the output of the H-Bridge.  I also learned how to solder this week! 

We have also decided to scrap the F/V converters and use a FPGA system interfaced to the micro through the bus.  The FPGA will simulate a memory device, so the data from it can be grabbed and used very easily.  The FPGA will provide an 8 bit resolution frequency count for motor 1 and 2.

The FPGA will be capable of providing both frequencies through the bus interface, and the microcontroller will select which frequency it needs.  The FPGA will also generate a pulse corresponding to 1 CM of wheel travel, thus providing position feedback.

Once again, the project has had a metamorphosis into a new creature.  However, with our new approach, the project will be very robust, and provide a great starting point for future projects.

 

February 21, 2002

Hardware (Randall)

The noise problems of the past have been isolated and mostly taken care of.  By adding filtration capacitors to the H bridge power supplies, the large changing current spike was removed.  Design for a snubber circuit is in the works that will take care of noise from the brushes of the motor.  Also the new H bridges arrived and have been installed, which cured even more noise problems and allows for the direction function to work again.  Rewiring the work station area has also yielded better results.

The frequency to voltage chips will also soon be replaced with an FPGA that will allow the inaccuracies and drift of the analog signal to be removed.  This is a more direct implementation and should yield more accuracy and an overall better control system.  The current setup will remain for test purposes of the code and will be replaced when the FPGA design is finalized and tested.

Software (Rob)

This week, the software has not been changed.  I spent the entire week helping Randall with the hardware.  We have a serious noise problem caused by the brushes on the DC motor.  After consulting with Professor Gutschlag, we have determined the problem and solution.  We must use a snubber circuit on the output of the H-Bridge.  I also learned how to solder this week! 

We have also decided to scrap the F/V converters and use a FPGA system interfaced to the micro through the bus.  The FPGA will simulate a memory device, so the data from it can be grabbed and used very easily.  The FPGA will provide an 8 bit resolution frequency count for motor 1 and 2.

The FPGA will be capable of providing both frequencies through the bus interface, and the microcontroller will select which frequency it needs.  The FPGA will also generate a pulse corresponding to 1 CM of wheel travel, thus providing position feedback.

Once again, the project has had a metamorphosis into a new creature.  However, with our new approach, the project will be very robust, and provide a great starting point for future projects.

 

February 14, 2002

Hardware (Randall)

Noise Analysis of the hardware circuits was done to try and isolate along with reduce noise.  It was found that both ground and power lines were noisy, and that the PWM signal was part of that noise.  Through ground isolation and adding filtering capacitors, the noise was reduced, but some still remains.  Both H bridges and freq to voltage converters are working well, and with almost no error between the two circuits.

Work has begun on the PCB using Pspice.  Simulation libraries containing both the H Bridge and Frequency to voltage converters were found, and work on familiarization with the software has begun.  A complete simulation is also in the works.

Software (Rob)

This week, I added more code to the KEYPAD routine to allow for more testing functionality of the motors.  I also spent some time making measurements on the two motors to verify the operation of the control system.  I gave both motors an equal control signal then measured each encoder frequency along with each output of frequency to voltage converters.  I started researching the use of PLD's for the project.  I hope to start programming a PLD next week and integrating it into the system.  The PLD will measure distance traveled.

 

February 7, 2002

Hardware (Randall)

The design of the H bridge circuitry is complete and has been built and tested.  Currently both H bridge circuits are build but one of the H bridges had failed, should have it replaced early this week so that the software testing can continue.  The DC/DC voltage converter has also been tested and works fine.

There is a current problem of high levels of noise in the system.  This noise is at the same frequency as the PWM and is believed to be introduced by the EMAC board.  Diagnostics into why this is happening and how to solve it will be done in the following days.  Also a determination of what type of FPGA/CPLD will be needed is to be determined, so that the circuit board layout can begin this week.

 Software (Rob)

This week, I was able to write the code allowing for direction control of the motors.   I also added code for individual speed control for each motor.  We were also able to connect both motors to the EMAC once we were given the other H-Bridge.  A few simple tests were performed to see if the motors were synchronized, but they were not.   It was later discovered that the new H-bridge was faulty.  The 2nd motor would not achieve full speed if given 100% PWM.  So, all tests are now negligible until a new h-bridge is used.  We hope to have a working dual-motor system after Thursday.  

 

January 31, 2002

Hardware (Randall)

So far the time line has been created and a layout of milestones has been mapped.  This is illustrated on page two.   As for the hardware, the frequency to voltage converters have been designed and tested to handle the new input from the motor encoder wheels.  Since these motors are for a different voltage and different series, the output is now 1Khz to 40Khz, instead of 1Khz to 15Khz.  The two voltage to frequency converters have each been carefully designed so that the same input generates the same output, the tolerance being the error from the A to D port on the EMAC.  So far most of the usable range matches between the two converters (that range being 6Khz to 36Khz), but at the high end an error of one bit is still evident.  This should not be a problem being that the max speed is not going to be used very often, only a test when the vehicle is built will determine if this is going to have a significant effect on the accuracy.

The next step will be to finalize the design for the H bridge circuit.  This will be designed and built on Jan 31, and Feb 5, the design should be finalized by Feb 7, and testing should begin with the control system and the H Bridge/Frequency to Voltage converters.  The rest of the power system will be worked with following completion of the H Bridge Design.  This should provide Rob with the hardware to begin refinement of the code.

Software (Rob)

The software has made several advances this week.  The conversion from timer 0 PWM creation to timer 2 PWM creation was made.  Switching to timer 2 allows for the creation of three PWM signals from one timer.  Timer 2 does not require a continuous program to create the PWM signals, so several pages of assembly code were removed.   Using timer 2 also solves the problem encountered when using timer 1 to create a 2nd PWM signal.  Timer 1 provides communication between the Kile Software and EMAC board.  By using timer 2, timer 1 is still free to provide the communication and debugging tools.  Once the software was converted to timer 2, code was added to generate 2 PWM signals.

The software can now provide two PWM signals to control 2 motors.  The code has been checked and debugged by using 2 power supplies to simulate the two separate motor-speed signals from the frequency to voltage converters.  However, there is still a persistent bug in the software, and I am working feverishly to find it.  The details are as follows:

  • Both PWM signals work, and track the signal obtained from the frequency to voltage converter.

  • The A/D port correctly samples both feedback signals

  • The display shows the current specified speed and measured speed for both motors

  • Both Frequency to Voltage converters were calibrated using the onboard A/D port, while the results were sent to the display for comparison.  If both frequency to voltage converters were given the same input, both outputs from had to match on the display for the system to function properly.  After some tweaking, the results were matched.

The PWM signal has an error where the PWM tracking suddenly freezes when a certain combination of measured and specified signals are obtained.  (This is the only known error)

October 30, 2001

  • Rob and Randall finished the six week Senior Mini Project today.  They now have sufficient insight in the areas of power electronics and assembly language programming.   The mini project was a "DC Motor Controler."  Basically, it was the senior project without feedback. 
  • Block diagrams and flow charts were made at the request of Dr. Huggins and Dr. Anakwa.  All block diagrams and flow charts can be found on this web site.

October 28, 2001

  • Rob designed and published the web site.

October 25, 2001

  • Rob and Randall met in Jobst hall to use a wall sized dry erase board.  Several hours were spent planning, drawing block diagrams, and consulting with Dr. Huggins.   Some of the more detailed aspects of the project were drawn out and new block diagrams were made.  Most importantly, the design team came to an agreement in how to control the robotic platform and divide labor.  Based on the assumption, "a closed loop system will reduce non-linear affects of each motor," the decision was made to treat each motor as a single entity and equal of the other.  Simply put, the motors are separate but equal.  This will allow the engineers to design the system for one motor, then make a copy of the design for the other motor.  This assumption is only valid in a closed loop system, utilizing feedback to compensate for the non-linear effects.