libavr/libbioloid C library for CM5 released!

[StuartL]

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.

[limor]

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 } } };

[StuartL]

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]

thanks
I've only been using C for 26 years.
it's great to learn a new trick

[billyzelsnack]

You got me beat limor. I've got just 20 something years of C and I've not seen it either.

[BillB]

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

Thank you Matt, Thank you StuartL. Thank you, thank you thank you.

[BillB]

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?

[StuartL]

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]

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.

[StuartL]

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.

[siempre.aprendiendo]

It looks great, StuartL&Matt

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

[BillB]

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.

[StuartL]

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.

[brijesh]

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

[StuartL]

What do you mean by "any particular reason"? Do you mean "why in that source file?" or "why do you need a sprintf?".