RoboSavvy Forum

MR-C3024 16Mhz

2008-06-06T16:00:41+01:00

i use external resistors, since in PIC 16F, internal pullups are only available for one port (8 IO lines). I use 4.7K pull-up resistor and simply switch the io direction to "input" when the servo is supposed to respond - this way you only need one io port per servo and don't need any circuitry other than the pull-up resistor.

Statistics: Posted by kushlik — Fri Jun 06, 2008 4:00 pm

MR-C3024 16Mhz

2008-06-06T13:39:02+01:00

Do you use external pull-ups on your PIC io to controll the servo or does the internall pull-up are enough ?
Thanks

Statistics: Posted by Voelker — Fri Jun 06, 2008 1:39 pm

MR-C3024 16Mhz

2008-06-03T18:56:34+01:00

Cool, thank you, i got it working.

Statistics: Posted by kushlik — Tue Jun 03, 2008 6:56 pm

MR-C3024 16Mhz

2008-06-03T17:52:53+01:00

The speed setting is very important. It does work. Any controller must manage individual servo speeds in addition to position.

In PWM the position is set on the servo, but the controller sets the speed by splitting the move into smaller timed steps. In serial HMI the speed can be set direct on the servo, and must be changed for slower movements and PTP moves.

Statistics: Posted by i-Bot — Tue Jun 03, 2008 5:52 pm

MR-C3024 16Mhz

2008-06-03T17:35:14+01:00

i-Bot,

I was curious about the speed setting - what does it do? Is this an alternative to setting a desired angle - just set the speed and it will move at that speed? I am confused why "set speed" and "get position" are combined together. So far i was only able to set speed to 0. otherwise the servo does not respond or turn...

Statistics: Posted by kushlik — Tue Jun 03, 2008 5:35 pm

MR-C3024 16Mhz

2008-06-03T17:25:13+01:00

Serial HMI works fine on the HSR-8498HB for the position setting, position read, and speed. Some of the later HMI version features such as PID settings are not available.

The reading of position does not cause the torque of the servo to be turned off. There do appear to be some timing conflicts between the serial HMI and the internal servo working. If the servo is moving at a steady speed continous position reads can cause the motion to become uneven. Also not all reads are succesful. Interested to hear your findings.

Interrupts should be OK, since you only need 10% accuracy on the edges of the serial stream and 19.2 is pretty slow. If you don't use interrupts you are hanging up the processor for too long. I have just done a new PWM code for the standard 7.3728 MR-C3024 using interrupts. I can still get 1 us accuracy on 24 ports with other interrupts going at the same time. I set the timer to trigger early on one OCR, then wait in a tight loop for the next OCR. if the next PWM edge is within 10us, I time by code, else I go back and wait for the interrupt. The entire motion engine CPU load has dropped from 70% to less than 20%.

Statistics: Posted by i-Bot — Tue Jun 03, 2008 5:25 pm

MR-C3024 16Mhz

2008-06-03T15:59:31+01:00

Sounds great, if the HMI protocol works on the robonova's servos updating position will be a lot less time taking than with the PWM interface. I hope to get my PIC32 board working soon in order to test this ...
Thanks

Statistics: Posted by Voelker — Tue Jun 03, 2008 3:59 pm

MR-C3024 16Mhz

2008-06-03T15:48:24+01:00

Voelker,

I guess you may be right about low overhead for higher clock speeds. There is only one way to find out - try it .

The serial protocol works on Robonova's servos. The stock servos should also work - just make sure you buy the right type. If you look up the specs for the HSR-8498HB, it says that it supports it. I have ordered a couple of these servos, but they have not come in, so i can't say for sure that the stock servos of the same type support HMI. (if they don't, i am getting my money back! )

About the position refresh rate - the servo does not go limp when you stop sending commands via HMI protocol. Therefore, arbitrarily low update rate will work.

Statistics: Posted by kushlik — Tue Jun 03, 2008 3:48 pm

MR-C3024 16Mhz

2008-06-03T15:16:42+01:00

Does the serial protocol works on the stock servos ? I thought that HMI was disabled on those servos ... I agree that the interrupt overhead can give unprecise timings on a PIC18 running at 20Mhz as this kind of proccessor really runs at 5Mhz, but on a PIC32 running at 80Mhz (true core frequency) the induced overhead is lot less than 1µs. As each servo as 256 positions this overhead cannot affect the precision on digital servo. When using the serial protocol, do you have to refresh the servo position often ?

Statistics: Posted by Voelker — Tue Jun 03, 2008 3:16 pm

MR-C3024 16Mhz

2008-06-03T14:37:06+01:00

Oh, and when you use serial protocol, the servo does *not* get loose. Just checked it yesterday.

Statistics: Posted by kushlik — Tue Jun 03, 2008 2:37 pm

MR-C3024 16Mhz

2008-06-03T14:35:45+01:00

I think the idea, discussed here, is to use the serial protocol at 19200 baud, instead of generating 16 pwm lines. The trick is to implement the serial communication yourself and flip all 16 bits at once (or almost at once). This way, you can achieve almost parallel functionality of 16 servos. The nice thing is that, as opposed to generating PWM with different pulse widths, the timing for serial communication can be precisely synchronized for all 16 lines, allowing to write and read from all 16 servos at once by imply flipping output pins or reading from them at appropriate time steps. All you need for this is 16 IO pins, preferably 2 sets of 8 which are on the same ports, so that you can write a byte to the whole 8-bit IO port (exactly like one would do for standard parallel port communication)

Therefore, there is at most a single timer required, but i would suggest actually not using interrupts or checking timers, but hand-tweaking the inter-bit delay, since the interrupt overhead won't guarantee precise timing.. For example, i used a delay_us() function in PICC compiler with conjunction with NOP assembly codes to get the timing exactly right. Otherwise, function call overhead can screw you up! (the disadvantage is that while sending/receiving commands, the code won't do anything else, but it seems like the only purpose of the microcontroller is to do the communication of the motors, so it should be fine)

Statistics: Posted by kushlik — Tue Jun 03, 2008 2:35 pm

MR-C3024 16Mhz

2008-06-03T13:22:18+01:00

while reading fedback, does the servo gets loosy or does it keep its position. I don't know what kinf of pic you intend to use but to send position to 16 servos, you'll need a minimum of two timers ... I am actually designing a board for the robonova with a PIC32, maybe this could work as it has a lot of timers and processing power ...

Statistics: Posted by Voelker — Tue Jun 03, 2008 1:22 pm

MR-C3024 16Mhz

2008-06-02T22:13:26+01:00

tum,

Keep in mind that you don't need to flip one bit at a time - you can set the whole output port to an 8-bit value. I tried this using a PIC microcontroller and it actually takes less time to set the whole output port than a single bit. I was able to get switching frequency of 1.25 Mhz (verified on the scope) on a 16F876A PIC with 20 Mhz crystal. Since PIC's clock speed is 1/4 of the oscillator, this tells me that it only takes 4 cycles to set the whole output port. This should speed up things quite a bit!

Btw, I am also working on interfacing the ROBONOVA to a PC with minimum overhead. I am actually planning on using one PIC microcontroller, mentioned above. I think it will be sufficient and there is no need for the "fancy" Atmel chip.

I was able to get one channel working with sending position command and reading feedback at ~100 Hz (also verified on the scope).. Now i "simply" need to make it work for 16 in parallel

Let me know if this makes sense..

Statistics: Posted by kushlik — Mon Jun 02, 2008 10:13 pm

MR-C3024 16Mhz

2008-05-19T21:29:52+01:00

From the cboot code, which you will find in my file area. It appears the bootloader sits at location (word) 0xf000. The bootloader is only capable to write to the range 0x00 to 0x7f7f in the application area and to 0xff80 to 0xffff in the boot area. So it cannot write to the boot area used in one step. It also appears applications cannot write to the boot area.

It seems unlikely to damage the boot loader with any wild application code, or bad downloads.

It would appear possible to change the boot loader if you wrote and downloaded a loader loader to locations 0xff80, and used this to load the area at 0xf00 with a new bootloader.

Statistics: Posted by i-Bot — Mon May 19, 2008 9:29 pm

MR-C3024 16Mhz

2008-05-19T21:29:36+01:00

Statistics: Posted by i-Bot — Mon May 19, 2008 9:29 pm