OpenServo.com

ginge · Posted: Fri Sep 21, 2007 12:19 am Post subject:

Last update before sleep.

I have made some major progress getting rid of those erroneous values. It turns out I was waiting too long to sample after enabling the sample switch. After re-reading all of the loong v3 hardware thread I made the mental connection and got it going.

Something is still bothering me though, the screen shot below give more insight into the issue I think may be.

I have artificially extended the coast time to 7ms so you can see the sawtooth that is being generated by the motor.
I think I am sampling at different points on this ramped signal that is causing the remaining issue.I will see if it is something that only happens with the pwm at 100% output, but i suspect it will be tough to eliminate.

Again, Cliff, do you have any insight into this?

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

kbb · Joined: 01 Jun 2007 Posts: 180

Not that I am an expert... But isn’t it bound to be similar to a saw tooth as the coils pass through the fields of the permanent magnets inside the motor? How about taking several samples in the period (after “2” and before “4”) and averaging them?

Kevin.

ginge · Posted: Fri Sep 21, 2007 8:11 am Post subject:

Kevin,

Yes, that is exactly what it is. The period of the saw changes with the speed of the motor, so there is still the possiblity of sampling at the wrong time as the period of each is not known.

I will try it though.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

Cliff · Joined: 23 Jan 2007 Posts: 150 Location: Saratoga, CA

Hi Barry,

Good job, looks like you are making great progress!

Sorry I don't have a lot of time to spend on this right now, but here a few thoughts that might help:

The waveform you are seeing on the motor drift voltage may be from friction in the gear train. If there is a high spot on one of the gears, it could cause slowing and wind-up in the gears behind it - the wind-up could account for the speed up after the high spot is past. This is just a theory, so add a grain of salt. However, if that is the cause of the wave form, I would expect that it is maximized by running the motor unloaded. In general, I would guess that you will see less 'mechanical' noise in the measurements with a loaded motor, although you may see more noise from the motor brushes. If the waveform increase in amplitude, when the motor is loaded, I would then guess it is brush noise.

Recognize that with a loaded motor, the motor will slow faster during the coast period. So, it will be desire-able to sample the BEMF as soon as possible after the negative spike, but it is also important to make sure there is enough delay so the ADC is never exposed to that negative spike. The time delay needed for the negative spike will be a function of the motor inductance and resistance and as such, will be different for different motors. This delay needs to be a parameter with a safe (large) delay as default, but programable - such as with the PID parameters.

In the current design the sample capacitor is 1,000 pF. This capacitor provides some filtering and reduces the the impedance as seen by the ADC. Increasing the value of this capacitor may decrease the noise you are seeing. Five time constants (6.67K x 1,000 pF x 5), for the 1,000 pF capacitor to charge to 99.3%, is 33.4 uS. So, you would want to wait that long, after asserting the sample signal, before sampling with the ADC. If you increase the value of the sample capacitor, you will need to increase that delay. Here is the simplified model I posted earlier, using a 10,000 pF sample capacitor:

Another thing to try would be to de-assert the sample signal before reading with the ADC. This would probably work better with a larger sample capacitor, but it would be easy to try with your current setup. The down side of this is that the capacitor will begin discharging (which is why larger might be better) and result in a slightly lower voltage read, but the up side is that the ADC is decoupled from the motor brushes.

BTW, are you using a capacitor across the motor terminals? If not that may also help reducing brush noise.

Cliff

ginge · Posted: Fri Sep 21, 2007 10:26 am Post subject:

Hi Cliff,

"Sorry I don't have a lot of time to spend on this right now, but here a few thoughts that might help:"

No Problem, I appreciate the advice. I will give changing the sample times a go. I will also try loading the motor to see what difference it makes.

"BTW, are you using a capacitor across the motor terminals? If not that may
also help reducing brush noise."

Yes, I have a 10nF over the terminals.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

ginge · Posted: Sat Sep 22, 2007 12:55 am Post subject:

I would like to congratulate myself on achieving the mission of releasing the magic smoke from a v3. It has been a hard task and... wait... oh shit.

Well, that is going to set me back a week.

Note to self: Never leave a test rig running while absent from its presence.

I have no idea what happened. I came back to the room to find the motor terminals arcing with the motor housing. It looks like one of the FETs or fet driver went, leaving a blue shroud.

Time to order components.

B
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

ginge · Posted: Mon Sep 24, 2007 12:23 am Post subject:

A few traces have lifted under the high currents. It is definitely beyond economical repair. This is all on hold until I can buy another v3 when Jay is ready.

I think I will start coding up the framework for continuous rotation based on velocity estimation while the new boards arrive.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

linuxguy · Joined: 16 Oct 2006 Posts: 120 Location: Beaverton, OR

ginge · Posted: Mon Sep 24, 2007 8:58 am Post subject:

That is the plan.

It will be less than accurate for extremely sensitive applications, but it will at least allow for simple velocity integrated estimation of position. (i.e. number or turns of the motor)

I don't know how well it will work out in the real world, but it is fairly trivial to get it going, so we might as well give it a go.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

Cliff · Joined: 23 Jan 2007 Posts: 150 Location: Saratoga, CA

Hi Barry,

ginge · Posted: Mon Sep 24, 2007 4:56 pm Post subject:

Hi Cliff,

I think you are right. In the near future I will be patching the v2-dev branch into a v3-dev branch to tie up the features that we have been playing around with. These include a PWM throttle for over current, and this would be the most realistic solution for managing such problems.

As it stands, we have plenty of time to sample the position, current and temperature in the time it takes for the spike to pass. All I need do is apply the information to the PWM transformation routine.

I was thinking of a two level approach to this. First it throttles the PWM until it hits a set low limit of the throttle value (stops audible noise), If it looks like the PWM still needs throttling, and we are at this throttle limit already, then I think it best that PWM is switched off entirely. The interrupt pin can then be used to signal a hard failure.

Does anybody have any thoughts on this?

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

ginge · Posted: Wed Oct 17, 2007 6:11 pm Post subject:

In the absence of any hardware I have started porting the features from the v2 dev tree into the new v3 firmware.

I have also started to make some tentative PID loops that integrate the new emf velocity estimations. One thing that did strike me while playing around with all of this stuff is that the back EMF velocity value changes with the loading of the servo. How this will affect the actual PID loop is not going to be known until I try it. We might be able to use a position / time integrator along with the back EMF to get a more sane reading on this one though.

I also rigged up some hardware to test back EMF in a little more detail in order to try and sort out the odd waveforms that were appearing in previous screenshots. I think I have a workaround that involves taking 7 samples in rapid succession and averaging them out. This seems to work reasonably well on the test rig, and hopefully it will work pretty well for the v3.

I also think I have everything in place for continuous rotation to work. There are still a few things that I will need to think about, but the basics are in.

There is something that is still bothering me about the brownouts that seem to occur far too often. I have coded up some really simple soft start routines that ramp the PWM from 0 to x over a number of steps, which seems to sort out that little bug. I would like to get some feedback as to my approach this "hack" to make certain that it would be acceptable for general use, and I am not overlooking a really obvious fix.

In other news, the laser cut frames have arrived for my biped, and I look forward to putting shiny new V3 boards in there Smile

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

bren · Joined: 01 Jul 2007 Posts: 79

Hi All

I remember reading on one of these threads about loads the .hex files on to the site. Has this been done is there anywhere I can download the .hex files for the version 3 board. I know I could download the .c files and compile them my self but as I'm just starting out in the openservo project I want to keep the number of steps to a minimum so that I can get up and running as fast as possible.

Thanks Bren

ginge · Posted: Mon Nov 12, 2007 12:11 pm Post subject:

Hi Bren,

I have checked the hex file into CVS. You can get it with a full checkout, or using the viewCVS

OpenServo ViewCVS

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

bren · Joined: 01 Jul 2007 Posts: 79

Hi Barry

Thanks yet again for your fast reply today. I have some more Questions (Sorry). I've successfully used the above file and have managed to get the servo's back in action Laughing

. I couldn't use you app to do it so I reflushed the boards using my AVRISP + AVR Studios. So the question is have I just written over the bootloader with the main code!

If so is there away to flush the board with the code and the bootlaoder at the same time or using AVR studio set the start address. Sorry for the lack of experiance I've only just received the AVRISP for this project. As I would much prefer in the future to use you app to manage the PID and the other settings when the robot is rebuilt.

Thanks Bren