Surveyor Robotics Journal
   



email:
support@surveyor.com

web:
Surveyor Corporation

rss:
Subscribe

Archives
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
Februray 2006
January 2006

       
Sun, 10 Jun 2007

Measuring SRV-1 motor speed using a comparator for Back EMF zero cross detection

We have considered a variety of approaches to adding motor speed measurement to the SRV-1, including optical encoders and hall-effect sensors, but liked the idea of measuring back EMF as an alternative, as it required no additional sensors. Instead, it works on the principle that a motor acts as a generator when free spinning, and the output voltage of this generator is proportional to the speed of the motor.

In the most simple application, bEMF is measured by occasionally turning off a motor to let it free spin, sampling the generated voltage, then turn the motor back on again. The only problem with this approach is that the LPC2106 ARM7 processor has no A/D converters, so there is no easy way to capture the motor voltage level on the SRV-1.

However, there is a solution which uses a simple comparator circuit. If you look at the waveform of the signal from the motor when spinning (without power), there's an AC ripple on top of a DC offset. The DC offset value corresponds to the output voltage of the motor acting as a generator. The AC ripple corresponds to variation in the DC as the active armature coil moves through the magnetic field of the fixed motor magnets.

Because our ARM7 doesn't have an A/D converter, measuring the DC offset isn't possible. However, measuring the "zero crossings" of the AC ripple would be quite useful, as the motor is driving a 100:1 gearbox, and the motor has a 3 poll armature, so we get 600 cycles or 1200 zero-crossings per hub revolution. Because the SRV-1 normally operates at 2-4 hub revolutions per second, it seems that we just need a high pass filter to take out the DC component and band-pass a 1200-2400Hz signal into a comparator. However, in our measurement circuit, we don't want to screw up the PWM drive with the filter components. Also, each comparator (one for each motor) will generate a digital signal that feeds the digital i/o inputs of the ARM7, and we have to be careful to isolate the motor voltage levels from the 3.3v logic levels of the ARM7.

In searching for a solution, I came across a very helpful circuit design website - http://www.discovercircuits.com, and actually found a schematic for a wide band zero cross detector. It uses an LM393 dual comparator ($0.25 part), along with a handful of resistors and a couple of capacitors. The circuit indicated an input frequency range of a few kilohertz to 150kHz, and our signal is in the range of 1200-2400Hz, though it seemed like the input frequency range might be a lot lower, so it seemed worth the effort to build the circuit and then tweak the filter components.



First, a free-standing motor was attached to the circuit and spun by hand. Here are some scope traces that show the results a 2 different motor speeds ...





The results were a lot better than expected. The digital output signal from the comparator is nicely formed, and even the false trigger caused the spike caused by a noisy armature brush on this particular motor (seen every other cycle) can be clearly identified and filtered in software. Actually, it's fortunate that I grabbed a noisy motor, because most of the other motors I checked don't show this brush bounce spike.

Just to check that electrical noise from the motors would not couple back into the 3.3V supply, I connected one of the motors on an SRV-1 to the circuit, and ran tests with the motor power on and off, and didn't see any problems. Here's a schematic of the modified circuit -



The next step is to build a circuit board which interfaces to both motors and mounts on the SRV-1, and then to write some firmware that samples the motor speed through this bEMF mechanism. The bEMF speed has to be actively sampled (this isn't a background task), so this sensor won't accumulate distance traveled (like a rotation counter), but it will be useful for stall detection, closed loop motor control, and odometry estimates.

There is a continuing discussion of this project on the Surveyor Robotics Forum at http://www.surveyor.com/cgi-bin/yabb2/YaBB.pl?num=1181167494

Posted Sun, 10 Jun 2007 14:30 | HTML Link | see additional stories ...



Migrating SRV-1 services from Microsoft Robotics Studio v1.0 to v1.5

This past week, we launched an effort to migrate the SRV-1 services to MSRS 1.5 (CTP May 2007) and encountered a number of problems. We have worked through all of these, and here is a wrap-up of what we found:

The migration process should have been straight-forward. The SRV-1 project files found at http://www.surveyor.com/MSRS.html are first installed in "C:\Microsoft Robotics Studio 1.5 (CTP May 2007)\samples\Platforms\Surveyor\SRV-1". MSRS 1.5 provides a utility called "DssProjectMigration.exe" which is applied to the SRV-1 project from "C:\Microsoft Robotics Studio 1.5 (CTP May 2007)\samples\Platforms\Surveyor\SRV-1". At that point, it should be possible to run "BuildSolution.cmd", but this generates a lot of errors. So resolve these errors, the follow steps are required:
  • After running DssProjectMigration, each of the .csproj files in Srv1, Srv1Controller and Srv1Services must be edited to remove the contents of any <PostBuildEvent> tag, i.e. anything between <PostBuildEvent> and </PostBuildEvent> should be deleted. This is a bug in MSRS that has been flagged, so perhaps it will be corrected by the next version.

  • An environment variable "PLATFORM=MCP" is causing the VC# build errors. Though this appears to be an MSRS bug, we still haven't located where the variable is being set. However, we are able to clear this variable in the MSRS 1.5 environment by typing "set PLATFORM=", and everything compiles cleanly

  • Once compiled, you will likely runtime errors such as *** Error creating service type http://schemas.sharplogic.com/robotics/2006/11/srv1camera.html. Fault:Service not found: http://schemas.sharplogic.com/robotics/2006/11/srv1camera.html [06/04/2007 16:03:32][http://srv1host:50000/constructor/8a6dc584-27f1-48dc-af52-9847b869b2f7]

    You'll need to clear the cache using del ""C:\Microsoft Robotics Studio 1.5 (CTP May 2007)\store"\contractDirectory*.xml". The MSRS cache will be rebuilt and the errors cleared, though this will take a few iterations
After all of this, the SRV-1 services will finally load and seem to be operating, but you will still be unable to communication with the robot. It turns out that the May CTP build had an issue that affected nullable types which were used in SRV-1 services to implement a simple serial bus. The problem has been fixed in MSRS code, and it has been verified that the MSRS group can run the SRV-1 services with a version of MSRS 1.5 that hasn't yet been released, but we'll have to wait for the next MSRS release before we can run the SRV-1 services on version 1.5.

So in the mean time, continue to use the SRV-1 services with MSRS version 1.0. We will post a code update when the corrected version of MSRS 1.5 has been released.

Posted Sun, 10 Jun 2007 14:25 | HTML Link | see additional stories ...