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

libavr/libbioloid C library for CM5 released!

Bioloid robot kit from Korean company Robotis; CM5 controller block, AX12 servos..
289 postsPage 5 of 201, 2, 3, 4, 5, 6, 7, 8 ... 20
289 postsPage 5 of 201, 2, 3, 4, 5, 6, 7, 8 ... 20

Post by BillB » Tue Jan 20, 2009 12:25 pm

Post by BillB
Tue Jan 20, 2009 12:25 pm

anjocama wrote:
The libbioloid, have any function to the AX-S1?


Yes it certianly does although I have not used them yet.

anjocama wrote:
I have a HaVimo camera for bioloid. You have any idea about integrated this whit this libraries?


Although I do not have a HaVimo camera, I am sure that once you have mastered using the AX-S1 then using the HaVimo camera should be a quite straight forward. Although you will need to define the HaVimo address table (similar to the AX-S1 definitions in dynamixel.h ).
anjocama wrote:
The libbioloid, have any function to the AX-S1?


Yes it certianly does although I have not used them yet.

anjocama wrote:
I have a HaVimo camera for bioloid. You have any idea about integrated this whit this libraries?


Although I do not have a HaVimo camera, I am sure that once you have mastered using the AX-S1 then using the HaVimo camera should be a quite straight forward. Although you will need to define the HaVimo address table (similar to the AX-S1 definitions in dynamixel.h ).
Last edited by BillB on Tue Jan 20, 2009 1:08 pm, edited 1 time in total.
BillB
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

Post by anjocama » Tue Jan 20, 2009 12:40 pm

Post by anjocama
Tue Jan 20, 2009 12:40 pm

OK. Thanks BillB.
I will investigate about this.
OK. Thanks BillB.
I will investigate about this.
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by BillB » Tue Jan 20, 2009 1:28 pm

Post by BillB
Tue Jan 20, 2009 1:28 pm

anjocama wrote:
The libbioloid, have any function to the AX-S1?


I just did a quick test and the following changes to example.c will read and display the values of all three IR proximity sensors on the AX-S1:

Declare the AX-S1 in "robot_t FLASH robot" by adding the following line (immediately before "{ DX_NOID, 0 }":
Code: Select all
        {  100,MODEL_AXS1, 0, 0, 0},


Then in, your Main() loop, add:

Code: Select all
uint8_t *data = dx_read(100, P_IRDATA_L, 3);
printf("IR Left:%d Centre:%d Right:%d \n", data[0], data[1], data[2]);


It works a treat!
anjocama wrote:
The libbioloid, have any function to the AX-S1?


I just did a quick test and the following changes to example.c will read and display the values of all three IR proximity sensors on the AX-S1:

Declare the AX-S1 in "robot_t FLASH robot" by adding the following line (immediately before "{ DX_NOID, 0 }":
Code: Select all
        {  100,MODEL_AXS1, 0, 0, 0},


Then in, your Main() loop, add:

Code: Select all
uint8_t *data = dx_read(100, P_IRDATA_L, 3);
printf("IR Left:%d Centre:%d Right:%d \n", data[0], data[1], data[2]);


It works a treat!
BillB
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

Post by anjocama » Tue Jan 20, 2009 2:29 pm

Post by anjocama
Tue Jan 20, 2009 2:29 pm

nice!

I compile whit this and work great.

I probed the other sensors of AX-S1 and all working good!

This is the example for the Lum and Sound sensors (based in your code :D ):
uint8_t *data = dx_read(100, P_IRDATA_L, 3);
uint8_t *data2 = dx_read(100, P_SOUNDDATA, 3);
uint8_t *data3 = dx_read(100, P_LUMDATA_L, 3);
printf("IR Left:%d Centre:%d Right:%d \n", data[0], data[1], data[2]);
printf("Sound Data:%d Sound Hold:%d Sound Count:%d \n", data2[0], data2[1], data2[2]);
printf("Lum Left:%d Lum Centre:%d Lum Right:%d \n", data3[0], data3[1], data3[2]);
nice!

I compile whit this and work great.

I probed the other sensors of AX-S1 and all working good!

This is the example for the Lum and Sound sensors (based in your code :D ):
uint8_t *data = dx_read(100, P_IRDATA_L, 3);
uint8_t *data2 = dx_read(100, P_SOUNDDATA, 3);
uint8_t *data3 = dx_read(100, P_LUMDATA_L, 3);
printf("IR Left:%d Centre:%d Right:%d \n", data[0], data[1], data[2]);
printf("Sound Data:%d Sound Hold:%d Sound Count:%d \n", data2[0], data2[1], data2[2]);
printf("Lum Left:%d Lum Centre:%d Lum Right:%d \n", data3[0], data3[1], data3[2]);
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by anjocama » Tue Jan 20, 2009 2:51 pm

Post by anjocama
Tue Jan 20, 2009 2:51 pm

Other example whit the AX-S1 and AX-12.

if you put your hand near of center sensor IR then left arm move up or down in function of the distance detecction of hand.

code:

uint8_t *data = dx_read(100, P_IRDATA_L, 3);
s.servo[1].position=data[1];
Other example whit the AX-S1 and AX-12.

if you put your hand near of center sensor IR then left arm move up or down in function of the distance detecction of hand.

code:

uint8_t *data = dx_read(100, P_IRDATA_L, 3);
s.servo[1].position=data[1];
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by RandomMatt » Tue Jan 20, 2009 7:00 pm

Post by RandomMatt
Tue Jan 20, 2009 7:00 pm

anjocama wrote:1) The libbioloid, have any function to the AX-S1?
2) I have a HaVimo camera for bioloid. You have any idea about integrated this whit this libraries?


1) not yet (BillB has noticed the table of constants which is the start of it).
2) I don't have one, so I wouldn't know what to add.

More helpfully... you can just use dx_read() and dx_write() to write your own helper functions. For example, looking in dynamixel.c:

Code: Select all
void dx_setmaxtorque(uint8_t id, uint16_t max) {
    dx_write(id, P_TORQUE_LIMIT_L, 2, &max);
}

void dx_getpsx(uint8_t id, uint8_t *data) {
    uint8_t *buf = dx_read(id, P_PSX_BASE, P_PSX_LENGTH);
    for (int i = 0; i < P_PSX_LENGTH; i++)
        *data++ = *buf++;
}


basically...
Code: Select all
uint8_t *data = dx_read(id, start, length);
...reads some bytes and you can get at them by looking in data. and...
Code: Select all
dx_write(id, start, length, data);
...will write them back to the device.

Edit: BillB seems to have more prompt... oh well
anjocama wrote:1) The libbioloid, have any function to the AX-S1?
2) I have a HaVimo camera for bioloid. You have any idea about integrated this whit this libraries?


1) not yet (BillB has noticed the table of constants which is the start of it).
2) I don't have one, so I wouldn't know what to add.

More helpfully... you can just use dx_read() and dx_write() to write your own helper functions. For example, looking in dynamixel.c:

Code: Select all
void dx_setmaxtorque(uint8_t id, uint16_t max) {
    dx_write(id, P_TORQUE_LIMIT_L, 2, &max);
}

void dx_getpsx(uint8_t id, uint8_t *data) {
    uint8_t *buf = dx_read(id, P_PSX_BASE, P_PSX_LENGTH);
    for (int i = 0; i < P_PSX_LENGTH; i++)
        *data++ = *buf++;
}


basically...
Code: Select all
uint8_t *data = dx_read(id, start, length);
...reads some bytes and you can get at them by looking in data. and...
Code: Select all
dx_write(id, start, length, data);
...will write them back to the device.

Edit: BillB seems to have more prompt... oh well
RandomMatt
Savvy Roboteer
Savvy Roboteer
Posts: 117
Joined: Sat Dec 20, 2008 11:16 pm

Post by anjocama » Tue Jan 20, 2009 11:39 pm

Post by anjocama
Tue Jan 20, 2009 11:39 pm

OK. many thanks RandomMatt

One question... Are you think to include support libraries for the Havimo vision module in the future?
OK. many thanks RandomMatt

One question... Are you think to include support libraries for the Havimo vision module in the future?
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by anjocama » Wed Jan 21, 2009 1:04 am

Post by anjocama
Wed Jan 21, 2009 1:04 am

Sorry!

I repeat the question :shock:
Sorry!

I repeat the question :shock:
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by RandomMatt » Wed Jan 21, 2009 9:16 am

Post by RandomMatt
Wed Jan 21, 2009 9:16 am

aejocama wrote:Are you think to include support libraries for the Havimo vision module in the future?


Not anytime soon.

I've had a quick look at the quickstart guide... it look's different enough that I wouldn't assume that I can write the code correctly first time. And I have little intention of buying one to test against until after I finished my current projects:

1) Better servo firmware
2) The software for my psx interface board
3) In addition: StuartL and I have also been discussing how to build a (drop in) CM5 replacement with many times the performance and an on-board inner-ear.
aejocama wrote:Are you think to include support libraries for the Havimo vision module in the future?


Not anytime soon.

I've had a quick look at the quickstart guide... it look's different enough that I wouldn't assume that I can write the code correctly first time. And I have little intention of buying one to test against until after I finished my current projects:

1) Better servo firmware
2) The software for my psx interface board
3) In addition: StuartL and I have also been discussing how to build a (drop in) CM5 replacement with many times the performance and an on-board inner-ear.
RandomMatt
Savvy Roboteer
Savvy Roboteer
Posts: 117
Joined: Sat Dec 20, 2008 11:16 pm

Post by anjocama » Wed Jan 21, 2009 11:00 am

Post by anjocama
Wed Jan 21, 2009 11:00 am

This is great RandomMatt/StuartL!!,

About the actual library, how can i control de charge bateries and detect when the DC cable are connected?
I see the battery.h for this. Can you tell me any example about this.
This is great RandomMatt/StuartL!!,

About the actual library, how can i control de charge bateries and detect when the DC cable are connected?
I see the battery.h for this. Can you tell me any example about this.
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by RandomMatt » Wed Jan 21, 2009 9:46 pm

Post by RandomMatt
Wed Jan 21, 2009 9:46 pm

The battery code is designed to be automatic. In the sense that
* it'll charge the battery if the battery needs it and the power lead is plugged in.
* it'll flash the power led as the battery gets low.
* it'll switch the robot off when the battery get flat.

The magic numbers in the #defines are the various voltage thresholds for the above.
* if the battery voltage is less than MV_FLASH, the power led flashes
* if the battery voltage is less than MV_STOP, the robot is stopped
* if the battery voltage is less than MV_CHARGE, and the power lead is plugged in; the battery charging circuit is turned on.

--

But... the battery charging circuit on the CM5 is broken. It isn't safe to use. Basically it is impossible to detect the end point for the charging... so the code has to either play safe an under charge the battery (this is what the robotis code does) and then you have poor battery life. Or you try to charge the battery correctly, which overcharges it slightly each time (which is what StuartL's code in battery.c does).

So... if you choose to use it be very careful. I have a melted CM5 case as a result of a battery fire caused by that code. In hindsight it may be safe enough, but I'd recommend just using a proper battery charger for a remote controlled car and be done with it. If you don't have one, then I'd suggest (along with BillB) that you get a LiPo and a LiPo charger as they are much better.
The battery code is designed to be automatic. In the sense that
* it'll charge the battery if the battery needs it and the power lead is plugged in.
* it'll flash the power led as the battery gets low.
* it'll switch the robot off when the battery get flat.

The magic numbers in the #defines are the various voltage thresholds for the above.
* if the battery voltage is less than MV_FLASH, the power led flashes
* if the battery voltage is less than MV_STOP, the robot is stopped
* if the battery voltage is less than MV_CHARGE, and the power lead is plugged in; the battery charging circuit is turned on.

--

But... the battery charging circuit on the CM5 is broken. It isn't safe to use. Basically it is impossible to detect the end point for the charging... so the code has to either play safe an under charge the battery (this is what the robotis code does) and then you have poor battery life. Or you try to charge the battery correctly, which overcharges it slightly each time (which is what StuartL's code in battery.c does).

So... if you choose to use it be very careful. I have a melted CM5 case as a result of a battery fire caused by that code. In hindsight it may be safe enough, but I'd recommend just using a proper battery charger for a remote controlled car and be done with it. If you don't have one, then I'd suggest (along with BillB) that you get a LiPo and a LiPo charger as they are much better.
RandomMatt
Savvy Roboteer
Savvy Roboteer
Posts: 117
Joined: Sat Dec 20, 2008 11:16 pm

Post by StuartL » Thu Jan 22, 2009 10:03 am

Post by StuartL
Thu Jan 22, 2009 10:03 am

To expand slightly on Matt's explanation of the battery charging issues:

The ADC (analogue to digital converter) used by the CM-5 board to sense the battery voltage is only accurate to 20mV. To charge a NiCd pack safely you need much more accuracy than this.

As Matt has said the Robotis code does what my code originally did, and that's wait until the battery voltage stops increasing. The problem with this is that at 20mV resolution it stops increasing surprisingly early in the charging cycle and you end up with a partially charged pack.

The code I developed was intended to 'guess' when the battery was fully charged by optimistically keeping the charging circuit running for a preset time after the battery voltage stops increasing. For a few weeks it seemed to work very nicely. Then the accrual of repeated overcharging caused a major failure of one of the NiCd packs and it caught fire.

Fortunately Matt heard the noise and managed to deal with the problem before the fire spread, not without damage to the CM-5 plastic case.

If you wish to use the charging code in the library it would be trivial to retune it to be more paranoid, however I strongly recommend that you invest money in a different (LiPo 3-cell) battery pack and remove the large charging diode in the charging circuit to prevent the CM-5 attempting to charge it.

Don't assume that disabling the code is enough to disable the charging circuit as the circuit (being so stupidly designed) actually gets turned on when the CM-5 boots up and only gets turned off when the port is initialised. This means that there's a very brief interval where the charging circuit runs every time the CM-5 starts up. I suspect that this would be disastrous for a LiPo pack.

We circumvent this problem by feeding the LiPo straight into the power rail, we don't use the battery connector. This also has a huge advantage for the BiPed in that there's a power distribution board hidden in the old battery compartment that allows much higher current down each limb by avoiding the inherent current limit of the battery connector and distribution wiring inside the CM5.

The drop-in-CM5 replacement Matt and I are talking about is VERY likely to have a multi-cell LiPo balancing charger built in. However LiPos are fickle beasts and we MUST recommend that you do not charge LiPos in anything other than a fire-proof container and away from anything flammable/expensive. Your robot qualifies :)
To expand slightly on Matt's explanation of the battery charging issues:

The ADC (analogue to digital converter) used by the CM-5 board to sense the battery voltage is only accurate to 20mV. To charge a NiCd pack safely you need much more accuracy than this.

As Matt has said the Robotis code does what my code originally did, and that's wait until the battery voltage stops increasing. The problem with this is that at 20mV resolution it stops increasing surprisingly early in the charging cycle and you end up with a partially charged pack.

The code I developed was intended to 'guess' when the battery was fully charged by optimistically keeping the charging circuit running for a preset time after the battery voltage stops increasing. For a few weeks it seemed to work very nicely. Then the accrual of repeated overcharging caused a major failure of one of the NiCd packs and it caught fire.

Fortunately Matt heard the noise and managed to deal with the problem before the fire spread, not without damage to the CM-5 plastic case.

If you wish to use the charging code in the library it would be trivial to retune it to be more paranoid, however I strongly recommend that you invest money in a different (LiPo 3-cell) battery pack and remove the large charging diode in the charging circuit to prevent the CM-5 attempting to charge it.

Don't assume that disabling the code is enough to disable the charging circuit as the circuit (being so stupidly designed) actually gets turned on when the CM-5 boots up and only gets turned off when the port is initialised. This means that there's a very brief interval where the charging circuit runs every time the CM-5 starts up. I suspect that this would be disastrous for a LiPo pack.

We circumvent this problem by feeding the LiPo straight into the power rail, we don't use the battery connector. This also has a huge advantage for the BiPed in that there's a power distribution board hidden in the old battery compartment that allows much higher current down each limb by avoiding the inherent current limit of the battery connector and distribution wiring inside the CM5.

The drop-in-CM5 replacement Matt and I are talking about is VERY likely to have a multi-cell LiPo balancing charger built in. However LiPos are fickle beasts and we MUST recommend that you do not charge LiPos in anything other than a fire-proof container and away from anything flammable/expensive. Your robot qualifies :)
StuartL
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by anjocama » Thu Jan 22, 2009 12:19 pm

Post by anjocama
Thu Jan 22, 2009 12:19 pm

Thanks StuartL/RandomMatt,

My next purchase as the LiPo Battery!

Change the subject, I think to play whitc C, motion pages saved at de eprom with the motion editor.

Have any functión yours library to do it? I search it but i dont find any.
Thanks StuartL/RandomMatt,

My next purchase as the LiPo Battery!

Change the subject, I think to play whitc C, motion pages saved at de eprom with the motion editor.

Have any functión yours library to do it? I search it but i dont find any.
anjocama
Savvy Roboteer
Savvy Roboteer
Posts: 36
Joined: Wed Jan 14, 2009 10:53 am

Post by StuartL » Thu Jan 22, 2009 5:56 pm

Post by StuartL
Thu Jan 22, 2009 5:56 pm

anjocama wrote:Change the subject, I think to play whitc C, motion pages saved at de eprom with the motion editor.

Have any functión yours library to do it? I search it but i dont find any.


Right now we haven't coded this functionality. The guys at Plymouth Uni (Phil and Joerg) coded some motion page decoding which I have looked at (and it looks REALLY easy) but because we're using inverse kinematics we haven't had any use for predefined motion sequences.

That's not to say I can't see any use for it. It's the kind of thing that we could, one day, get around to coding. It's just not what we've been concentrating on and as such is likely to be some time away.
anjocama wrote:Change the subject, I think to play whitc C, motion pages saved at de eprom with the motion editor.

Have any functión yours library to do it? I search it but i dont find any.


Right now we haven't coded this functionality. The guys at Plymouth Uni (Phil and Joerg) coded some motion page decoding which I have looked at (and it looks REALLY easy) but because we're using inverse kinematics we haven't had any use for predefined motion sequences.

That's not to say I can't see any use for it. It's the kind of thing that we could, one day, get around to coding. It's just not what we've been concentrating on and as such is likely to be some time away.
StuartL
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by BillB » Thu Jan 22, 2009 7:57 pm

Post by BillB
Thu Jan 22, 2009 7:57 pm

StuartL wrote:

remove the large charging diode in the charging circuit to prevent the CM-5 attempting to charge it.



Good tip. Could you please point out whch is the safety diode? Is it the one labelled D1 (the black one next to the large resistor)?
StuartL wrote:

remove the large charging diode in the charging circuit to prevent the CM-5 attempting to charge it.



Good tip. Could you please point out whch is the safety diode? Is it the one labelled D1 (the black one next to the large resistor)?
BillB
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

PreviousNext
289 postsPage 5 of 201, 2, 3, 4, 5, 6, 7, 8 ... 20
289 postsPage 5 of 201, 2, 3, 4, 5, 6, 7, 8 ... 20