libavr/libbioloid C library for CM5 released!

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

libavr/libbioloid C library for CM5 released!

Post by StuartL » Tue Dec 16, 2008 11:29 am

Post by StuartL
Tue Dec 16, 2008 11:29 am

Finally Matt and I have released the C library for CM5 development.

edit: Now with its own website... http://sneaky.livings.co.uk/bioloid/

Right now there's not much documentation but the example.c should be fairly self explanatory.

Dependencies:
- A working GCC and MAKE for the HOST operating system. For Windows I suggest Cygwin or MINGW. Linux probably already has this installed.
- A working GCC-AVR for the TARGET platform. Note that the CM5 is an ATmega128 so most of the recent AVR gcc targets will work.

Installation:
- Install Cygwin/MINGW/some other gcc/make combo.
- Install gcc AVR.
- Download both the libavr and libbioloid tgz files from the URL below.
- Go into the 'example' directory and type 'make'.
- Let me know if anything untoward happens.
- Transfer the .hex file to your CM5 and use the q, a, w and s keys to move servos 1 and 2 around.
- Join the distribution list to discuss any problems or feature requests.

All files are available at http://www.braincell.cx/bioloid/dist/. I would very much like to know who is downloading it just so we can get a feel for how many people are using different bits of the API when we start evolving the interface.

The distribution list can be joined by emailing the list robot at ecartis at (the domain) braincell dot cx with the command 'subscribe robots'. You will need to reply to the email you receive to confirm the subscription to the list.
Finally Matt and I have released the C library for CM5 development.

edit: Now with its own website... http://sneaky.livings.co.uk/bioloid/

Right now there's not much documentation but the example.c should be fairly self explanatory.

Dependencies:
- A working GCC and MAKE for the HOST operating system. For Windows I suggest Cygwin or MINGW. Linux probably already has this installed.
- A working GCC-AVR for the TARGET platform. Note that the CM5 is an ATmega128 so most of the recent AVR gcc targets will work.

Installation:
- Install Cygwin/MINGW/some other gcc/make combo.
- Install gcc AVR.
- Download both the libavr and libbioloid tgz files from the URL below.
- Go into the 'example' directory and type 'make'.
- Let me know if anything untoward happens.
- Transfer the .hex file to your CM5 and use the q, a, w and s keys to move servos 1 and 2 around.
- Join the distribution list to discuss any problems or feature requests.

All files are available at http://www.braincell.cx/bioloid/dist/. I would very much like to know who is downloading it just so we can get a feel for how many people are using different bits of the API when we start evolving the interface.

The distribution list can be joined by emailing the list robot at ecartis at (the domain) braincell dot cx with the command 'subscribe robots'. You will need to reply to the email you receive to confirm the subscription to the list.
Last edited by StuartL on Wed Sep 12, 2012 1:00 pm, edited 2 times in total.
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by limor » Tue Dec 16, 2008 9:40 pm

Post by limor
Tue Dec 16, 2008 9:40 pm

I looked at the example.c and it looks like programming the CM5 and communicating with the servos has become much easier than ever before. I dont have the Bioloid with me to test now but i will give it a go the next couple of weeks.

One question about the syntax.. I don't recall seeing before a statement in C such as [number] = {..list..}

Code: Select all
    static struct dx_stance s = { 0, { [23] = { DX_NOID, 0 } } };


:?:
I looked at the example.c and it looks like programming the CM5 and communicating with the servos has become much easier than ever before. I dont have the Bioloid with me to test now but i will give it a go the next couple of weeks.

One question about the syntax.. I don't recall seeing before a statement in C such as [number] = {..list..}

Code: Select all
    static struct dx_stance s = { 0, { [23] = { DX_NOID, 0 } } };


:?:
limor offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1812
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by StuartL » Tue Dec 16, 2008 10:10 pm

Post by StuartL
Tue Dec 16, 2008 10:10 pm

limor wrote:I looked at the example.c and it looks like programming the CM5 and communicating with the servos has become much easier than ever before. I dont have the Bioloid with me to test now but i will give it a go the next couple of weeks.


Thank you! We've worked very hard on that, and as you'll see from the changelog Matt in particular has contributed a HUGE amount to the repository recently. We wanted to be able to develop high performance software for the Bioloid without having to work at the low levels.

One question about the syntax.. I don't recall seeing before a statement in C such as [number] = {..list..}

Code: Select all
    static struct dx_stance s = { 0, { [23] = { DX_NOID, 0 } } };


:?:


That's actually a lot easier to understand if you open it out. Firstly the dx_stance structure looks like this:

Code: Select all
struct dx_servo {
    uint8_t id;
    int position;
};

struct dx_stance {
    uint8_t junk;
    struct dx_servo servo[]; // last item in the list should have id=DX_NOID
};


The 'junk' parameter is to avoid compiler bugs with variable length structures. Otherwise, in the stance, there's an array of servo structures.

Code: Select all
static struct dx_stance s = {
    0, // Junk
    { [23] = { DX_NOID, 0 } } // Initialises element 23 of the servo array of structures to the two values DX_NOID and zero.
};


Because element 23 is initialised to those values by implication the compiler must have allocated 0-22 (i.e. 23 other elements in the list). The startup code created by gcc-avr actually allocates these statically from the 4k RAM in the MCU and initialises them all to zero, with element 23 containing the ID of DX_NOID which the library knows to mean is the end of the array.
limor wrote:I looked at the example.c and it looks like programming the CM5 and communicating with the servos has become much easier than ever before. I dont have the Bioloid with me to test now but i will give it a go the next couple of weeks.


Thank you! We've worked very hard on that, and as you'll see from the changelog Matt in particular has contributed a HUGE amount to the repository recently. We wanted to be able to develop high performance software for the Bioloid without having to work at the low levels.

One question about the syntax.. I don't recall seeing before a statement in C such as [number] = {..list..}

Code: Select all
    static struct dx_stance s = { 0, { [23] = { DX_NOID, 0 } } };


:?:


That's actually a lot easier to understand if you open it out. Firstly the dx_stance structure looks like this:

Code: Select all
struct dx_servo {
    uint8_t id;
    int position;
};

struct dx_stance {
    uint8_t junk;
    struct dx_servo servo[]; // last item in the list should have id=DX_NOID
};


The 'junk' parameter is to avoid compiler bugs with variable length structures. Otherwise, in the stance, there's an array of servo structures.

Code: Select all
static struct dx_stance s = {
    0, // Junk
    { [23] = { DX_NOID, 0 } } // Initialises element 23 of the servo array of structures to the two values DX_NOID and zero.
};


Because element 23 is initialised to those values by implication the compiler must have allocated 0-22 (i.e. 23 other elements in the list). The startup code created by gcc-avr actually allocates these statically from the 4k RAM in the MCU and initialises them all to zero, with element 23 containing the ID of DX_NOID which the library knows to mean is the end of the array.
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by limor » Tue Dec 16, 2008 10:26 pm

Post by limor
Tue Dec 16, 2008 10:26 pm

thanks
I've only been using C for 26 years.
it's great to learn a new trick
:lol:
thanks
I've only been using C for 26 years.
it's great to learn a new trick
:lol:
limor offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1812
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by billyzelsnack » Wed Dec 17, 2008 6:35 am

Post by billyzelsnack
Wed Dec 17, 2008 6:35 am

You got me beat limor. I've got just 20 something years of C and I've not seen it either.
You got me beat limor. I've got just 20 something years of C and I've not seen it either.
billyzelsnack offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 618
Joined: Sat Dec 30, 2006 1:00 am

Post by BillB » Wed Dec 17, 2008 9:53 am

Post by BillB
Wed Dec 17, 2008 9:53 am

Yipee - now programing the CM5 has become a whole lot easier.

Thank you Matt, Thank you StuartL. Thank you, thank you thank you.
Yipee - now programing the CM5 has become a whole lot easier.

Thank you Matt, Thank you StuartL. Thank you, thank you thank you.
BillB offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

Post by BillB » Wed Dec 17, 2008 10:48 am

Post by BillB
Wed Dec 17, 2008 10:48 am

I have just tried to make the example. But the make failed because it could notfind the file: "trig_tables.c".

I can find a "make_trig_tables.c" file but no "trig_tables.c" file

Any suggestions? Would simply renaming "make_trig_tables.c" to "trig_tables.c" do the trick?
I have just tried to make the example. But the make failed because it could notfind the file: "trig_tables.c".

I can find a "make_trig_tables.c" file but no "trig_tables.c" file

Any suggestions? Would simply renaming "make_trig_tables.c" to "trig_tables.c" do the trick?
BillB offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

Post by StuartL » Wed Dec 17, 2008 11:54 am

Post by StuartL
Wed Dec 17, 2008 11:54 am

BillB wrote:I have just tried to make the example. But the make failed because it could notfind the file: "trig_tables.c".


This probably means that the local gcc doesn't work. The trig tables are calculated at compile time and need to compile make_trig_table.c into make_trig_table.exe which is then used to generate trig_tables.c, used by the gccavr compiler to link in the now "statically" defined trig tables.

Try a manual compilation as follows:

Code: Select all
gcc -o make_trig_tables make_trig_tables.c
BillB wrote:I have just tried to make the example. But the make failed because it could notfind the file: "trig_tables.c".


This probably means that the local gcc doesn't work. The trig tables are calculated at compile time and need to compile make_trig_table.c into make_trig_table.exe which is then used to generate trig_tables.c, used by the gccavr compiler to link in the now "statically" defined trig tables.

Try a manual compilation as follows:

Code: Select all
gcc -o make_trig_tables make_trig_tables.c
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by BillB » Wed Dec 17, 2008 6:47 pm

Post by BillB
Wed Dec 17, 2008 6:47 pm

Thank you Stuart for helping me out with the compile problem. I abandoned trying to compile on my PC - and it compiled first time with no errors on my Mac.

Still getting to grips with the code though. The example appears straight forward and demonstrates how easy you and Matt have made it to access and control the Dynamixels.

Upon running the compiled .hex file on a CM5 I noticed that if you press a key before you reach the infinate while loop you will reach a menu. Upon examining your code library it appears that this menu is part of the "Supervisor" (sounds like something from the Matrix :) ). The supervisor has already proved very useful (for reconfiguring Dynamixel Id's).

My question is that I cannot see where in the Example.c code the Supervisor is involved. It appears to be before the main(). Could you please point out to me where the supervisor is started/initiated.

Apologies if this is a silly C question- my C is a bit rusty after 15 years of neglect.
Thank you Stuart for helping me out with the compile problem. I abandoned trying to compile on my PC - and it compiled first time with no errors on my Mac.

Still getting to grips with the code though. The example appears straight forward and demonstrates how easy you and Matt have made it to access and control the Dynamixels.

Upon running the compiled .hex file on a CM5 I noticed that if you press a key before you reach the infinate while loop you will reach a menu. Upon examining your code library it appears that this menu is part of the "Supervisor" (sounds like something from the Matrix :) ). The supervisor has already proved very useful (for reconfiguring Dynamixel Id's).

My question is that I cannot see where in the Example.c code the Supervisor is involved. It appears to be before the main(). Could you please point out to me where the supervisor is started/initiated.

Apologies if this is a silly C question- my C is a bit rusty after 15 years of neglect.
BillB offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

Post by StuartL » Wed Dec 17, 2008 7:04 pm

Post by StuartL
Wed Dec 17, 2008 7:04 pm

The key hook is done in libbioloid/bioloid/cm5.c at line 21 where cm5_init is set to appear in section ".init8". This gets called before 'main' and therefore ensures that all the library initialisation routines get called before the user application. It's the linker that makes sure that .init8 gets called between .init7 and .init9 and that main() gets called after .init9.

The supervisor has a lot of convenient features. As well as letting you renumber dynamixels you can also reset them (handy if the eeprom gets corrupted), scan the bus for devices, read and write memory locations and (the reason for initially writing it) it checks that your robot complies with the 'robot' definition before letting main() run, making sure you don't end up running the wrong software on the wrong robot or trying to run code when a servo has been renumbered.
The key hook is done in libbioloid/bioloid/cm5.c at line 21 where cm5_init is set to appear in section ".init8". This gets called before 'main' and therefore ensures that all the library initialisation routines get called before the user application. It's the linker that makes sure that .init8 gets called between .init7 and .init9 and that main() gets called after .init9.

The supervisor has a lot of convenient features. As well as letting you renumber dynamixels you can also reset them (handy if the eeprom gets corrupted), scan the bus for devices, read and write memory locations and (the reason for initially writing it) it checks that your robot complies with the 'robot' definition before letting main() run, making sure you don't end up running the wrong software on the wrong robot or trying to run code when a servo has been renumbered.
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by siempre.aprendiendo » Wed Dec 17, 2008 8:59 pm

Post by siempre.aprendiendo
Wed Dec 17, 2008 8:59 pm

It looks great, StuartL&Matt

I think it's the moment to try again programming the CM-5 :)
It looks great, StuartL&Matt

I think it's the moment to try again programming the CM-5 :)
siempre.aprendiendo offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 559
Joined: Wed Aug 08, 2007 9:13 pm
Location: Barcelona

Post by BillB » Wed Dec 17, 2008 9:45 pm

Post by BillB
Wed Dec 17, 2008 9:45 pm

The key hook is done in libbioloid/bioloid/cm5.c at line 21 where cm5_init is set to appear in section ".init8"


Ah - thats the Monkey. Thanks Stuart.
The key hook is done in libbioloid/bioloid/cm5.c at line 21 where cm5_init is set to appear in section ".init8"


Ah - thats the Monkey. Thanks Stuart.
BillB offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 232
Joined: Sun Aug 06, 2006 1:00 am
Location: Hampshire, UK

Post by StuartL » Thu Dec 18, 2008 1:07 pm

Post by StuartL
Thu Dec 18, 2008 1:07 pm

siempre.aprendiendo wrote:It looks great, StuartL&Matt


As you'll see from the changelog Matt deserves most of the credit for the recent work. He keeps talking about creating an account but as far as I know he hasn't done so yet. He is on the distribution list, though.

I think it's the moment to try again programming the CM-5 :)


The functionality available with well written C is surprising. As most people reading this will know we've managed 20-servo forward and reverse kinematics at 40Hz with the biped using the stock ATmega128 at 16MHz.

Of course if you consider the servos as MCUs in their own right a 20-servo biped has 20 x 8MHz MCUs and 1 x 16MHz MCUs. That's a lot of processing power if you can make the software appropriately parallel.

One of the biggest overheads we're seeing are for 32-bit arithmetic (needed for accurate trig) and interrupt overhead. If we can switch to the platform we're thinking of (see other thread) both of these should be resolved natively and even if the clock rate doesn't increase that much (which it should) the overheads should be much lower and hence performance will jump dramatically. We're even now thinking about how we can increase the speed of the servo bus so that we can go faster than 40Hz.
siempre.aprendiendo wrote:It looks great, StuartL&Matt


As you'll see from the changelog Matt deserves most of the credit for the recent work. He keeps talking about creating an account but as far as I know he hasn't done so yet. He is on the distribution list, though.

I think it's the moment to try again programming the CM-5 :)


The functionality available with well written C is surprising. As most people reading this will know we've managed 20-servo forward and reverse kinematics at 40Hz with the biped using the stock ATmega128 at 16MHz.

Of course if you consider the servos as MCUs in their own right a 20-servo biped has 20 x 8MHz MCUs and 1 x 16MHz MCUs. That's a lot of processing power if you can make the software appropriately parallel.

One of the biggest overheads we're seeing are for 32-bit arithmetic (needed for accurate trig) and interrupt overhead. If we can switch to the platform we're thinking of (see other thread) both of these should be resolved natively and even if the clock rate doesn't increase that much (which it should) the overheads should be much lower and hence performance will jump dramatically. We're even now thinking about how we can increase the speed of the servo bus so that we can go faster than 40Hz.
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by brijesh » Sat Dec 20, 2008 6:21 pm

Post by brijesh
Sat Dec 20, 2008 6:21 pm

I have down loaded and been going through it. Great work guys.

When I was looking through code I saw that you are kind of implementing the sprintf() functionality in sio_printf_real(). At least thats what it seemed like with a cursory first look at the code.

Any particular reason?

thanks
I have down loaded and been going through it. Great work guys.

When I was looking through code I saw that you are kind of implementing the sprintf() functionality in sio_printf_real(). At least thats what it seemed like with a cursory first look at the code.

Any particular reason?

thanks
brijesh offline
Newbie
Newbie
Posts: 4
Joined: Tue Sep 02, 2008 7:51 pm

Post by StuartL » Sat Dec 20, 2008 7:26 pm

Post by StuartL
Sat Dec 20, 2008 7:26 pm

What do you mean by "any particular reason"? Do you mean "why in that source file?" or "why do you need a sprintf?".
What do you mean by "any particular reason"? Do you mean "why in that source file?" or "why do you need a sprintf?".
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Next
Next
289 postsPage 1 of 201, 2, 3, 4, 5 ... 20
289 postsPage 1 of 201, 2, 3, 4, 5 ... 20