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 12:00 pm; edited 2 times in total
Joined: 11 Oct 2004 Posts: 1791 Location: London, UK
Posted: Tue Dec 16, 2008 8:40 pm Post subject:
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..}
Joined: 04 Jun 2007 Posts: 349 Location: Thatcham, Berkshire, UK
Posted: Tue Dec 16, 2008 9:10 pm Post subject:
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.
Quote:
One question about the syntax.. I don't recall seeing before a statement in C such as [number] = {..list..}
That's actually a lot easier to understand if you open it out. Firstly the dx_stance structure looks like this:
Code:
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:
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.
Joined: 04 Jun 2007 Posts: 349 Location: Thatcham, Berkshire, UK
Posted: Wed Dec 17, 2008 10:54 am Post subject:
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.
Joined: 06 Aug 2006 Posts: 232 Location: Hampshire, UK
Posted: Wed Dec 17, 2008 5:47 pm Post subject:
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.
Joined: 04 Jun 2007 Posts: 349 Location: Thatcham, Berkshire, UK
Posted: Wed Dec 17, 2008 6:04 pm Post subject:
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.
Joined: 04 Jun 2007 Posts: 349 Location: Thatcham, Berkshire, UK
Posted: Thu Dec 18, 2008 12:07 pm Post subject:
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.
Quote:
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.
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.
All times are GMT Goto page 1, 2, 3 ... 18, 19, 20Next
Page 1 of 20
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
£169.18 inc. VAT
). The supervisor has already proved very useful (for reconfiguring Dynamixel Id's).
