The CEENBoT is a mobile robotics platform developed by the Computer and Electronics Engineering Department (CEEN), now Electrical and Computer Engineering (ECE) through a grant from the National Science Foundation as an educational platform to teach not only robotics, but also science, engineering, mathematics, and technology, usually abbreviated as STEM. The CEENBoT is the official educational robotics platform in the University of Nebraska-Lincoln curriculum in the Omaha campus, and in particular, the Mobile Robotics course offered through the engineering program. In this context the CEENBoT is used as a learning platform for robotic, embedded and mechatronic systems, which also includes their control and software programming.
The CEENBoT was the (at-the-time) next-generation mobile robotics platform which replaced the TekBoT from Oregon State University (see below figure) that was part of CEEN's curriculum. As with the CEENBoT today, its purpose is an exploratory and learning platform to learn electronics, embedded systems, and robotics. It had interchangeable boards that allowed users to upgrade as their skill levels in electronics increased: the default configuration arrived with analog boards for sensing and control, which could then be upgraded with a digital board containing an LCD and Atmel microcontroller consisting of the ATmega32.
The CEENBoT's initial incarnation was the brainchild of CEEN students Ben Barenz and Dan Norman, whom were then joined by students Austin Steiner and Nicholas Wertzberger, also CEEN students. However, Ben Barenz is credited with creating the CEENBoT's initial concept and prototyping through an independent-study course according to reference . The CEENBoT was composed of two separate electronic boards: an interface board for connecting I/O and peripherals, and a controller board composed of two separate AVR architecture based microcontrollers with their firmware entirely written in AVR assembly in order to optimize for overall program size. These were ATmega48 MCUs from ATMEL , which had a very limited 4KB of FLASH, so the firmware had to be extensively optimized for size.
The initial incarnation of the CEENBoT was a step in the right direction, but had some playtime-longevity issues that stemmed from high current draw from the stepper motors and other power-hungry devices (e.g., BJTs in the power supply subsystem as well as the infrared sensor boards) that limited the overall playtime to usually less than 45 minutes under usual load conditions (sometimes less than 30 mintes as the battery aged), and for platform 2.1 as it was called, it was the power subsystem that was the CEENBoT's Achilles' heel, if you will.
The construction of the CEENBoT was quite slick in terms of mechanical (as well as overall) design, and the thing looked just plain cool next to the puny TekBot when it was introduced, but it was also complex and intricate and it was costly to manufacture and maintain (e.g., the spring/shock assembly was pretty sophisticated) by the simple mere fact that it just had too many parts. Also, since many students were also responsible for assembling their own robots, it did not help that many were just not very good at following proper instructions when assembling the thing, resulting in poorly constructed spring/shock assemblies that were either too stiff, or too loose resulting in 'sagging' of the spring/shock system.
This revision of the CEENBoT constituted the first generation CEENBoT was characterized as platform version 2.1 (circa 2008-2009).
The issues that plagued the first-generation CEENBoT were addressed with a significant redesign under the direction of Dennis Deyen, a very talented engineer who was brought in to resolve these issues and redesign the CEENBoT for cost-effective manufacturability. This new upgraded design of the CEENBoT resulted in what is now called platform 2.21. In this version the interface and controller boards were consolidated into one PCB and the two microcontrollers were replaced with a single, still AVR architecture (ATmega324). Actually, the board still did have a secondary microcontroller (ATtiny48), but instead of having equal loads and requiring synchronization between microcontrollers, as was needed with platform 2.1, the secondary microcontroller in platform 2.21 was to provide secondary support (e.g., LCD brightness control, pulse-width modulation for RC servo ports, basic I/O for pushbuttons, etc). In fact, the secondary MCU in platform 2.21 is somewhat underutilized, but this was intentional. For platform 2.21 every attempt was made to reuse what was present in the CEENBoT (e.g., stepper motors and the nice beefy rubber wheels were unchanged, but the IR sensors were redesigned to reduce current draw, while the same metal chassis remained). A nice backlit dot-matrix LCD was also added to the board.
Platform 2.21 worked fairly well. Battery life was now extended from 30-45 minutes (under continuous load) to up to 1 Hour and 30 minutes. In some cases battery life improved up to 2 hours when power management features were written into the firmware, which included a reduced power mode for driving the stepper motors. This was also helped by the fact batteries with higher charge capacity and improved chemistries were now standard, and the combination of these elements helped to extend the overall 'playtime' of the robot. This was particularly important as the robot was evisioned to be used with a variety of devices commonly used in robotics tasks, but which needed to obtain power from the robot's power supply chain (e.g., GPS modules, Analog Sensors, SPI devices, etc). This would have been difficult wit platform 2.1 given its power issues.
As platform 2.21 widespread use began to grow, one of the most common issues raised among users of the CEENBoT and the teachers whom had integrated them into their curriculum was stepper-motor repeatability. The large rubber wheels along with the spring/shock system (which I thought were cool) created difficulty for teachers who wanted to implement distance-rate-time problems using the robot with greater accuracy. The spring/shock system in conjunction with the rubber wheels, which can flex and deform (the very property that allowed it to grip the surface floor properly) made it difficult to mount line-following sensors because this system made it challenging to keep the sensors at a given height as the springs flexed (and wheels) the robot away from the floor's ideal height for sensor mounting and this height was different for everyone and it varied drastically as the robot moved about. This motivated yet another design change of the wheel and chassis as pictured below.
Further design changes were made into platform 2.23. Of notable importance for this particular iteration was the addition of a native TI calculator serial port for connecting a calculator, which with the aid of a TI-Basic program, users could now control the CEENBoT. Previously this required a special-made adapter that plugged into one of the I/O connectors of the CEENBoT. With version 2.23, this connector was now integrated as part of the main circuit board for those that wanted to take advantage of this functionality, since prior the explosion of iOS/Android tablet and mobile devices, the omnipresence of TI-based calculators was pretty much standard. Of course this landscape has changed considerable today (as of 2015).
The expectation behind the redesign/replacement of the original CEENBoT wheels was to improve stepper repeatability introduced by the variability of the CEENBoT's height from the ground by removal of the spring/shock system as well as the first-generation wheel/tire design, which deformed and flexed as the CEENBoT moved. This deforming and flexing is what gave the CEENBoT a considerable amount of grip. However, a very common problem with the new wheel design is that frequent (and NOT so frequent) use of the CEENBoT in bare floor environments resulted in the wheels picking up dust very quickly adhering to the flat wheels precisely because of the new 'flat' wheel design. So while one problem was apparently solved, a new one manifested itself, with the wheels experiencing frequent slippage contributing to a new type of stepper repeatability error that, in my opinion, was worse than the previous wheel design, which is something I've frequently observed in Mobile Robotics I with my students. However, this is a minor setback in comparison to all the design improvements that have been made to the platform to date.
The latest design iteration of the CEENBoT is platform 2.24.
Many people mistakingly believe that I had any involvement in the hardware design of the CEENBoT, but this is incorrect. Before the CEENBoT was redesigned from platform 2.1 into 2.21, there was work being done regarding a graphical programming interface application to allow the CEENBoT to be programmed graphically instead of using a programming language. This tool was being written and engineered by a very talented developer (and student, at the time) named Nicholas Wertzberger, who wrote the core engine and established the software architecture that became the foundation to what was to become (and later indeed became) CEENBoT Commander, but before it became that, it was just called "The GPI".
The GPI did not run in any hardware. To my knowledge it started it out entirely in software form, so a platform was needed to make this possible. This is precisely the time when I was brought in by Dr. Bing Chen and Prof. Alisa Gilmore (also the instructor for Mobile Robotics I) to achieve this task. The goal was to design a hardware architecture that would run the GPI that was still being worked on at the time. While no one had given me any justification as to why, it was stated that the architecture was to be based on ARM, which was a good choice in hindsight, given ARM is well known for good performance-per-watt than most microcontollers of similar caliber and for the processing power it had to offer. So, after some preliminary research, I had chosen to go with an ARM7TDMI architecuture from Atmel (the AT91SAM7S256 to be precise), consisting of a 32-bit microcontoller that supported the good-old thumb instruction set, with 256KB on-board FLASH and 64KB SRM, and was to operate at 55 MHz. (Compare this to the current ATmega324, which was only an 8-bit MCU with 32KB FLASH and 2KB SRAM, running at 20 MHz).
It was at this point that I began to work on the CEENBoT-API, and the point where -my- contributions to the CEENBoT commenced through the development of the API, except it was targeted towards the ARM architecture. This idea of the API was not "inspired" by the factory firmware for the 2.2x platform given that NO factory firmware existed when I started working on the CEENBoT-API for the ARM. The idea of creating the API was inspired by existing software API technology such as the Glide API from 3dfx Interactive , which was the leading manufacturer of 3D graphics cards for gaming before NVidia became king back in the 1990s, as well as OpenGL because I've always had a thing for real-time computer graphics (and still do). The organization of graphics API of the time presented a good design model in building the CEENBoT-API, down to proper, and clear documentation. At that time, I had achieved a considerable amount of work with the ARM version of the API. Sadly, however, creative differences in vision among the engineers and desire to bring 2.1 towards 2.21 into fruition created some unfortunate friction among CEENBoT's engineers. This is a private matter that I won't discuss out of respect for those involved. During this very brief, but tumultuous period, it became clear to me I would not be able to see my work finished, so I moved on and left.
Approximately one year after the events surrounding CEENBoT v2.1 I was asked to take the role of Teaching Assistant for a Mobile Robotics course headed by Prof. Gilmore. The robotics platform being used in the course was a new CEENBoT, what became platform 2.21 based on the ATmega324 microcontroller from ATMEL. This was the first time I got to see the end product resulting from the transformation from the first-generation platform 2.1 to platform 2.21. As was mentioned previously, the controller board was redesigned and consolidated into one. The ATmega324 is an AVR architecture 8-bit microcontroller running at 20 MHz, with 32KB on-board FLASH and 2KB SRAM. As I began to prepare for my T.A. duties for the course I found out that for previous semesters, all students had to go for resources was the at-the-time firmware's source code written by designer of the new CEENBoT 2.21. Unfortunately, there was no documentation of any sort, and students had to write their CEENBoT robotics programs within this already-complicated firmware code, without interrupting the underlying mechanisms such as power management and timing needed to run the steppers as well as the RC servos. Because there was no guidance and no mechanisms for proper software implementation of robotic programs, students really had to 'hack' their way into completing their CEENBoT programming assignments.
Feeling troubled for what at the time felt like an ad-hoc approach to the robotics course, I began to entertain the idea of revisiting my efforts regarding the API to ensure an improved experience for Mobile Robotics during my tenure as Teaching Assistant. So, during the summer of that very same year summer I went to work and revived my API work (for the ARM back then, which was started under platform 2.1 and under Ben Barenz tenure) and now targeting the AVR architecture. I worked for three months, solid, authoring and growing the engine bit by bit. This also included extensive documentation totalling over 300 pages, written in great detail. It was during this period that the 'CEENBoT-API' was finally reborn.
At about the same time, there was new staff working with the CEENBoT platform and the "GPI" was being worked on and improved upon at a staggering and impressive pace. This time by an also very talented engineer (and student, at the time) named Aaron Mills. Other students were also working on it, but Aaron Mills was the lead architect for what became CEENBoT Commander (it was no longer called the GPI). Still, a way was needed to run Commander on the CEENBoT, so while I was working on authoring the API, I was also asked to help with the task of enabling Commander run programs on the CEENBoT, so, as the API was being developed during the summer, it was also written to support this goal. Consequently, the API was dual purposed: it was itself an Application Programming Interface in that users could directly write programs to control their CEENBoTs, but it also served as low-level middleware and hardware abstraction layer (HAL) that sat between Commander and the hardware platform itself. For this reason, the CEENBoT-API was more of an 'monolithic middleware API' system---a microkernel of sorts---serving this dual-purpose.
Thus, to summarize, the existence of the API was driven nothing more than by my desire to provide students in Mobile Robotics I with an improved postive experience. Unlike the first time, it was not something I was tasked to do, but instead something I simply felt compelled to do. My (at-the-time) newly assigned duties as a Teaching Assistant motivated me to make improvements to the course in hopes that it would improve the overall student experience. Everything else, just followed, more or less, by accident. All of this was motivated by my desire to provide the same academic experience I would want for myself if I were in their shoes. That's how the CEENBoT-API came to be.
It is easy to look at someone's work and criticize and pin-point its weaknesses. The truth is that while there were disagreements along the CEENBoT's lifetime and life-cycle changes, the fact remains that there was much about the CEENBoT, that was well-accomplished, beyond the expectations of its original creators. Anyone can be a critic, but very few people can be courageous enough to innovate. All big things have small beginnings, and without innovation and imagination there is no chance for opportunity. Even if Ben Barenz did not remain with the group to oversee the various iterations of the CEENBoT, its existence created a myriad of positive changes and opportunities that have inspired many whom have come in contact with it. The fact is that the CEENBoT was a good idea: before Arduinos, Beagle Bones and Raspberry PIs.
Did the CEENBoT succeed? To answer that question all you have to do is witness the impact its existence has made in the lives of those who have come in contact with it; many of whom I hope will pursue a career in STEM. As of 2015, the University of Nebraska, in collaboration with many partners have hosted six years of the Nebraska Robotics Expo, in which teams using the LEGO robotics platform and CEENBoT robotics platform compete in various educational activities. Hundreds of K-through-12 Nebraska students, team leaders and teachers attend this marvelous event , . All you have to do is look at the faces of the children who get to engage in robotics to see their lives may have changed forever. Each and everyone of us has contributed to the development of the CEENBoT in ways, I don't think some realize, nor that perhaps have had the time to reflect on this impact. I've always tried to, and feel very proud to have partaken on this journey, and to have been granted the opportunity to make a contribution to this robotics platform, no matter how much I sometimes get criticized for its shortcomings. My contribution was to elevate the bar just a bit higher, just like those before me. That is good enough for me, and..., well... I'm okay with that ;)
The CEENBoT-API, has at one time or other, been used by the following:
Local schools include (from ):
 - "Nebraska Robotics Expo at the Strategic Air & Space Museum", by The Strategic Air & Space Museum. Posted: Feb. 19, 2015. Accessed: Jun. 23, 2015. Available Online. URL: http://sasmuseum.com/2015/02/19/nebraska-robotics-expo-at-the-strategic-air-space-museum/
 - "CEENBoTTM Robotics Showcase 2015". University of Nebraska-Lincoln. Accessed: Jun. 23, 2015. Available Online. URL: http://ceenbot.unl.edu/Showcase/
 - Ben Barenz. "CEENBoT. Technical Description & Functional Overview." Revision 2.1. Oct. 21, 2008. Available Online. URL: http://www.mechatronics-mec.org/downloads/061709-CEENBoT_Description_&_Overview.pdf
 - CEENBoT, Inc. Official Website. URL: http://www.ceenbotinc.com
 - "Robotics contest draws 800 students", in Omaha.com. Feb. 22, 2015. Accessed: Aug. 2, 2015. Available Online. URL: http://www.omaha.com/news/robotics-contest-draws-students/article_c6f35b9e-bafa-11e4-9f59-23604681ba46.html
 - "Glide (API)", in Wikipedia. Accessed: Dec. 31, 2016. URL: https://en.wikipedia.org/wiki/Glide_(API)