| View previous topic :: View next topic |
| Author |
Message |
kbb
Joined: 01 Jun 2007
Posts: 180
|
 Posted: Mon Nov 26, 2007 10:22 am Post subject: |
 |
|
| bren wrote: | | kbb - Have you solved the brown out problem yet. |
Bren,
Yes the problem appears to be solved and new code and .hex files for the V3 boards have been checked into to the "AVR_OpenServo_V3" and "AVR_OpenServo_V3-dev" parts of the OpenServo CVS.
Reminder: The register layout of the firmware in AVR_OpenServo_V3-dev is different.
For the old V2.1 boards:
I did get occasional brownouts with the old 2.1 board as well (at least for the one I have when used with a low impedance motor). It is possible a similar change is needed for the V2.1 firmware, although the lower CPU clock rate would probably be helping to prevent them.
If I get time I will find reconnect the 2.1 board to a servo and do some tests.
Regards Kevin. |
|
| Back to top |
|
 |
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Wed Nov 28, 2007 12:48 am Post subject: |
|
|
Kevin,
I am looking to implement your strength braking feature, but I am not entirely sure of the theory behind it. The code snippet will hold the brake low for the period of nBrakeCount*10ms after the pwm_stop() function is called. How does this factor into the "strength" of the braking of the servo horn? Once the the enable lines are pulled high to brake, releasing them almost immediately would do the same, would it not?
I can't see the reasoning behind braking for n us/ms after we call stop, can you clarify the reasoning here?
P.S braking now has an enable/disable command to shut the brake off as of my next CVS check-in.
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Wed Nov 28, 2007 1:19 pm Post subject: |
|
|
| ginge wrote: | | I am looking to implement your strength braking feature, but I am not entirely sure of the theory behind it. The code snippet will hold the brake low for the period of nBrakeCount*10ms after the pwm_stop() function is called. How does this factor into the "strength" of the braking of the servo horn? Once the the enable lines are pulled high to brake, releasing them almost immediately would do the same, would it not? |
There was a delay. But...
My untested idea was: if EN_A and EN_B were turned on and off at regular intervals with some sort of duty cycle, that it might result in “controllable braking strength”.
I have spent a few hours testing and fiddling with the idea and you are right: it doesn’t seem to work. No practical control is likely to be achievable implementing it this way. It makes me think that controlling the braking this way may not be possible (if it is it presumably requires the use of the PWM drivers to do it).
Edit: The above definitely seems to produce unsatisfactory results.
Therefore it doesn’t look like controlled braking (or “posable servos”) is simple to implement.
I think the scenario for “posable" or “tactile" servos is likely to be along the lines of a running mode where the PWM is on but the servo position is allowed to drift in a controlled manner: the seek position would be updated to reflect the actual current physical position of the servo.
There seem to be quite a number of possibilities to how this might be achieved. I have no idea which would be the right way, if any, without researching (or more likely trying) them.
For example: if the “force required to try to return the servo back to the seek position is >f (and it isn’t returning?), then alter the seek position by some factor n (or set it to the current position?)”.
Kevin.
Last edited by kbb on Wed Nov 28, 2007 1:48 pm; edited 1 time in total |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Wed Nov 28, 2007 1:45 pm Post subject: |
|
|
| Quote: |
Therefore it doesn’t look like controlled braking (or “posable servos”) is simple to implement.
I think the scenario for “posable" or “tactile" servos is likely to be along the lines of a running mode where the PWM is on but the servo position is allowed to drift in a controlled manner: the seek position would be updated to reflect the actual current physical position of the servo. |
I did some experiments a fair while ago with current sensing and interactive pwm control. The way it worked was to set a mode where the pwm was at a minimum level, and as you twist the horn, the position moved (albeit one or two units) and the current increased. I was trying to balance out the amount of force on the horn with the pwm generated so they correlated with the finger movement. Sort of a follow mode, if you would.
It worked well enough for a training mode, but I did find that each joint needed a different set of parameters to get it to follow right.
I tried to search the forums for the post where I explain what I am was trying to do, but I can't seem to find it.
I guess in short, yes, it is not simple. I find the easiest way around this is to disable the PWM output, and then give the horn a good amount of force.
There must be a fairly simple way around this.
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Wed Nov 28, 2007 1:49 pm Post subject: |
|
|
| Quote: |
Edit: I just realised there is something wrong with the implementation of the above idea in the code, so I will have another go at testing. Failing that... |
pwm_a = 0
pwm_b = 0
caught me out while I was testing it. Hopefully it didn't bite you too hard.
Baz
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Wed Nov 28, 2007 2:57 pm Post subject: |
|
|
| ginge wrote: | | Quote: |
Edit: I just realised there is something wrong with the implementation of the above idea in the code, so I will have another go at testing. Failing that... |
pwm_a = 0
pwm_b = 0
caught me out while I was testing it. Hopefully it didn't bite you too hard. |
Indeed, however, with that accounted for it doesn't work- well there does appear to be “some effect” but nothing useful!
Kevin. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Wed Nov 28, 2007 10:16 pm Post subject: |
|
|
I have made a few changes to the source to eliminate the noise of the motor while idle. As noted above in the thread this was being caused by the back emf sensing being active while not moving. I have rectified this issue.
There are also a couple of new features that I have incorporated including the group general call support, and a few minor touchups here and there.
Group general calls allows for multiple servos to be addressed all at once. For example, if you have a group of 4 servos, you can give 2 of them the group number 1, and the other 2 group 2. Sending a broadcast message of "group 1" will set the first two servos off at the same time, and likewise sending "group 2" message will set the second two servos off. The group call supports up to 254 groups in total, so there are more groups available than servos on a chain.
I have also changed the temperature alert cutoff to a more sane value of 290. I will see how this plays out in the real world, but it is looking like a more realistic figure.
I also managed to give the servo a complete workout on my torture rack, and I am happy to say that Kevin has resolved the brownout issue completely. This long standing annoyance is gone, and we should all thank Kevin for his due diligence in isolating and patching this issue.
As usual these changes are checked into the -dev branch in CVS.
Things left on todo list:-
* Controlled braking? Kevin seems to be looking into this one.
* Integrating the back emf into the PID algorithm.
* Bootloader brownout alert support.
* full shakedown!
* Can anybody add to this list?
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Dec 02, 2007 10:33 pm Post subject: |
|
|
| ginge wrote: | | * Can anybody add to this list? |
It would be nice to fix the version numbering! Currently there are four sets of code (two for each of two hardware types) to support, but three of these share the same “version” when interrogated over I2C. Software identification of the OpenServo “type” and available features would be easier if this wasn't so: Currently we have (device type, subtype, software version major, minor):
OpenServo: 1, 1, 0, 2
OpenServo-dev: 1, 1, 0, 2
OpenServo_V3: 1, 1, 0, 2
OpenServo_V3-dev: 1, 1, 3, 1
Possible suggestion:
The “device type” is used to identify the board type:
1: 2.1 boards
2: V3 boards
(we then also have the continual read of the subtype returns “OpenServo” feature on the later firmware).
The current software major versions could be identified as follows:
0: Original software (i.e. not the bank switched software in the -dev trees, 2.1 board only functionality when used on V3 boards)
3 (as 3 has been used already): The new bank switched software.
In future, minor changes (e.g. adding a single new register/feature) to any software would increment the minor version, major changes would increment the major version.
Updates to any “OpenServo Interface” software would probably require the latest release or development (as desired) software for the respective board to be flashed to the servo.
Kevin. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Mon Dec 03, 2007 1:29 am Post subject: |
|
|
Hi Kevin,
Some of this makes a lot of sense. I will make the appropriate changes in the week, pending resolution of my thoughts below.
As for the maintenance of the multiple branches... I have let Version 2 -dev tree slip as of late. There are many bugs that reared their head during the v3-dev work that need backporting. Personally I am very tempted to drop the v2-dev branch all together so we can concentrate on the newer stuff. Either that or a full merge before dropping v2-dev. Any thoughts on this?
| kbb wrote: |
3 (as 3 has been used already): The new bank switched software.
|
I picked a number that matched the hardware version to differentiate it for "openservointerface" It seemed like a logical step as there are a significant amount of changes compared to the other trees. I was planning on changing the version 2-dev software major to 1 and leave the "vanilla" v2 code at 0. I thought maybe the "vanilla" v3 code should have a minor of 2. This makes it pretty clear which firmware is being used. I am not sure that using banks as a benchmark justifies the v2-dev to have a major of 3. The v3 banks are different in layout to v2-dev (for the moment, its also on the todo list) but also the v3-dev is going to have a LOT more registers crammed in there that are not compatible with the v2 hardware (think PID for velocity)... That is of course unless you think otherwise.
In summary:-
| Code: |
Vanilla V2: Major 0
V2-dev : Major 1
Vanilla V3: Major 2
V3-dev : Major 3
|
The "device type" you propose looks good. In addition, the subtype, or the rolling subtype can be changed at compile time to further identify the servo. For example I use different subtypes for identification of the axis on my robot arm.
| kbb wrote: |
In future, minor changes (e.g. adding a single new register/feature) to any software would increment the minor version, major changes would increment the major version.
|
Absolutely. This is going to be very important for tracking the different features. It is probably not so important while there is a large amount of work going on in v3-dev branch, but once this settles down it would be wise to make sure this happens. I am thinking of setting some dates for a code freeze on the v3-dev so that people can at least start using it without me moving registers on a daily basis 
| kbb wrote: |
Updates to any “OpenServo Interface” software would probably require the latest release or development (as desired) software for the respective board to be flashed to the servo. |
That is probably the cleanest solution, although I now have lookup tables in the code that can translate features based on major and minor versions that in theory will handle any version of the source, assuming we are hot on changing the minor versions.
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
bren
Joined: 01 Jul 2007
Posts: 79
|
| Posted: Sun Jan 06, 2008 8:27 pm Post subject: |
|
|
Hi all
I hope you all had a god holiday.
Now that the port for version 3 seems to be stable could some one please give me the .hex dump for with the boot + main code so that I can reflash my boards. So I can just reflash using my ISPAVR.
Thanks Bren |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Mon Jan 07, 2008 8:36 pm Post subject: |
|
|
Hi Bren,
holidays were good. Plenty of dev work done. I hope yours were as relaxing.
Do you want a single hex with the bootloader and the application firmware, or would you like two images. I am guessing on a singular combined hex file.
Also... did you want a dump of the -dev branch? Best to get it now before I commit the last round of features.
Cheers,
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
bren
Joined: 01 Jul 2007
Posts: 79
|
| Posted: Tue Jan 08, 2008 12:24 am Post subject: |
|
|
Hi Barry
my holiday was good to busy to do any thing on my bot but now things have quietened down will hopefully go full throttle.
I was after the bootloader + main program all in one (so I can just dump in in flash in one shot).
| Quote: | | Also... did you want a dump of the -dev branch? Best to get it now before I commit the last round of features. |
Don't know what you mean by this I just need the latest for the first batch of version 3.
Thanks Bren |
|
| Back to top |
|
|
eric_lmi
Joined: 08 Mar 2007
Posts: 41
|
| Posted: Fri Jan 18, 2008 2:10 pm Post subject: |
|
|
| any update on Back EMF PID control? |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Fri Jan 18, 2008 2:19 pm Post subject: |
|
|
Hi Eric,
I have integrated the EMF into the PID, and it is just undergoing some tests.
The EMF based loop is a tricky beast, as loading of the servo causes the EMF values to be non linear. This basically means that any loading makes the servo bounce, and the PID needs tuning.
While I was at it I wrote a cascaded velocity loop to go along with it, which has added a little more time to the testing period. The cascaded loop is causing some tricky tuning issues, which is making me think I should commit only the EMF based PID loop.
I will commit the current EMF driven PID loop later on today, after I have cleaned up and commented the code.
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
eric_lmi
Joined: 08 Mar 2007
Posts: 41
|
| Posted: Sat Jan 19, 2008 4:20 pm Post subject: |
|
|
| ginge wrote: | Hi Eric,
I have integrated the EMF into the PID, and it is just undergoing some tests.
The EMF based loop is a tricky beast, as loading of the servo causes the EMF values to be non linear. This basically means that any loading makes the servo bounce, and the PID needs tuning.
While I was at it I wrote a cascaded velocity loop to go along with it, which has added a little more time to the testing period. The cascaded loop is causing some tricky tuning issues, which is making me think I should commit only the EMF based PID loop.
I will commit the current EMF driven PID loop later on today, after I have cleaned up and commented the code.
Barry |
do you still using data from Potentiometer? or only EMF? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
