Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

MR-C3024 and AVR Development Tools

Hitec robotics including ROBONOVA humanoid, HSR-8498HB servos, MR C-3024 Controllers and RoboBasic
29 postsPage 2 of 21, 2
29 postsPage 2 of 21, 2

Post by limor » Tue Jun 06, 2006 1:03 am

Post by limor
Tue Jun 06, 2006 1:03 am

i-Bot wrote:If Newmicros are able to program an efficient timed group move function based on the assumption all servos are digital. And offer an "occasional" position feedback capability, this may be enough.


It'd be interesting to see how often position can be captured contiously as this would allow for feedback control. For example, if the robot's foot gets blocked while walking, the knee servo position readings would register unusual positions and elevated current consumption in comparisson to the standard gait. Falling may be prevented by doing some corrective action.
(see example1 - Andrew Lippitt's ground sensing exapod and example2 - Alejandro Alonso-Puig's obstacle sensing hexapod and example3 - speculation about NXT's position feedback)
i-Bot wrote:If Newmicros are able to program an efficient timed group move function based on the assumption all servos are digital. And offer an "occasional" position feedback capability, this may be enough.


It'd be interesting to see how often position can be captured contiously as this would allow for feedback control. For example, if the robot's foot gets blocked while walking, the knee servo position readings would register unusual positions and elevated current consumption in comparisson to the standard gait. Falling may be prevented by doing some corrective action.
(see example1 - Andrew Lippitt's ground sensing exapod and example2 - Alejandro Alonso-Puig's obstacle sensing hexapod and example3 - speculation about NXT's position feedback)
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by subpilot » Tue Jun 06, 2006 4:48 am

Post by subpilot
Tue Jun 06, 2006 4:48 am

Here's more from NewMicros

I'd spoken with a software engineer here who had mentioned that the timer pulse generation and measurement on non-timer pins was probably based on interrupt driven software programming using those pins. Its a technique called "bit-banging" in which a port pin is made to act like a timer pin through software, depending on the speed of the processor to generate or read pulses. It works, though can be a bit complicated to program in. It would simply require enough processor cycles to generate or read the pulses. The Mega128 probably has 16 MIPs to work with using a 16 MHz clock, the Servopod has 40 MIPs to work with if developing in DSP56F8xx assembly. Should be doable if there is a programmer available to generate the interrupt code needed to output and input pulses on GPIO pins as well as Timer pins.

As an alternative, perhaps using 2 IsoPods would be a solution. They are priced at $99 each, so would be the same price as a ServoPod, but you would then have 2 x 14 = 28 timer pins available. You would need some software to have the 2 communicate to each other. And I believe their size is such that the 2 boards sized 1.2" by 3" each should fit in the space occupied by the HiTec board. We have RC-Servo adapter boards for these, but that might go beyond the depth of the enclosure on the Robonova. Used as is, the signal wire from each servo could be routed to the appropriate timer pin, while the power lines for the servo are routed to a power board.

Sending a servo pulse on a timer pin is shown on our Download page :
http://www.newmicros.com/store/product_ ... nload.html
on page 6 of the IO Glossary. The example is :
An RC servo requires a 50 Hz (20 msec) PWM waveform with an on time varying from 1 msec to 2 msec, on output pin PHASEA0 (TA0). We wish to control this with an integer parameter from 0 to 100.

The desired range of on-time corresponds to a duty cycle varying from 5% to 10%. 5% of 65535 decimal is 3277, and 10% is 6554. We need to add a fraction of 3277 to the base value of 3277. This is easily accomplished with the */ scaling operator:

DECIMAL
: SET-RC-SERVO ( n -- )
3277 100 */ ( scale 0-100 to 0-3277 )
3277 + ( add base value of 3277 )
TA0 PWM-OUT ( output that duty cycle, 5-10% of 65535 )
;

50000 TA0 PWM-PERIOD ( set period to 20 msec )
TA0 ACTIVE-HIGH
50 SET-RC-SERVO ( output 50% of range, 1.5 msec pulse width )


Similarly, reading a pulse can be accomplished as shown in later, or from one of our code examples for reading a sonar further down the download page :

: SRF05
TA0 OFF TA0 ON TA0 OFF ( PULSE OUT
TA0 ON ( MAKE HIGH TO BE INPUT
TA0 SET-PWM-IN ( READY TO READ PULSE WIDTH
BEGIN
CHK-PWM-IN ( CHK PULSE
?DUP ( DUP IF NON ZERO
UNTIL . ( STOP WAITING WHEN NON ZERO, PRINT
;

Accelerometers and Gyros usually have a variable voltage that could be read by the analog to digital pins available. Simple lines like
ADC0 ANALOGIN .
would provide the current reading of a device attached to the ADC0 pin.

Finally, to get 2 IsoPods to talk to each other, there is a CAN example on the Download page, that I believe was used in an interesting robot. It had 6 sections that each had a Pod board in, which drove a pair of motors for that given section.

As another example, there is code showing driving an 18 servo hexapod robot with inverse kinematics being calculated for each leg, to have appropriate placing of the robots foot depending on which direction it is being directed to travel. It does make use of PWM outputs, so would not read in pulses.

David Peterson
www.newmicros.com
Here's more from NewMicros

I'd spoken with a software engineer here who had mentioned that the timer pulse generation and measurement on non-timer pins was probably based on interrupt driven software programming using those pins. Its a technique called "bit-banging" in which a port pin is made to act like a timer pin through software, depending on the speed of the processor to generate or read pulses. It works, though can be a bit complicated to program in. It would simply require enough processor cycles to generate or read the pulses. The Mega128 probably has 16 MIPs to work with using a 16 MHz clock, the Servopod has 40 MIPs to work with if developing in DSP56F8xx assembly. Should be doable if there is a programmer available to generate the interrupt code needed to output and input pulses on GPIO pins as well as Timer pins.

As an alternative, perhaps using 2 IsoPods would be a solution. They are priced at $99 each, so would be the same price as a ServoPod, but you would then have 2 x 14 = 28 timer pins available. You would need some software to have the 2 communicate to each other. And I believe their size is such that the 2 boards sized 1.2" by 3" each should fit in the space occupied by the HiTec board. We have RC-Servo adapter boards for these, but that might go beyond the depth of the enclosure on the Robonova. Used as is, the signal wire from each servo could be routed to the appropriate timer pin, while the power lines for the servo are routed to a power board.

Sending a servo pulse on a timer pin is shown on our Download page :
http://www.newmicros.com/store/product_ ... nload.html
on page 6 of the IO Glossary. The example is :
An RC servo requires a 50 Hz (20 msec) PWM waveform with an on time varying from 1 msec to 2 msec, on output pin PHASEA0 (TA0). We wish to control this with an integer parameter from 0 to 100.

The desired range of on-time corresponds to a duty cycle varying from 5% to 10%. 5% of 65535 decimal is 3277, and 10% is 6554. We need to add a fraction of 3277 to the base value of 3277. This is easily accomplished with the */ scaling operator:

DECIMAL
: SET-RC-SERVO ( n -- )
3277 100 */ ( scale 0-100 to 0-3277 )
3277 + ( add base value of 3277 )
TA0 PWM-OUT ( output that duty cycle, 5-10% of 65535 )
;

50000 TA0 PWM-PERIOD ( set period to 20 msec )
TA0 ACTIVE-HIGH
50 SET-RC-SERVO ( output 50% of range, 1.5 msec pulse width )


Similarly, reading a pulse can be accomplished as shown in later, or from one of our code examples for reading a sonar further down the download page :

: SRF05
TA0 OFF TA0 ON TA0 OFF ( PULSE OUT
TA0 ON ( MAKE HIGH TO BE INPUT
TA0 SET-PWM-IN ( READY TO READ PULSE WIDTH
BEGIN
CHK-PWM-IN ( CHK PULSE
?DUP ( DUP IF NON ZERO
UNTIL . ( STOP WAITING WHEN NON ZERO, PRINT
;

Accelerometers and Gyros usually have a variable voltage that could be read by the analog to digital pins available. Simple lines like
ADC0 ANALOGIN .
would provide the current reading of a device attached to the ADC0 pin.

Finally, to get 2 IsoPods to talk to each other, there is a CAN example on the Download page, that I believe was used in an interesting robot. It had 6 sections that each had a Pod board in, which drove a pair of motors for that given section.

As another example, there is code showing driving an 18 servo hexapod robot with inverse kinematics being calculated for each leg, to have appropriate placing of the robots foot depending on which direction it is being directed to travel. It does make use of PWM outputs, so would not read in pulses.

David Peterson
www.newmicros.com
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Post by i-Bot » Tue Jun 06, 2006 11:36 am

Post by i-Bot
Tue Jun 06, 2006 11:36 am

Some info on the MR-C3024 to PC protocol at last !

http://www.robonova.de/store/support/in ... 63&nav=0,3
Some info on the MR-C3024 to PC protocol at last !

http://www.robonova.de/store/support/in ... 63&nav=0,3
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by Bullit » Tue Jun 06, 2006 5:00 pm

Post by Bullit
Tue Jun 06, 2006 5:00 pm

As awesome as it is that they released this much, it is incomplete.
Obviously the program transfer and controller version and status commands are missing. There are probably many others. I'd like to be able to alter the baud rate up from 9600bps.
As awesome as it is that they released this much, it is incomplete.
Obviously the program transfer and controller version and status commands are missing. There are probably many others. I'd like to be able to alter the baud rate up from 9600bps.
Bullit
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 291
Joined: Wed May 31, 2006 1:00 am
Location: Near robot

Post by i-Bot » Tue Jun 06, 2006 8:37 pm

Post by i-Bot
Tue Jun 06, 2006 8:37 pm

I agree, I don't understand why they only give part of it. Especially when Robobasic obviously uses many more command codes.

However the serial monitor program described before in this thread is great, and reveals much more when you get the principles from the disclosed part.

You can see how the position feedback is achieved from the monitor traces, and also the program downloading. The controller information command is simple to decode.

It looks like the speed may be kicked up to a higher rate during downloads. Not sure if this can be changed at other times. Otherwise speed may be an issue. The position feedback has 10 bytes of data for 8 channels, so we are limited to 100 reads per sec, at very best. Moves average about 4 bytes per servo, so at first guestimate we are going to be in the region of 10 motion updates per sec. Can anyone give us some idea if this is fast enough for say reading accelerometers/Gryos and creating a response in time ?

Lots to investigate !

Maybe we should start a new thread, where we can share our discoveries.
I agree, I don't understand why they only give part of it. Especially when Robobasic obviously uses many more command codes.

However the serial monitor program described before in this thread is great, and reveals much more when you get the principles from the disclosed part.

You can see how the position feedback is achieved from the monitor traces, and also the program downloading. The controller information command is simple to decode.

It looks like the speed may be kicked up to a higher rate during downloads. Not sure if this can be changed at other times. Otherwise speed may be an issue. The position feedback has 10 bytes of data for 8 channels, so we are limited to 100 reads per sec, at very best. Moves average about 4 bytes per servo, so at first guestimate we are going to be in the region of 10 motion updates per sec. Can anyone give us some idea if this is fast enough for say reading accelerometers/Gryos and creating a response in time ?

Lots to investigate !

Maybe we should start a new thread, where we can share our discoveries.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by Bullit » Tue Jun 06, 2006 8:46 pm

Post by Bullit
Tue Jun 06, 2006 8:46 pm

Gyro or acclerometer feedback needs to be at least 20 cycles per second combined with motor response in the same time frame.
That serial monitor program is very nice. I'll look into how the baud rate is changed via the monitor. If we can figure that one out we should be down to how fast the controller can respond and not the RS232 bottleneck.
Gyro or acclerometer feedback needs to be at least 20 cycles per second combined with motor response in the same time frame.
That serial monitor program is very nice. I'll look into how the baud rate is changed via the monitor. If we can figure that one out we should be down to how fast the controller can respond and not the RS232 bottleneck.
Bullit
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 291
Joined: Wed May 31, 2006 1:00 am
Location: Near robot

Post by mpthompson » Thu Jun 08, 2006 12:25 am

Post by mpthompson
Thu Jun 08, 2006 12:25 am

I have put together here some information I gleaned from observing serial exchange between the RoboNova and the Real-Time Control Window in RoboBasic and from some other sources. Hopefully others can expand upon this basic information.

Something I'm curious about is once a servo is commanded to position, how do you know when the servo reached the position? I guess you have to poll.

-Mike
I have put together here some information I gleaned from observing serial exchange between the RoboNova and the Real-Time Control Window in RoboBasic and from some other sources. Hopefully others can expand upon this basic information.

Something I'm curious about is once a servo is commanded to position, how do you know when the servo reached the position? I guess you have to poll.

-Mike
mpthompson
Newbie
Newbie
User avatar
Posts: 6
Joined: Mon May 29, 2006 1:00 am
Location: San Carlos, CA

Post by i-Bot » Fri Jun 09, 2006 2:17 pm

Post by i-Bot
Fri Jun 09, 2006 2:17 pm

Here is my contribution. Still hunting for further enlightenment.

http://web.ukonline.co.uk/r.ibbotson/fi ... Serial.pdf

Richard
Here is my contribution. Still hunting for further enlightenment.

http://web.ukonline.co.uk/r.ibbotson/fi ... Serial.pdf

Richard
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by Bullit » Fri Jun 09, 2006 5:28 pm

Post by Bullit
Fri Jun 09, 2006 5:28 pm

Wow, nice work i-Bot!
I wish I understood more about the baud rate change.
It appears from i-Bot's work that it is automatic with the program transfer.
I thought it would be a seperate command. I was hoping to up the baud rate for faster acquisition and control and operate at one baudrate so that it could easily be bluetooth.
Wow, nice work i-Bot!
I wish I understood more about the baud rate change.
It appears from i-Bot's work that it is automatic with the program transfer.
I thought it would be a seperate command. I was hoping to up the baud rate for faster acquisition and control and operate at one baudrate so that it could easily be bluetooth.
Bullit
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 291
Joined: Wed May 31, 2006 1:00 am
Location: Near robot

My comments on a few points

Post by bearclaw » Fri Jun 09, 2006 11:38 pm

Post by bearclaw
Fri Jun 09, 2006 11:38 pm

The problem with reverse-engineering the serial "firmware" update protocol is that there is nothing to reverse-engineer yet, since hitec did not release any update yet.


I think it's perfectly possible to get fast (20-50Hz) read/write of all servos through a serial line with nothing more powerful than an atmel. I allready solved the write part, still having trouble reading the servo positions
The problem with reverse-engineering the serial "firmware" update protocol is that there is nothing to reverse-engineer yet, since hitec did not release any update yet.


I think it's perfectly possible to get fast (20-50Hz) read/write of all servos through a serial line with nothing more powerful than an atmel. I allready solved the write part, still having trouble reading the servo positions
bearclaw
Robot Builder
Robot Builder
User avatar
Posts: 10
Joined: Sun May 14, 2006 1:00 am

Post by SirAho » Sun Jun 11, 2006 2:04 pm

Post by SirAho
Sun Jun 11, 2006 2:04 pm

Maybe an alternative to the NewMicros is the RE001 board. It's based on the ATmega128 and you can program it in C. It's used to control the robot "Pirkus R Type-01" that was designade by Jin Sato (well-known in the Mindstorm community). You can buy it separatly without the robot. A SDK is included with the board.

Here is some information about RE001 in the end of the article at Robots dreams (in English)
http://www.robots-dreams.com/2006/01/ro ... imer_.html
Maybe an alternative to the NewMicros is the RE001 board. It's based on the ATmega128 and you can program it in C. It's used to control the robot "Pirkus R Type-01" that was designade by Jin Sato (well-known in the Mindstorm community). You can buy it separatly without the robot. A SDK is included with the board.

Here is some information about RE001 in the end of the article at Robots dreams (in English)
http://www.robots-dreams.com/2006/01/ro ... imer_.html
SirAho
Robot Builder
Robot Builder
User avatar
Posts: 16
Joined: Tue Apr 11, 2006 1:00 am

Post by limor » Thu Jun 29, 2006 4:57 pm

Post by limor
Thu Jun 29, 2006 4:57 pm

subpilot, Have you managed to get servo position reading with the servopod? Has anyone else managed using another board?
subpilot, Have you managed to get servo position reading with the servopod? Has anyone else managed using another board?
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by i-Bot » Thu Jun 29, 2006 9:11 pm

Post by i-Bot
Thu Jun 29, 2006 9:11 pm

I have only tried it on a Parallax SX28 processor under SX/B using pulseout and pulsein instructions, and it works fine.

The servos look like about 30K ohms to ground, so you need to be a check if your pullups are small enough to meet the processor VinHigh. The Atmega specifies 20 to 50K for the pullup, so in theory, the required 3V high will not be acheived at a 5V processor supply. But it seems to work OK.
I have only tried it on a Parallax SX28 processor under SX/B using pulseout and pulsein instructions, and it works fine.

The servos look like about 30K ohms to ground, so you need to be a check if your pullups are small enough to meet the processor VinHigh. The Atmega specifies 20 to 50K for the pullup, so in theory, the required 3V high will not be acheived at a 5V processor supply. But it seems to work OK.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by subpilot » Fri Jun 30, 2006 6:46 am

Post by subpilot
Fri Jun 30, 2006 6:46 am

I haven't even powered up my Servopod yet. I'm leaving for sea again on Tuesday and have been busy trying to get things I need done before then. I'm taking my Servopod and several servos with me so hopefully I'll have time to do some development during the cruise.
I haven't even powered up my Servopod yet. I'm leaving for sea again on Tuesday and have been busy trying to get things I need done before then. I'm taking my Servopod and several servos with me so hopefully I'll have time to do some development during the cruise.
subpilot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 146
Joined: Sat Feb 25, 2006 1:00 am
Location: Lake Arrowhead, Ca,USA

Previous
29 postsPage 2 of 21, 2
29 postsPage 2 of 21, 2