| View previous topic :: View next topic |
| Author |
Message |
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
 Posted: Mon Nov 12, 2007 7:27 pm Post subject: |
 |
|
Hi Bren,
Yes, You almost certainly have wiped the bootloader off. If you don't intend to mess with the firmware, then this is OK. If you want to flash the bootloade r and application at the same time, you will need to either use my app (and flash it within the first 3 seconds Ignoring the write fail) or wait until I get some more v3 boards where I can read the while thing off end to end for you.
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 14, 2007 3:39 pm Post subject: |
|
|
I just received the OpenServos from Jay, and they all have this same bootloader problem. I will chat to Jay about the version of the bootloader shipped, but there are other bootloader related issue I need to resolve first.
The main problem I am seeing on the V3 is the bootloader timing out waaaay too fast. Unless you are the flash, there is no chance of recovering from a bad application flash, as the bootloader times out after <0.5 seconds.
I am still not sure how we should handle the bootloader stage. Should it be on a timer, or should it only boot with manual intervention, such as a jumpered pins on the connector?
Anyway, those issues aside, the V3 dev firmware flashed and ran first time and is nearly operational.
With the help of Kevin (kbb) we should have some brownout free operation in the near future.
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
bren
Joined: 01 Jul 2007
Posts: 79
|
| Posted: Wed Nov 14, 2007 5:42 pm Post subject: |
|
|
Good to hear.
I've been doing some more fiddling today with the boards. I also get the brown out issue. I've tried changing the fuzes so that Brown out detection is turned off. To describe the problem I'm having is the servo will 50% reset it self e.g. the servo horn will turn a little bit then stop turn a little then stop in a 2 second beat and will appear as 0x7F. The other 50% of the time it will load normally and I can use you app to change the servo position and it will go there nicely then change the position a couple of more times and it will reset it self and do the random turning.
I'm running it at 7 - 12V from a very good bench power supply with now load so it shouldn't be the power supply! I've tried with different value capators across the terminal but this seams to have no affect!
Will carry on tomorrow.
Bren |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Wed Nov 14, 2007 5:58 pm Post subject: |
|
|
| bren wrote: | | Will carry on tomorrow. |
I believe, at the moment, that there isn't any point in fiddling with the power supplies, batteries, capacitors or fatter wire- it appears to be a "software issue".
I have applied some "quick and dirty" fixes to the PWM code, which I have passed on to Barry, this at least seems to make my OpenServi-MG995 test combination totally stable (although it still needs a bit of PID tuning, e.g. to prevent overshoot).
I will be looking at the issues later in the week to see of I can tighten things up and do some harsh testing. I think Barry will also be looking at the problem.
Kevin. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Wed Nov 14, 2007 8:57 pm Post subject: |
|
|
| ginge wrote: | | I just received the OpenServos from Jay, and they all have this same bootloader problem. I will chat to Jay about the version of the bootloader shipped, but there are other bootloader related issue I need to resolve first. |
More of a note for others: As an alternative to the STK500, etc., I am using an AVR ISP Downloader together with PonyProg on a Windows PC to program the bootloader into the V3 boards Jay sent me. It works very well.
About the AVR ISP Downloader (and similar): you need to provide it with 5V, a resistor and a LED to connect it directly to the OpenServo: it should noy be being connected to your I2C host at the same time.
| ginge wrote: | | The main problem I am seeing on the V3 is the bootloader timing out waaaay too fast. Unless you are the flash, there is no chance of recovering from a bad application flash, as the bootloader times out after <0.5 seconds. |
I have found that with the Dimax/Diolan U2C12 USB-I2C/SPI/GPIO I can run both “OpenServo Test” (openservointerface.exe) and TWIBootProg at the same time, press “Reboot” on“OpenServo Test” and then the “Program it” button on TWIBootProg, thus a short start up time does not matter. I don’t have an OSIF, so I don’t know if its bus can be shared out in the same way.
With a very short start-up time for the bootloader, say 250ms, one could have a “flash my OpenServo” application that is intelligent enough to go for the bootloader if it is there, wait for it appear (user applying power) or simply resets the OpenServo of your choice and wait for the it (options possibly needed to say what to do). One could even add a “jump to bootloader and stay there” command
I don't think anything more complex is necessary.
| ginge wrote: | | I am still not sure how we should handle the bootloader stage. Should it be on a timer, or should it only boot with manual intervention, such as a jumpered pins on the connector? |
Jumpering a pin on the connector seems like a good option, it would provide a “rescue me” option in case of a bad firmware upload. It could be backed up by the “jump to bootloader and stay there” command
so that “in application” programming can still be achieved (e.g. so that you can reprogram all the servos in the biped/hexapod/whatever without having to unplug and replug all the leads or without needing to use the special jumpered lead)- luxury!
Kevin.
Edit history: Added note about 5V etc for the AVR ISP Downloader.
Last edited by kbb on Fri Nov 16, 2007 12:35 am; edited 2 times in total |
|
| Back to top |
|
|
bren
Joined: 01 Jul 2007
Posts: 79
|
| Posted: Wed Nov 14, 2007 9:24 pm Post subject: |
|
|
| Quote: | | I am still not sure how we should handle the bootloader stage. Should it be on a timer, or should it only boot with manual intervention, such as a jumpered pins on the connector? |
A 1 second bootloader would be fine. If the app can reset the board, then it can then just upload the new file. As far as a jumper goes, I not think we need it. I've made up a cable and can just plug my AVRISP directly if something went really wrong.
Bren |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Thu Nov 15, 2007 3:35 pm Post subject: |
|
|
Hi all,
My boards have arrived, and are up and running. So, update time! There is quite a lot to get through this time.
While waiting for the boards I ported all of the v2 -dev features over to the new v3 hardware...
- Paged Banks are in. There are 3 banks to use for storage and configuration on the V3. Each bank is selectable by writing the page number to a register.
*Page 1 holds and alerts and errors, back emf data and other informational output. This bank is read only.
*Page 2 has all of the configuration variables. Lots of config parameters have moved from standard registers.
*Page 3 has the redirection register in it. More on this another time 
- Alerts are in and working. Alerts serve to warn you when there is a problem, over current over voltage over temperature. etc. The only useful thing that I have done with the alert functions is to crudely throttle pwm when current is over its limit.
- Back EMF is in and working. The back emf speed sensing is now working well, giving nice results. I will post up some values and graphs of the captured speed data vs actual speed. Back emf integration is not fully complete as yet, and the values are only exposed through a register at the moment. I will be factoring this into a new PID algorithm with speed feedforward in the coming weeks. There are several back emf related configuration variables available to tweak the sensor data and delay times.
- PWM. There are 2 major changes to the PWM routines. Kevin (kbb) has supplied a working fix for the brownout problem in the guise of some carefully placed delays which stop "crowbarring" of the FETs.
I have also put in place a configuration variable that scales the PWM output up to 100% of normal. If you run from a 7.2v battery, and the motor is rated at 6v, you scale to 83% PWM to reduce the output voltage. You can change this value on the fly for a short "turbo mode".
- Some register locations are changed.
- The main.c main loop now waits for a clock heartbeat before kicking off any actions, decoupling it away from the ADC clocks. This allows us to sample the ADC in the backemf stop period for cleaner figures.
- Rolling subtype support is in. If you enable this feature, reading the subtype register over and over returns the ascii "OpenServo"
- Bridge braking. The bridge is braked by default now by clamping the fets together by shorting the motor. Do we want to be able to turn the hardware brake off? If yes then we need another config register.
Known issues
- EEProm saving is broken because of the new banks It will save the standard registers with a nice CRC, but the banks are not CRC'd yet.
- Some variable defaults are not set. Notably the alert functions. I have not decided if these should all start at 0 (disabled) or if we are better with safe defaults. What is a safe default for the temperature? At the moment the temperature reads 250 when it is very hot. The scale of the temperature sensor is not particularly great.
- PWM jitters. When the servo is idling (stopped) There seems to be a very small pwm signal being generated that makes the motor whine because of the low ratio. This needs to be clipped to 0 at a set level.
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: Thu Nov 15, 2007 3:41 pm Post subject: |
|
|
| Quote: |
I have found that with the Dimax/Diolan U2C12 USB-I2C/SPI/GPIO I can run both “OpenServo Test” (openservointerface.exe) and TWIBootProg at the same time, press “Reboot” on“OpenServo Test” and then the “Program it” button on TWIBootProg, thus a short start up time does not matter. I don’t have an OSIF, so I don’t know if its bus can be shared out in the same way. |
In short, yes.
| Quote: | | With a very short start-up time for the bootloader, say 250ms, one could have a “flash my OpenServo” application that is intelligent enough to go for the bootloader if it is there, wait for it appear (user applying power) or simply resets the OpenServo of your choice and wait for the it (options possibly needed to say what to do). One could even add a “jump to bootloader and stay there” command |
The OSIF will send the reboot command to an OpenServo before trying to flash it, immediately after reboot it starts the flash. This would fit with your super short bootloader idea. The OpenServo itself will stay in the bootloader if you read or write to it at 7f. If you read one byte at 0x?? you would be locked in the bootloader until you write 0xffff to jump to the application (or power cycled). The OSIF also does this.
Any chance of getting hold of your dimax mods to the OpenServo Test application, I will merge and put into CVS for everyone else to use.
Cheers,
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Thu Nov 15, 2007 11:22 pm Post subject: |
|
|
| ginge wrote: | | Bridge braking. The bridge is braked by default now by clamping the fets together by shorting the motor. Do we want to be able to turn the hardware brake off? If yes then we need another config register. |
Yes, this would be a useful feature and it would seem easy to implement. At the moment, once you have run the servo, even if you turn PWM off, the motor is still braked. This makes it hard to manually move the servo horn- why would one want to do this? To allow you to move things whilst reading back the servo positions for the purposes of “motion capture”. It had also occurred to me that we could have “pulsed” breaking so that the servos are easy to move without being “too loose”.
| ginge wrote: | | PWM jitters. When the servo is idling (stopped) There seems to be a very small pwm signal being generated that makes the motor whine because of the low ratio. This needs to be clipped to 0 at a set level. |
Yes, there is sometimes a very slight jitter with the MG995 servo I am testing with- but it doesn't seem too bad. It is sometimes seen as a one point change on the servo position (i.e. 400 to 399 and back again). Sometimes you can start it by touching the horn of the servo when it has no load- then there is a little jitter and a high pitched whine, then it settles back down again. I was thinking it might be noise in the system (ADC issues) or a "problem" with the pot.
Kevin. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Fri Nov 16, 2007 10:35 pm Post subject: |
|
|
| ginge wrote: | | Any chance of getting hold of your dimax mods to the OpenServo Test application, I will merge and put into CVS for everyone else to use. |
Soon!
Kevin. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Sun Nov 25, 2007 3:05 pm Post subject: |
|
|
| kbb wrote: |
Yes, this would be a useful feature and it would seem easy to implement. At the moment, once you have run the servo, even if you turn PWM off, the motor is still braked. This makes it hard to manually move the servo horn- why would one want to do this? To allow you to move things whilst reading back the servo positions for the purposes of “motion capture”. |
Would we be better off unlocking the brake when PWM is disabled, or would we prefer an actual brake register?
| ginge wrote: |
Yes, there is sometimes a very slight jitter with the MG995 servo I am testing with- but it doesn't seem too bad. It is sometimes seen as a one point change on the servo position (i.e. 400 to 399 and back again). Sometimes you can start it by touching the horn of the servo when it has no load- then there is a little jitter and a high pitched whine, then it settles back down again. I was thinking it might be noise in the system (ADC issues) or a "problem" with the pot.
|
I have looked into this one a with a little more detail. It would appear that the Back emf sensing combined with the PWM scaling produces long off times. If I disable the back emf functions it moves away from the audible range. How we should handle this is a difficult question. We need the back emf for the speed sensing, but the values returned while it is whining are nearly useless. The easy solution would be to disable backemf when the position is idling. It does this to a certain extent at the moment, but I think we need to go further.
As a side note, Kevin has checked in a more refined version of the pwm.c modifications that stop the brownouts. There is also a hex file in CVS should anyone want to play with the new features. Please remember the layout of the registers is different, and that existing programs will not function without modification. We will have some abstraction layers for this fairly soon, from both Kevin (which sounds like it is going to kick bottom) to my simpler implementation.
There are also a few other fixes here and there, notably the eeprom saving functions are working again, and this time with a CRC to verify the data. I had a request from a friend that his servo reset to a known position on powerup, can anyone see the merit in this feature? If so I will add the patch set in. It would be of no use to me, and my robots would break horribly if they were ever reset to a state that the host doesnt know about until it is too late.
Bootloader:
At the moment, upon poweron the bootloader sits and waits for a few seconds before powering up the application. Something that crossed my mind was the reset vector register, which holds the value for the source of the reset, can be used to determine if we hit a brownout. If that is the case, I think it should jump directly to the application without waiting for a timeout. Any thoughts on that one?
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Nov 25, 2007 9:36 pm Post subject: |
|
|
| ginge wrote: | | Would we be better off unlocking the brake when PWM is disabled, or would we prefer an actual brake register? |
I imagine this could be held as two states controlled by four commands “PWM off/on” and “Brake off/on”: that would give the user most control. Sending the relevant commands together, if needed, would likely be just as effective as any other method of controlling the two flags/registers. A “brake register” that provides control over how “hard” the braking is (0=none, 255=full on)?
| ginge wrote: | | I had a request from a friend that his servo reset to a known position on powerup, can anyone see the merit in this feature? |
I think it would be a bad thing to have on by default for most people. It could be implemented as a feature that the end user could enable if wanted. I can only see that it would be useful if there is no master to control the servo(s)!
| ginge wrote: | | ... The easy solution would be to disable backemf when the position is idling. It does this to a certain extent at the moment, but I think we need to go further. |
Is one possible solution to trigger back EMF measurements only when the position appears to be changing and is then stopped once things have “settled”?
| ginge wrote: | | Bootloader: ... if we hit a brownout. If that is the case, I think it should jump directly to the application without waiting for a timeout. Any thoughts on that one? |
As a brownout indicates a “problem”, maybe the bootloader could jump directly to the OpenServo application firmware, which then enters an “alert” state, the same as it does when the over temperature condition is detected (new V3 firmware feature). The controlling application would then need to do something about the situation- just as it would have to do when the temperature alert is triggered.
Kevin. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Sun Nov 25, 2007 11:07 pm Post subject: |
|
|
Hi Kevin,
| kbb wrote: |
A “brake register” that provides control over how “hard” the braking is (0=none, 255=full on)?
|
An interesting idea. I would have to think about how that one would work, but I do like it. I worry about having a separate command for the brake, as setting it while the servo is in motion would cause exploded FETs. Your "brake register" along with a little bit of logic would be a good way around that issue.
| kbb wrote: | | I can only see that it would be useful if there is no master to control the servo(s)! |
Thinking about this further I think it would be better to allow saving of curves/positions to the eeprom so that the stored paths can be replayed at startup. This would allow the choice of how the servo behaves, and would allow for the OpenServo to be decoupled from the host controller.
| kbb wrote: | | As a brownout indicates a “problem”, maybe the bootloader could jump directly to the OpenServo application firmware, which then enters an “alert” state, |
I think this is a sensible approach. Let the host know so that anything that needs to change, such as unsaved configuration, can be restored.
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Nov 25, 2007 11:29 pm Post subject: |
|
|
| ginge wrote: | | kbb wrote: |
A “brake register” that provides control over how “hard” the braking is (0=none, 255=full on)?
|
An interesting idea. I would have to think about how that one would work, but I do like it. I worry about having a separate command for the brake, as setting it while the servo is in motion would cause exploded FETs. Your "brake register" along with a little bit of logic would be a good way around that issue. |
Currently the pwm_stop function has code that looks like
| Code: | if (1)
{
delay_loop(DELAYLOOP);
PORTD |= ((1<<PD2) | (1<<PD3));
} else
{
PORTD &= ~((1<<PD2) | (1<<PD3));
} |
and (currently) it is being called, whenever PWM drive is not required, from pwm_update. Thus for “controlled” braking I was thinking that code of the form
| Code: | static int8_t nBrakeCount;
delay_loop(DELAYLOOP);
if(nReg_nBreakStrength && nBrakeCount<=nReg_nBreakStrength)
{
PORTD |= ((1<<PD2) | (1<<PD3));
} else
{
PORTD &= ~((1<<PD2) | (1<<PD3));
}
nBrakeCount++; |
might be a feasible method. Linking it to a timer might be nicer tho (just more complicated, possibly unnecessarily so). To be clean, nBrakeCount would be initialised to 0 each time PWM drive comes on.
Kevin. |
|
| Back to top |
|
|
bren
Joined: 01 Jul 2007
Posts: 79
|
| Posted: Mon Nov 26, 2007 10:04 am Post subject: |
|
|
Hi all
I like the idea of been able to set the brake with a 0-255. For me I could use it when setting a pose so that you could rotate the servo by hand, but it should be able to stay in that position whilst I'm moving other servos. As for the set position on start up it could be useful but not essential. I could see my self using it to make my biped go to the home position whilst my gumstix boots.
kbb - Have you solved the brown out problem yet.
Bren |
|
| 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
