I just installed the software from a recent Robobuilder CD and found a folder called C coding.

I am not sure if this was part of the first CDs that shipped but it is definitely something worth looking at.

I have been watching the excellent progress you have been doing with your own custom implementation/library for Robobuilder This is nowhere near that complete but I believe it may be of interest to look at it, specially for beginners who want to start coding in C.

The ZIP file includes a full implementation of a C program and you only need to add the exported motion file and compile.

============================================EDIT / UPDATE:============================================This post explains the native implementation of the C code by the manufacturer (Robobuilder).The community members have further extended this code and added support for sensors, etc.The thread for the extended version can be found here http://robosavvy.com/forum/viewtopic.ph ... c&start=15

A document with activities and explanations has also been released. Please look through this thread and you'll find it further down.
============================================

Hi All

I just installed the software from a recent Robobuilder CD and found a folder called C coding.

I am not sure if this was part of the first CDs that shipped but it is definitely something worth looking at.

I have been watching the excellent progress you have been doing with your own custom implementation/library for Robobuilder This is nowhere near that complete but I believe it may be of interest to look at it, specially for beginners who want to start coding in C.

The ZIP file includes a full implementation of a C program and you only need to add the exported motion file and compile.

============================================EDIT / UPDATE:============================================This post explains the native implementation of the C code by the manufacturer (Robobuilder).The community members have further extended this code and added support for sensors, etc.The thread for the extended version can be found here http://robosavvy.com/forum/viewtopic.ph ... c&start=15

I didn't check if this is an update, but this was the basis of the current C code for the RBC which we have worked on.

I simply changed to use AVR Studio and avr-gcc instead of Codevision AVR. This also required some defines to ensure the header files from Motionbuilder could be used. Also used some functions from the Procyon AVR library to help in the debug.

Later I added the routine for the IR controller.

Since then the versions from l3v3rv have added support for the other sensors, but I think still have a strong base on the Robobuilder provided source.

Hi Pedro,

I didn't check if this is an update, but this was the basis of the current C code for the RBC which we have worked on.

I simply changed to use AVR Studio and avr-gcc instead of Codevision AVR. This also required some defines to ensure the header files from Motionbuilder could be used. Also used some functions from the Procyon AVR library to help in the debug.

Later I added the routine for the IR controller.

Since then the versions from l3v3rv have added support for the other sensors, but I think still have a strong base on the Robobuilder provided source.

Yes, still very much based on i-bots port which has a major advantage that you can download the free open source tool chain.

I've added support for the PSD and the accelerometer and a simple terminal based menu interface. It now supports 18 different motions including some soccer related ones which I'm interested in trying to link with PC based webcam.

Yes, still very much based on i-bots port which has a major advantage that you can download the free open source tool chain.

I've added support for the PSD and the accelerometer and a simple terminal based menu interface. It now supports 18 different motions including some soccer related ones which I'm interested in trying to link with PC based webcam.

I had not understood that this was the base of your code.
Every time I installed Robobuilder software I downloaded the latest version from the Website. It was only yesterday that I performed a full install from a CD and discovered this.....

I didn't realize this was already the base of your code.

Anyway, I will keep the post here just as a mention to "the original/official implementation" but I will edit the post to mention your own customized/extended versions.

Thanks and once again I apologise if I generated any confusion.

Hi all

Sorry if I generated any confusion.
It was not my intention at all.

I had not understood that this was the base of your code.
Every time I installed Robobuilder software I downloaded the latest version from the Website. It was only yesterday that I performed a full install from a CD and discovered this.....

I didn't realize this was already the base of your code.

Anyway, I will keep the post here just as a mention to "the original/official implementation" but I will edit the post to mention your own customized/extended versions.

If you'd like I can work on a PC library to make simple BLOB detection.
I have already collected a lot of material as I wanted to do that myself and can code it in relatively short time.
My idea would be to set a colour to look for and tolerance threshold and return the blobs that are found. That's the way the HaViMo camera for Bioloid does it and it's fairly successfully in Robot Soccer.

Also, if there was the possibility to add an instruction to the firmware that let us talk to the servo bus that would be excellent. Something like the PC Control Mode of the native firmware.
I don't really have the expertise on ATMEGA 128 to do it otherwise I would contribute it myself.

Either implement an instruction to change it to full pc control mode or implement and instruction that sends the specified bytes and returns the number of bytes we want (IDEAL).
Lets say, a command like
servobus 0x21 0x23 0x26 0x78, 2
This would tell it to put bytes 0x21 0x23 0x26 0x78 and then return the next "2" bytes received (which would be the answer)
I would need to establish a timeout in case we are querying an in existent servo (which will never return the expected 2 bytes) but other than that it would really unleash a LOT of power in terms of sharing the control between the ATMEGA and the PC.

More complex stuff could then be done without the need to revert back to the native firmware like changing servo id's,setting up PID gains, querying servos, etc etc

hi l3v3rz

If you'd like I can work on a PC library to make simple BLOB detection.
I have already collected a lot of material as I wanted to do that myself and can code it in relatively short time.
My idea would be to set a colour to look for and tolerance threshold and return the blobs that are found. That's the way the HaViMo camera for Bioloid does it and it's fairly successfully in Robot Soccer.

Also, if there was the possibility to add an instruction to the firmware that let us talk to the servo bus that would be excellent. Something like the PC Control Mode of the native firmware.
I don't really have the expertise on ATMEGA 128 to do it otherwise I would contribute it myself.

Either implement an instruction to change it to full pc control mode or implement and instruction that sends the specified bytes and returns the number of bytes we want (IDEAL).
Lets say, a command like
servobus 0x21 0x23 0x26 0x78, 2
This would tell it to put bytes 0x21 0x23 0x26 0x78 and then return the next "2" bytes received (which would be the answer)
I would need to establish a timeout in case we are querying an in existent servo (which will never return the expected 2 bytes) but other than that it would really unleash a LOT of power in terms of sharing the control between the ATMEGA and the PC.

More complex stuff could then be done without the need to revert back to the native firmware like changing servo id's,setting up PID gains, querying servos, etc etc

With regards to the number of bytes returned please note it is not always 2.
IF the instruction returns a packet, it is 2 bytes always.
BUT there are instructions that do not return any packet: in particular the Synchronized Position move and the Runtime Speed Set.
A summary of this can be found on the last page (71) of the wCK manual.
The right column in the table shows which packets are returned by the instructions (and what is their meaning).

Thank you very much for all your work and support.
I will probably port my wCK DLL library and Remocon DLL to your new firmware and merge them in a super class

I think that once support for this is added the only thing missing to make a full, much improved firmware, is a battery charging routine right?
I found some data on that here http://www.edaboard.com/ftopic273063.html but I can't really understand most of it though......

hey l3v3rz

Your API proposal seems a lot better/simpler

With regards to the number of bytes returned please note it is not always 2.
IF the instruction returns a packet, it is 2 bytes always.
BUT there are instructions that do not return any packet: in particular the Synchronized Position move and the Runtime Speed Set.
A summary of this can be found on the last page (71) of the wCK manual.
The right column in the table shows which packets are returned by the instructions (and what is their meaning).

Thank you very much for all your work and support.
I will probably port my wCK DLL library and Remocon DLL to your new firmware and merge them in a super class

I think that once support for this is added the only thing missing to make a full, much improved firmware, is a battery charging routine right?
I found some data on that here http://www.edaboard.com/ftopic273063.html but I can't really understand most of it though......

I've now two variants of theat command, 'x' (lowercase) that waits for and displays a response, and 'X' (uppercase) that just sends with no wait. I'm begining to look at charging but its complex as you must ensure the battery is not overcharged as it can overheat and cause damage - hence my caution.

If also created a second project called robobuildervc that has my .NET code based client.

regards

OK - thanks for that.

I've now two variants of theat command, 'x' (lowercase) that waits for and displays a response, and 'X' (uppercase) that just sends with no wait. I'm begining to look at charging but its complex as you must ensure the battery is not overcharged as it can overheat and cause damage - hence my caution.

there is an added level of complexity here which is the cases where we are querying an inexistent/disconnected servo.

let's say I query the position of servo 1. I send the packet and wait for a response with 2 bytes.
In case servo 1 is disconnected those 2 bytes will never arrive hence locking the program.... maybe a conservative timeout solves this problem. please be aware that depending on the instruction you send the delay between sending the packet and getting the response is different.

Page 25 of the wCk manual details that. I believe the longest is 121145 but they don't mention which units this is....

there is an added level of complexity here which is the cases where we are querying an inexistent/disconnected servo.

let's say I query the position of servo 1. I send the packet and wait for a response with 2 bytes.
In case servo 1 is disconnected those 2 bytes will never arrive hence locking the program.... maybe a conservative timeout solves this problem. please be aware that depending on the instruction you send the delay between sending the packet and getting the response is different.

Page 25 of the wCk manual details that. I believe the longest is 121145 but they don't mention which units this is....

Any ideas what I could be doing wrong? I get this error in the first and second versions of the C code tutorials.

My goal is to get Robobuilder to go through a maze using just the chip and not his bluetooth or the serial port. If it is completely hopeless trying to use the C code from the tutorial, will the library built by the community work for a maze?

Thanks in advance!

I am currently using CodeVisionAVR and cannot get rid of the following error without changing the code. Its like my c files aren't connecting with my main file during build:

Any ideas what I could be doing wrong? I get this error in the first and second versions of the C code tutorials.

My goal is to get Robobuilder to go through a maze using just the chip and not his bluetooth or the serial port. If it is completely hopeless trying to use the C code from the tutorial, will the library built by the community work for a maze?

The codevision early versions compiled all source .c file simultaneously, so there was no need to define variables in files as external. Later versions complile the .c file seperate, so you might get problems as you describe. You need to define the global variables giving a problem as extern in the comm.c , so they are resolved later by the linker.

I have not used codevision, but it should work OK for your project.

The codevision early versions compiled all source .c file simultaneously, so there was no need to define variables in files as external. Later versions complile the .c file seperate, so you might get problems as you describe. You need to define the global variables giving a problem as extern in the comm.c , so they are resolved later by the linker.

I am using CodeVisionAVR 2.04.4a Advanced. So how do I get the structs to be external then? I was able to get rid of all of the errors except for ones revolving around structs. I still have a bit of trouble with scopes in C.

I am using CodeVisionAVR 2.04.4a Advanced. So how do I get the structs to be external then? I was able to get rid of all of the errors except for ones revolving around structs. I still have a bit of trouble with scopes in C.