This is the newest addition to the family. MALaD is a 3pi robot from Pololu and it is awesome. It's specialty is in using line following and maze solving algorithms to solve those problems -- both of which i have tried and successfully tested using both C and the C++ programming languages.
The 3pi robot makes a great platform for people with C programming experience to learn robotics, and it is a fun environment for ambitious beginners to learn C programming. At its heart is an Atmel ATmega168 microcontroller running at 20 MHz with 16KB of flash program memory and 1KB data memory, enough space to run complicated programs. An extra 512 bytes of persistent flash memory is provided on the microcontroller for data logging or long-term learning applications. The popular, free GNU C/C++ compiler works perfectly with the 3pi, Atmel’s AVR Studio provides a comfortable development environment, and an extensive set of libraries provided by Pololu makes it a breeze to interface with all of the integrated hardware. The 3pi is also compatible with the popular Arduino development platform. We provide a number of sample programs to show how to use the various 3pi components, as well as how to perform more complex behaviors such as line following and maze solving.
Here he is on a simple line-following task using the NXT line map. i will post a video of him solving a maze, a very crude maze, that i designed. As crude as the maze is, the task was still accomplished successfully.
All the excitement! For the past few weeks, i have worked on Java apps, C++ apps, two separate CMS dev. and implementations, an e-commerce site, checked out the new version of the Sun Solaris OS, implemented a couple blogs, built a video preview-system that ties into an Online store, setup and installed a couple SSLs (key, CSR, and, CRT) on the Apache server, and re-configured the network so that my wireless connection/work goes seemlessly. And the week is not over! i still have a host of stuff to implement for a Monday deadline; plus i have been playing with JavaFX.
So i have, of course, ardently begun practicing C++ once again. It is obvious from some (many) of the posts to this blog that i am huge on C++. i had to get back into it because it is a language that i love. So i have been studying and experimenting, as well as giving some serious thought to a particular idea for an application for later down the road. It is a tool that will solve an existing problem, bring peace-of-mind to consumers, and save the users of this industry-specific tool, a great deal of time and money. More on this later.
OMaR is here. i am having a bit of trouble getting the serial cable to talk to the COM port though. Not sure what the trouble is, but i am just not having any luck with it. i have tried everything, so now, i have to step away from it for a while. i will look at it again in the morning to see if i was just making a mistake somewhere or if i merely overlooked something. In the meantime, i am messing around with some C++, experimenting with a few things to see what will happen. Hopefully tomorrow i will be able to connect and thus, load a program for preliminary testing.
What's the status of Embedded C++? The latest information that i can find is dated back to the late '90s. Following is a series of questions about Embedded C++ and its language specification. These questions address the specification at the time, i am not sure what, if any, changes have been made. i still think it is cool though.
-----------
(1) Where is EC++ language specification?
You can find current language specification for EC++ at the page of "The Language Specification". This specification is in the style of amendment for ISO/ANSI C++ Draft Standard which is registered as SC22/WG21/N1037.
(2) Are there any features added specially for embedded programs?
No at all. EC++ specification is a pure subset of ISO/ANSI C++.
(3) Why is 'namespace' eliminated?
Though 'namespace' has no runtime overhead, it is too new to be used widely.
(4) Why is 'using' eliminated?
Though 'using' has no runtime overhead, it is too new to be used widely.
(5) Why are 'static_cast', 'reinterpret_cast', 'const_cast' eliminated?
Though such casts have no runtime overhead, it is too new to be used widely.
(6) Why is 'template' eliminated?
Currently 'template' implementation requires large memory and causes runtime overhaed.
(7) Why is RTTI eliminated?
RTTI features causes runtime overhead even if it is not actually used.
(8) Why is exception eliminated?
It is very difficult to estimate machine cycles for exception handling. This is not suitable for embedded programs.
(9) Can I use STL?
No, you cannot.
(10) Is there any difference between EC++ and cfront?
Basically, EC++ is very similar to cfront 1.2. But EC++ specification is a pure subset of ISO/ANSI C++.
Had to take a little break form OMaR to do some "real" work. No, no, this is not like the previous break, this should only last a little while (if all goes well). At any rate, i was evaluating some robot code in Java in an effort to compare it to C++ to see how much of a stretch it would be to program OMaR in C++; i really don't see it as being much of an issue. Of course, i have not really looked at anything very complicated just yet. The code has primarily been for direction, navigation, and measuring. So the question is: "Why C++?" Well, most of the robots that i have seen featured have brains provided by BASIC (Stamp), C, Java, etc. Being a Java engineer, it would seem like the most likely path for me to take, but i think i really wanted the challenge of using C++ to accomplish the task(s) as well as to do something different. Rest assured however, the next (not-so-experimental) robot will have Java brains.
i have added an early production pic just to give a clue as to what he looks like. Clearly, he is not yet skinned and he is a mini-sumo. However, he will not serve in that capacity. This is just and experimental/learning tool for my robotics studies. i want him to take certain actions in order to do a specific 'non-battle' task(s). i will add some more pics as time goes on, but for now this is it. Back to work for me.
P.S -- There is a change coming that, if you look closely at the pic, you will know what it is.
OMaR -- Object Manipulation Robot development is coming along nicely. i seem to have however, hit a snag. i think there may be a mis-connection somewhere and i am now going to have to reverse engineer it. i'd hate to have to desolder and then resolder, but i will if i must. For the time being though, i am taking a break from working on it. i will be posting some pics representing a tiny timeline of the development process a little later on. OMaR's brains will not be written in Java (that's for our other buddy), but will instead be written in C++. i have not really tested out too much C++ robot code, but i did mess around with writing a little LED blinking program as well as a timer/delay program. Since those programs were successful, i am imagining that the rest will be fairly easy to work out (besides, experimentation is the most fun).
Here we are. i took a bit of time off from making any posts until i recieved my *bot kit; i did! Yes! Assembly is underway and the long awaited debut is drawing near. Now, i must say a little about the plans. The initial direction that i was going in was put on hold (for a little while). i decided instead to work on a different robot and write a different set of instructions for him. With that, i purchased a Mark III kit and began woking on it. The new robot is called OMaR -- Object Manipulation Robot. His objective is simple; manipulate specific objects within his environment.
i have been kidnapped by C++ recently, hence the infrequent blog updates. i have not worked on the Inspection Algorithm in days, nor have i worked directly on any *bot-related programming. i have been giving thought to getting a VexLab robotics kit (see image) and seeing what i can do with it (that is, in addition to *bot). *bot will always be number one as far as side projects go, if i decide to get the VexLab kit, it will just be something else to work on, either in addition to *bot, or following the completion of *bot. Not to worry though, i will be working on *bot tonight in some capacity, but for right now, i will continue to fight with my captor -- C++. Updates to follow.
WIDGETIZE