Society of Robots - Robot Forum
Software => Software => Topic started by: pomprocker on March 11, 2008, 12:41:44 AM
-
I am in a month long c++ class right now and we have to chose a final project. I have 3 weeks to do it. Any ideas for robot code?
-
embedded c is somthin different than c++
you have to find yourself a microcontroller compiler that compile c++ code into machine code
,by the way c++ is about classes and objects and ... stuff you wont need when programing a bot
unless you want the bot to be connected to a computer and do thinking over there
-
It'll be hard to program a robot in C++.
-
I am in a month long c++ class right now and we have to chose a final project. I have 3 weeks to do it. Any ideas for robot code?
Coding in C using Winavr is the best way to start.Search up for tutorials in Winavr.
-
Hi
If there is a computer (laptop,etc...) on board the robot than it can be easy to use c++, it depends on what motor controllers and sensors you have on board.
You might be able to use Microsoft's robotic studio to simulate a robot for your final project (i know its not as fun as building a real robot).
-
oh thats fine. I don't really have time to build one anyway, I would just rather focus on the coding since thats all that matters here.
I would definitely have to use OOP since that is the whole point of c++
-
I would definitely have to use OOP
i dont think you can find an application in robotics if thats what you aim for
-
I am in a month long c++ class right now and we have to chose a final project. I have 3 weeks to do it. Any ideas for robot code?
There is no problem about programming robotics in c++, the problem is that to support some features (exceptions, stl,...) of c++ is necessary a lot more resources (specially memory) than programming in c.
Here you can find some information about c++ restrictions while programming avr with "c++":
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus (no new/delete, no exceptions,...)
BrickOS (http://brickos.sourceforge.net/), for Lego Mindstorms RCX, does support new/delete. There is an interesting new project to program in C/C++ the new Mindstorms NXT, Lejos OSEK (http://lejos-osek.sourceforge.net/).
There are some pretty interesting boards, like gumstix, that support c++ easily. But they are more expensive that the average microcontroller.
-
i'd think that it would be a good thing to have OOP in robotics.
class bodypart {
};
class wheels : public bodypart {
public:
void rotatewheels();
};
class sensors : public bodypart {
public:
int detect(string smell, int distance, int temp);
};
etc..
-
yea but that wont get you extra stuff in robots , maybe you feel its easier for you to write code this way
plus it would consume too much flash as tyhis depends on how your compiler transform this stuff into machine code
i dont see no reason to use c++ while you can do everything in c
-
I am in a month long c++ class right now and we have to chose a final project. I have 3 weeks to do it. Any ideas for robot code?
your in the same boat as all of us.......
You can take in sensor data, but what do you actually do with it????????
-
I think the Player/Stage project would be your best bet for a 'Robot' project in a hurry.
http://playerstage.sourceforge.net/index.php?src=stage
-
i dont see no reason to use c++ while you can do everything in c
This misses the point ;D - you can do ALL things in ALL programming languages but it comes down to the usual stuff re encapsulation, polymorphism, familiarity and ease of use etc. I can do everything in Assembler that can be done in C - but I dont because C is easier. Therefore if stuff is easier in C++ then why not use it?
So for example in C++ you could have an abstract class that represents an LCD display with methods like 'clear the screen', 'back light on/off'. You could then create concrete classes for specific displays that implement these methods in the relevant way.
As for memory constraints - this seems to be somewhat over-egged as a recent why C++ would be bad. Normally in C++ each class has a vtable with an address offset to where the implemented method is stored. So for a class with a handfull of over-ridable methods then this would only require a handfull of values (bytes) overhead.
Consider the case of the servos. In C++ you could have one class and then instantiate two implementations where one of the motors knows that it is 'back to front' compared with the other motor. ie forward on the left servo is the same as reverse on the right servo. The rest of your code could then just say 'go forwards'. Now in C you have to flatten this code out so that all of your code that controls the servos remembers that one of them is back to front compared with the other. So the result is that you end up writing more code in C. So the overhead of the vtables in C++ for each object would be offset by the amount of C code you could get rid of. The whole point of OO is that you can then abstract the implementation so if your servo class had a method:-
void setSpeed(int speed)
where the parameter is a percentage ie -100 = full speed reverse, +100 = full speed forward then you could change your motors to DC/Stepper etc without having to change the main part of your code.
Obviously the controller would freak out if you were trying to allocate and de-allocate thousands of objects per second. But what would be good is to create objects for each sensor/servo at the start of the code.
OO rules !! But its a big step for the beginner.
-
I was thinking of creating base classes and derived classes and member functions like arm ->left_arm->wrist->finger lol then you could just tell the robot> finger middleFinger; middleFinger.raise(3); // for 3 seconds
-
Cool. And thats where OO is great. Assume you had two arms (which I hope you do!!). Then your left arm does everything in reverse to your right arm - ie to put both arms up in the air then one goes clockwise and the other anti-clockwise. Much easier to handle this is OO classes rather than all your C code having to be done twice - once for the left and then again for the right. OO rocks. The advantage is magnified once you have inter-related classes like arm/elbow/wrist/finger.
The other great thing with OO is that classes are 'self-contained' and so could be published to a forum - such as this excellent one - which others could just plug into their own projects. Keep going with the C++ its great. But then Java is even cooler but thats a whole new ball game.
-
Java is my next class in pursuit of my CS degree ;D
Maybe i'll start talking about robot JSPs for webapps ::)
-
You may also be interested in this link http://www.red3d.com/cwr/steer/ (http://www.red3d.com/cwr/steer/) as it shows all sorts of behaviours as used in games, collections of robots etc. It also has a link to a free library (OpenSteer) which is all in C++ to help provide the behaviours that it shows. The animations on the site are cool - and it gives all the logic as to how each one works. I thoroughly recommend having a look (and NO - I didn't have anything to do with it!! ).
-
i have worked a lot with mcu programming and i dont think it can get any easier with c++
, i dont understand what is it in C that you dont like?
i dont think object oriented programming can add a lot to mcu's
anyways when you are in need to do advanced programming you r not goin to be able to use mcu's
you should implement your stuff over the pc, now we can use c++, matlab , java ,,,,,etc
but using it to program a mcu is quite uncommon
-
once you've gone to object oriented programming, you don't wanna go back to process oriented programming. ;D
-
once you've gone to object oriented programming, you don't wanna go back to process oriented programming.
what is it the big deal and ease provided by that so you dont wanna do anythin but object oriented for mcus?
-
Its just one of those debates that will go on forever ;D
-
The big deal with object oriented design goes a couple ways,
- OO is easier to read and think about because you abstract and take things to higher levels so instead of doing a bunch of bit oring and what not you see a representational function call on an object.
- OO is easier to maintain because you can change how the insides of a function or class work if they need to without changing the code that uses it.
- OO helps you to design your project by breaking down the problem and making you focus on one thing at a time.
-
well any compilers for that? (microcontroller ones)
-
can't avr-gcc also do c++? google has the answers...
-
It would be nice to use oo programming for certain things such as sensor objects etc... but it all depends on wether you can get away with it. When each object needs to be assigned a thread so it runs seemingly independantly, it reduces the overall speed for everything else to run, which is a big reason that oo programming isnt used in mcu's because they are not powerful enough. You can try to simulate an oo type of style by using typedef struct's in c:
#include <p18f2525.h>
typedef struct { //define a new "type" structure
unsigned char direction:1; //specify a bit field of 1 - allowing values of either 0 or 1
unsigned char speed:7; //specify a bit field of 7 to allow a speed between 0 and 128
//the above 2 only use 1 byte altogether
} motor; //the structure is called "motor"
void main(){
motor motor1; //create a new instance of the 'motor' struct
motor motor2;
while(1){
motor1.direction=1; //set the direction of motor1
motor2.direction=0;
}
}
As you can see, its quite easy to define an object with properties using c. But I havent worked on adding methods yet, I have a funny feeling that you would need to define them seperately from the typedef. For things like sensor reading and actuator control, I am working on a thread running system, but one that reserves a set speed for the main function.
-
yea that what i was talking about paul.. it seems that OO is not suitable for mcus , ....
-
Whoa guys,
Let me tell you what I do for a living. I work at John Deere in electro-hydraulic steering. You can look up AutoTrac and see what I work on half the time, the other half is under NDA so I can't talk about it. We have an embedded OS for task management (or threads if you will) and we use OO in C up the wazoo.
As for the function calls in OO and regular C do something like this (using the motor from the above example).
void SetMotorForward(motor* this)
{
this->direction = 1;
}
void SetMotorBackward(motor* this)
{
this->direction = 0;
}
void SetMotorSpeed(motor* this, uint8_t new_speed)
{
if (new_speed >= 127) // note that 7 bytes can only represent 0 to 127
{
this->speed = new_speed;
}
}
In this way the implementation of the motor driver (could be PWM to a servo, could be serial output, could be a PWM to high current switch) doesn't matter to the application making the calls to change the motor, it just cares that it has a motor and a speed. As for the thread thing you need a scheduler of some sort. John Deere has made its own, at home I use Linux for my heavier robot tasks, and FreeRTOS on AVR's for every thing else.
One other thing, Instead of declaring those motors (and the storage scope) inside your main() block what you want to do is make an instances.c and an instances.h for all your classes. declare and define the variable of the motor structures in the .c file and then extern them in the .h file so that anywhere you #include the .h file, you will have access to those structures. So the above functions would be a class.c and the structure definition would be a class.h (you would also want to declare the functions in the class.h). but those motor structures would probably need more than just the bit field, they need to know what pins they hook up to and the current status (speed, direction). One of those should go in ROM and one should go in Ram. So what you do is create a Const sturcutres that go in to ROM and have a pointer to static variables in RAM. I'm in the middle of a rewrite on some of my lower level code and if I ever get it all cleaned up I'll show you exactly what I mean.
-
Thats definately useful. I started on my thread scheduler this afternoon, and have some basic threads running such as led's flashing at different rates. I just need to clean it up and work on making the implementation easier.
My idea is to make structured threads (eg. motor_runner) which is where you define the port number etc in. The motor_runner thread reads the type struct data and decides on what the port states should be.
A quick question:
If a create functions like you mention above, can they be called from anywhere or just from the object theyre related to?
Its amazing when you use c++ or java for a while just how much you take for granted.
-
i dont think c++ compilers for mcus are in this world
i did some search and ,,nada
-
If a create functions like you mention above, can they be called from anywhere or just from the object theyre related to?
Well in C there is no such thing as public and private functions, so if you want private functions declare them as file static and don't declare them in the .h file. Example:
MyClass.h
#ifndef MYCLASS_H
#define MYCLASS_H
typedef struct
{
uint8_t var1;
sint16_t var2;
} MyClass
sint16_t getSumOfVars(MyClass* this); //decleration
void doSomeComplexThing(MyClass* this); //decleration
#endif
MyClass.C
#include "MyClass.h"
static void doPrivateFunction(MyClass* this);
sint16_t getSumOfVars(MyClass* this) // definition
{
return (sint16_t)(this->var1 + this->var2);
}
void doSomeComplexThing(MyClass* this) //definition
{
//do some complex stuff for this class
doPrivateFunction(this);
}
static void doPrivateFunction(MyClass* this)
{
//do some other stuff
}
Then you want your instances files
MyClass_Instances.h
extern MyClass ExampleInstanceOne;
extern MyClass ExampleInstanceTwo;
MyClass_Instances.c
MyClass ExampleInstanceOne = { 10, -10000};
MyClass ExampleInstanceTwo = { 5, 30000};
Then generally we make a .h file for the whole package
MyClass_Package.h
#ifndef MYCLASS_PACKAGE_H
#define MYCLASS_PACKAGE_H
#include "MyClass.h"
#include "MyClass_Instances.h"
#endif
And that's the basic model for classes in regular C.
-
i dont think c++ compilers for mcus are in this world
i did some search and ,,nada
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus
-
well just use C coz thats the only thing u can do
-
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus
is this only some libraries you add to your own compilers or is it a complete compiler?
can you please post the link to download this thing
-
http://winavr.sourceforge.net/
Or if you use Debian based Linux just do this:
apt-get install gcc-avr
-
As per all the discussions about structures - well said - that's how C++ works. Early C++ compilers used to work by turning all your code into C and then compiling that. So when it comes to memory overhead then the size of an object instance is just the size of the structure used to store its variables. Each class, ie 'Motor' has one vtable to handle the overridable methods irrespective of the number of instances of Motor you create. So the argument about memory differences between C++ and C just don't stand up. Equally comments about running multiple threads are also irrelevant - if you want to have multiple threads then you could do this in assembler, C, C++, Java etc. Its not a problem with the programming language you choose - its down to whether you want/need to have multiple threads in the first place. If C++/Java make it easier to do so then it doesn't mean you have to use this facility. OK- things like Java often have background threads to help manage the heap space but since you wont be using lots of <code>new(Thing)</code> then this isn't a problem - and is probably why a lot of the mcu compilers don't support <code>new</code> - so that they can save all the overhead of managing the heap. But surely thats the same in C as well - just try using the C <code>malloc</code> command and see how much support you get.
-
Exactly why you make an instances.c and an instances.h
Essentially in an embedded environment you should already know how many instances of an object you need. For example, you should never have to dynamically add sensors, or motors, or servos at run time.
-
i dont think c++ compilers for mcus are in this world
i did some search and ,,nada
Actually they exist and are popular in the professional world: Look for FreeScale.
Essentially in an embedded environment you should already know how many instances of an object you need. For example, you should never have to dynamically add sensors, or motors, or servos at run time.
When it comes to robot hardware you are right but when it comes to interactivity with the environment you might not know how many variables are out there. Last year I did some experiments by connecting my umpc to a microcontroller. The controller was nothing but an interface between the robot hardware and the umpc. then I connected I camera and used Artoolkit to make the robot scan the environment and collect random small objects(that I choose) in my room. I programmed the umpc in C++ and every single object the robot identified (from my bed to a piece of paper) became an object. Then I had a methods for each one of those objects to compare them to the target objects. And finally I had a separated set of methods(outside a class) for serial communication between the umpc and the controller. Unfortunatelly I am still working with the comparation algorithm(there are so many angles). Whatever, it is just some nerdy project that I work when I have too much spare time. My point is that C++ is a great language for robotics. I think C# would be even better but it is only for windows and it is still way too heavy for the usual one-chip mcu(that is because I like C# syntax the most). C is still great. You can "pretend" that you are using c++ and oop by structures and functions related to those structures(I do that quite a lot).
-
Well if you need dynamic memory you are going to have to use a chip with memory management. That pretty much goes without saying. I think you are correct that C++ is probably the best compromise between performance and ease of use for robotics on the higher level.
My thoughts on C# are that the syntax is ok, it's just about the same as Java so no big deal there. But I personally detest using any language that does Garbage Collection. I think it's the biggest crutch that was ever made.
But I'm strange like that :P
-
Actually they exist and are popular in the professional world: Look for FreeScale.
Freescale is a company,can you provide the link to that compiler?
is it a reliable one?efficient in using mcu memory?
-
anyways if you guys are interested to make it easier for you to program processors u gorra check the matlab embedded toolbox
,it has a toolbox to compile matlab code into machine code,,
matlab programming is awesome,,compared to lots of languages ,including c++.
still not sure if this toolbox supports avr and 8051 cores mcus
i think its basicly made for DSPs
-
Yea they tell us at work that Matlab and model based design are the wave of the future.
I don't buy that either. It's a performance sink in a big way. We have a division that only uses model based design and they use the same processor that we use, except we have nearly 5 applications to their one per processor. It may be better for rapid prototyping or limited production solutions (such as hobby robotics) but I don't think it's really going to take off that much in the industry.
I'm not meaning to be contrary though... if you like it, use it.
-
Actually they exist and are popular in the professional world: Look for FreeScale.
Freescale is a company,can you provide the link to that compiler?
is it a reliable one?efficient in using mcu memory?
It is a company. A famous one. And they have c++ compilers for their micro controller. But you have to buy them. Honestly you should at least do some research first.
My thoughts on C# are that the syntax is ok, it's just about the same as Java so no big deal there. But I personally detest using any language that does Garbage Collection. I think it's the biggest crutch that was ever made.
That is my problem with c# as well. Garbage collection is garbage. But the code is easy to read and write though(and I like intelisense, it is a nice feature). I use it (and Java) for quick prototyping or small programs(usually not related to robotics). But only for that.
-
well its not model based design nesecerally
i was talking about the matlab programming language
it provide real ease compared to the others
adding to that that the basic element in matlab is a matrix
which is what commonly used in robotics
-
Does anybody have any opinions on how large a return stack should be kept?
Im in the process of writing an interrupt based kernel in 99% c. This involves copying the hardware return stack to memory. The stack is usually 31 levels deep allowing for nested functions, if conditionals, while loops etc.. of up to 31 levels.
Each thread must have its own software based return stack (stored in an array) to remember where it is upto when its thread yields to another one. So when the thread yields, the program counter is copied to the top of the hardware stack. The entire hardware stack is copied into the threads own software stack array. When the thread is allowed to resume, its software stack array is copied back into the hardware return stack and a return command pushes the top level of the hardware stack back into the program counter so it resumes from the position the thread yielded it.
The threads are interrupted when timer0 overflows. This is when the hardware stack is copied. It allows all threads to run for 256 clock cycles before yielding (it can be altered by setting divisors if necessarry). The timer1 module is used to set priorities and that thread will not resume until its defined priority is equalled or exceeded based on timer1 (this is controlled by a simple process scheduler).
The problem involved in this is that it means that to allow for the maximum 31 level returns, each thread must have three arrays as such: ubyte[31] hbyte[31] lbyte[31] because the stack is 3 bytes wide by 31 deep. That means each thread uses 93 bytes of ram before its actually used to do anything. The uc (pic18f4520) im using allows 1536 of ram, but its soon going to get used up with a few threads and typedef and variables.
Obviously the memory usage of the threads can be greatly reduced by only allowing a return stack of 10 levels. I cant think of any time lately that ive gone above 5 levels deep in returns which brings me back to the question above.
What does everyone think is acceptable for nesting depth?
-
How long is a piece of string...
This will depend on the maximum nesting of subroutine calls in your main code. Ifs/whiles etc should make no difference.
BUT the other thing is that all variables declared locally within the methods/subroutines will normally also be allocated within the stack. There will also normally be an overhead per nested level of subroutine where several key registers are pushed/popped. The exact implementation will vary from one compiler to the next.
Consider:
void mySubroutine(void){
char buffer[256];
do something;
}
The buffer variable space may be allocated on the stack or it may be allocated on a separate virtual heap stack tracked via some other register.
Also if your subroutine has parameters that are passed by value, rather than as a pointer to the original values, then these are normally also copied to the stack.
ie
void mySubroutine(char *args){
do something
}
will just pass the address of the original array of data but
void mySubroutine(char args[256]){
do something
}
may well copy 256 bytes of info to the stack.
If you are not careful you will spend most of your time copying stuff in and out of the stack rather than running the code.
Rather than copying stack contents into C variables ie ubyte[31] you may be better off thinking about how many tasks there would be (maximum) and then chopping up the stack space yourself. Look at the generated assembly code to see how the stack is managed and then swap the contents of the stack register when you swap tasks. ie dont modify the contents of the stack, rather change the actual stack pointer itself to a unique location for each thread. Most C compilers will also keep variables for the top and bottom of the stack (to detect stack overflows) so you would also need to change the contents of these variables yourself at each task switch so that a given task works within the subset you have given it. If you dont do this then if one stack gets bigger than expected it will overwrite the stack for another thread without you knowing until you switch to that tasks and it crashes horribly. If you do it properly then you should get the standard C stack-overflow messages.
This is much more efficient as you can swap tasks by changing a register and a system wide variable or two (irrespective of how big the stack actually is). But it does involve you understanding exactly the assembler that is generated by your C compiler and then adding some assembler code to do the switching. Look at the symbol/map files - as they may also help located where some of this info is stored.
I did this about 15 years ago for a commercial application in MSDOS for IBM cash registers monitoring multiple petrol pumps - it is possible - can be very efficient - but requires some in-depth jiggery pokery. If you dont have a good understanding of the processor architecture and assembler then you may find it a big challenge.
Good luck
-
Ive already written it. (about 2hours writing code, about 100 hours researching and reading the datasheet and testing code snippets on the hardware stacks).
The hardware stack on the pic18 for return pointers is only 31 deep anyway so i dont think its large enough to just use pointer locations for many threads on it. I could implement a larger software stack (If i had some external sram fitted, It could be as large as that is) and just point to that, but then you hit the problem of 1 thread overflowing into another etc... I also have a couple of plans for communicating between threads and the global environment but I need to do a bit more work on this aspect (It needs to follow my object model). I think that each thread is going to have a corresponding struct ##name_global_variables.variable_name and also variables that are private to the thread created with the ##name_1.
I need to do a lot of work on assigning extra functions to the threads, but this is likely to be fully pointer based.
I also decided before I went to bed that since the copied stack pointer is only 5 bits long, and im going to be using probably another 5 bits for interrupt priority settings then I can use the remaining 5 bits to select a return depth with 1 bit left over for some possible future boolean allocation(like thread_active). It just means having to configure the threads a bit more before they run. I'll post the code tomorrow when im sure that its working properly
-
Here is the first version of my multi tasking system on PIC18's.
It only has 1 thread configured to run at the minute called logic_thread, im working on making defining threads easier, its priority driven with threads executing according to a priority set against the timer1 module. The timer0 module interrupts the thread after 256 instruction cycles and checks to see if any other threads are due to run. The threads will only run when their predefined priority time comes up, there is a priority of 0 that can be set so threads alsways execute when the scheduler gets to them. priorities go down to 31.
Each thread stores its return stack in software so when a thread is interrupted it stores where it was upto so when its priority time comes up again it can carry on where it left off rather than starting from the top of its function.
Lessons learnt:-
Microcontrollers really need to interface to external ram. - im hopefully going to add this into my model
To make threaded systems that can be easily used by other people, you really need to develope a higher level precompiler that includes the usual c commands along with a few other bits. - the reason i decided to do this was because most other simple threaded systems seem to need you to insert extra bits in the threads to allow it to break out, the interrupt driven style that i have made needs nothing extra adding into your thread, it just takes a lot of setting up at the minute.
You can spend hours trying to find where the bug in your code is causing erratic behavior until you realise that the code simulator has a problem with the timer overflowing more than 8192 times?
Having to actually monitor memory stacks, return stacks, and sift through stupid amounts of assembly gives a much deeper understanding into how things work in the PIC
When at first you think that 1 thread has taken up an immense amount of memory, its time to check the memory usage gauge with a blank main.c document only to realise that an empty main file with just the P18f4520.h included takes over 300 bytes, and its not really that bad after all. If ever you start to run low on memory, maybe its time to sift through the standard header file used and make your own with only the things in it that you need.
This is an ongoing project which needs a lot of cleaning up yet, and maybe think about making a higher level language to make objects threads easier to use....