Behavior Based Robot Programming
photomankc
Posts: 943
Has anyone implemented or know of a full implementation of the model of robot programming in "Robot Programming : A Practical Guide to Behavior-Based Robotics" for the Propeller (or anything else). I have a pretty decent idea of the concept but I always do better looking at a concrete implementation of something than just the abstract. I'd like to start my early bot on the basis of that model but I don't see a lot of code posted out there anywhere for it. Mostly links to the book or journal articles I can't get to.
I think it may be a bit harder in spin since I can't pass objects as variables and I can think of a lot of ways that would be very helpful. Maybe I need to step up and get serious with PropGCC.
I think it may be a bit harder in spin since I can't pass objects as variables and I can think of a lot of ways that would be very helpful. Maybe I need to step up and get serious with PropGCC.
Comments
I am know nothing of robots or what you have in mind for them but I will make the observation that if you really need to pass complicated objects around (methods as well as data) for the techniques you mention then C++ will indeed make it a lot easier to manage and propgcc can handle that.
However, it also sounds like these algorithm/data could get quite large. It happens that propgcc generates fairly fast native Propeller instructions but as a result the generated code is quite large. Thirty two bits per instruction compared to the byte codes of Spin. So don't expect to fit much functionality into the Prop with that unless you are prepared to acquire/build a Propeller system with external RAM, which then will not be so fast. The Prop II will be better suited to C/C++ code.
My suggestion would be to use a little ARM board to run your algorithms on. Something like a Beagle board or Panda or ISEE IGEPv2. Hopefully soon we can get hold of the ultra cheap, small and simple Raspberry PI boards.
As these boards are small you can build them into your robot. Hook them up to a Prop via a serial link. The Prop(s) take care of the real-time I/O stuff, sensor monitoring, servo driving etc. Tasks for which it is designed. The ARM board takes care of the higher level behavioral algorithms with mmemory and speed available to do whatever you wish.
But now you have a proper Linux based board in which to experiment and develop your code you have more options for languages. For quick development experimental turn around C and C++ is complicated and slow (That is in terms of compiling and building). So an interpreted language like Python will give you more instant feedback on the correctness of you experiments.
Also, consider that when experimenting/developing complex code like this it is great to be able to edit and run the same code on your PC as on you target robot. You can test a lot of things there before crashing your bot into the walls:)
I knew that program size would be an issue for PropGCC. Maybe the Prop-2 will be out by the time I actually have a chance to get serious about really developing it. 126K would go a LOT further.
Heres a link to the bot I'm building. It's going to take a while to get all the physical construction done really anyway:
http://forums.parallax.com/showthread.php?136483-Scratch-Built-Robot-In-Progress
Ardinos may be cheap, but Propeller boards aren't exactly expensive.
It's CODE that's expensive and mixed systems mean two (or more?)
different programming languages to work with.
If these were being built in high production numbers, maybe the little
bit of savings on hardware would makes sense.
But for one-off systems, I don't see it.
I just like mucking with new stuff too so there's that angle as well. The code that IDBruce released is a good starting point for getting going on a prop based stepper drive and if I can port my PASM I2C master code to also act as a slave then another issue is delt with, but that still leaves adding and interfacing A/D hardware.
The Propeller on the other hand makes a fantastic sensor control system. 8 processors can all monitor sensors in real time and calculate useful values for higher consumption and without all the headaches of servicing them in series. I see it as tools for tasks, and as a hobbist that means I don't have the economy aspects to worry about so much. A simple alarm system for a $150 could do what I have planned here better and more reliably but that isn't the point.
Thank you. Very cool project site there. At the outset I can probably do as he did and use behaviour subroutines vs passing complex data around. It's going to be a banner day when this puppy can sense and back away from a wll so my needs for now are pretty simple.
ETA: I just was looking at his follow me Propeller Hex Crawler. Perhaps I was way over-complicating the issue in my head. He has a human tracking hexapod implemented in a couple pages of light code. Behaviours are seqential subroutines. That's probably enough for me to start experimenting. C++ would be nice for encapsulating things but this is doable without all that obviously.
Horses for courses.
Whilst we would all like to keep things simple and regular it may not always be reasonable.
Typical example is how your desktop PC has an x86 CPU for general purpose number crunching and
a seriously different processor for accelerating graphics. Not to mention that 8 bit micro-controller that was hidden away in
your keyboard for decades. Or now on ARM systems like phones they have a regular ARM processor and a DSP unit.
If your Prop based robot really needs a big space to put your latest search and destroy algorithm in it might make
more sense to bolt on am ARM talking over serial to the Prop than to rebuild your Prop board with external memory or trying to
use the ARM for lots of I/O bit twiddling.
Quite so. Much nicer to have the same language everywhere. I might suggest that is why in the embedded systems world there
is C/C++ everywhere and why there is a big push to get C/C++ on the Propeller. Embedded shops see the multiple language thing as a serious complication to their work and may dismiss the Propeller because of Spin.
As a case in point, If you look at a typical modern day traffic light controller in Scandinavia it has an ARM processor taking care of
higher level logic, communications tasks etc. That ARM is surrounded by PICs/AVRs performing all kind of peripheral tasks, sensor monitoring,
LCD panel driving etc. No matter how small those peripheral chips are they are all programmed in C.
Anyway, for my hobby projects I'm quite happy to spend the hours learning a new language or processor if they are genuinely innovative in some way.
Hence spending so much time with the Prop and PASM and Spin. And just now my attention has turned to, wait for it, Javascript for the host end processing/display.
I know, Javascript is not new, but there are things you can do with it now that you would never have imagined when JS was a browser only thing.
cavelamb,
I have been working with the propeller chip for almost two years now and what is interesting in your statement is that I have reached the opposite conclusion, i.e., when building something complex, mixed processor systems are so much easier than single processor systems.
The propeller is great for low level I/O but its lack of memory and native C/C++ support (as well as usable floating point) makes it hard to use for application-level s/w. In robotics code, in particular when experimenting with implementing new algorithms, you need memory and usually floating point. It is not that you can't implement this in SPIN (or pasm) but you now have to worry about the algorithm part and then worry about the implementation details; that's not a good thing.
I have build (and still working on) two robotics systems (mostly for education/research at a University) and in both cases I started planning to use a propeller only and ended up adding more processors. On one extreme, we have an autonomous quad-copter that is using two propeller chis and a chipkit Uno; another ground robot is using a propeller board and chipkit Max. In all cases, the propeller(s) are doing the low level sensor I/O, light blinking, RC decoding, PWM generation and the Uno/Max boards are running 'traditional' robotics s/w algorithms using two and three dimensional arrays and floating point; effectively, you get the best of both worlds!
Again, I see the opposite; if I will be building something in high numbers, the effort to squeeze everything in one board/CPU makes sense, but for one-off systems, just stick any number of appropriate processors to make it work, since cost doesn't matter.