My Least Favorite Computer

When William Shattner started doing Commodore Vic20 commercials, I found that I just had to have a Vic20.  It had nothing to do with Captain Kirk of course, but those comparison commercials wherein the Vic20 features were compared to other computers was very convincing to this 14 year old.

I saved every penny from my paper route and got $350 to buy the "Wonder computer of the 80's".  I got the tape deck unit with the Vic20 and a few books and progs.  Without the tape deck, it would have been little better than a gaming console.

Fast forward through the 80's and my intense love of playing and creating games continued.  The Commodore 64 was purchased by my wife and I and we used it to create college reports.  My first good paying job I got an used Amiga1000.  It was a wonderfully frustrating machine as any changes to it were expensive.  Besides, the IBM PC era for the home had finally arrived. 

We sold the Amiga and bought an Amstrad PC-20.  It was affordable, had EGA video and sound and two floppy drives - no hard drive.  It did not run Windows but included GEM which is similar to the black and white Apple Macintosh OS.

Improving on the machine meant opening the flip top and plugging in ISA PC cards.  There were only 2 slots.  Oh yeah, and the lid did not close after a card was plugged in.

It was a strange PC and we didn't have it long before buying a full IBM PC compatible with memory, VGA graphics, Soundblaster, a CD reader and all.  Overall, I've enjoyed every computer that I've ever owned - except the Amstrad PC-20.

My Android Apps Privacy Policy

Some Android app repositories have changed their submission process to require a privacy policy.  This post is in response to those requests and to address concerns of some users.

I create Android games and other programs as a hobby.  As a result, I have no interest in collecting personal information and using it.  My interest is in game creation and development.  There is a great deal of responsibility involved in managing personal data.  

I use third-party libraries in my games to provide social interaction.  Google Play Services is currently used in most of my games, and Swarm is still used in at least one older game and thus examination of their respective privacy policies may be beneficial.  

Most of my games have location sensing flags set to support targeted advertising - this is a requirement by many advertisers.   To those that enjoy my software creations, thank you, and rest assured that I do not collect personal data and currently have no use for it.

Bash Shellshock Vulnerability - What's the threat?

Below is a link on github wherein the Bash Shellshock vulnerability is being discussed:

https://gist.github.com/anonymous/929d622f3b36b00c0be1

For the non-technical, what is being shown by posters is that the now termed Shellshock vulnerability is now being used.  Attempts to use the vulnerability are being captured in log files - particularly note the UserAgent notes in the log files as they illustrate the attempt to use the vulnerability.

What is particularly alarming is just how easily this vulnerability can be used and also what appears to be an attempt in the log files to search for vulnerable machines.  The "grep" command on Linux is an advanced and complex search command that can be used to execute very specific searches.  Note the comments in the link where grep is mentioned.  A list of websites with the vulnerability would be valuable indeed.  However, so would a list that contains any type of machine with the vulnerability. 

This vulnerability affects much more than just websites - MythTV boxes and other entertainment boxes running Linux (Boxee?  TiVo?) could also be affected.  It could even affect security cameras or for that matter any device that has an available Bash shell.

This is a particularly scary vulnerability because of its ease of use and power.  Using the Shellshock vulnerability, it is possible to obtain files that were supposed to be limited to root access.  In other words "Got Root?" isn't a question - it's  an assumption.

Oh and by the way, Mac OSX systems are also affected since they also have Bash available.

Imagine a SCADA running Unix at a steel mill and it is connected to the Internet for customer convenience.  Naturally, there is security in place to prevent anyone except customers from accessing the SCADA webpage data.  However, with the latest Bash vulnerability anyone that can type a simple script can access that SCADA.  Who cares you may ask?  Its just production data.  Why would anyone want it?

The problem, in this case isn't that data may be copied, as in credit card numbers theft.  The problem is what could be done if someone on an outside connection can control that machine?

Of course the attacker would need to be running the actual SCADA software to interact with equipment, or would he?  Could he just directly access the database that the SCADA uses to keep track of and issue equipment commands?  Could he access the database and change the product recipe? 

But who cares about a steel mill right?  Well the issue is that Unix and Linux based SCADA are used in a wide range of industries from power generation, oil production, transportation, semiconductor fabs, and  utilities.  All it takes is one machine connected to another machine connected to the Internet and the scenario depicted above can become very real. 

There's no need to panic - yet unless you happen to be in IT and manage systems that run Unix, Linux, or Mac OSX.  On the other hand,  security research Bruce Schneier is calling the flaw "catastrophic."

If important systems, besides just commerce and finance, do not get patched before a Shellshock worm is released, we could have serious problems that would make the finger vulnerability, the Morris worm, Heartbleed, and the Code Red virus, seem almost innocuous in comparison.

2007 Nissan Sentra accelerates by itself!

On August 22, 2012 I posted about our 2007 Nissan Sentra attempting to accelerate out of control in reverse. We had it checked by Nissan mechanics and they found nothing wrong or in their log. Yep your modern car has a log file in it.

I was even shown that slamming the brakes automatically overrides the accelerator even if your foot is on it. That's a good safety and so I figured if the problem ever resurfaced, we would still be safe - just slam the brakes.

Yesterday, 9/11/14, our 2007 Nissan Sentra accelerated all by itself! It went into runaway mode again but this time in drive!

We were in a McDonalds drive through and had just placed our order. The car was in park. The AC was on but not on Max AC. I put my foot on the brake and shifted to Drive. The car lurched forward but the brake held it. My wife Kelly exclaimed, "what are you doing?" 

This time I was ready except I had no camera or smartphone. Damn!

I said to Kelly, "Look! There it is! Look at my foot, it's not touching the gas at all - just the brake. Look at the tach. It's racing up to 2500 and coming back down. It's in drive." 

Kelly asked, "What do we do?"

I said, "Watch this!" I slammed the brake to the floor as hard as I could. Everything went back to normal. I said, "see that mechanic was right. Just slam it to the floor (the brake)."

"Are we safe," asked Kelly.

I answered, "I guess so. If anything happens we just slam the brakes. Nissan will never find this. It wouldn't do any good to take it in; they couldn't find it the last time."

"You sure we'll be okay", asked Kelly.

"I don't know but I'm putting it online so that it's at least documented somewhere if anything happens. At least we have a brake override to kill it?"

Kelly asked, "do you think Nissan knew about this?"

I answered, I don't know but at least they planned for it. I wonder if they found it in testing and added the override because they couldn't find the bug causing it?"

-- end of story - 

I think it likely has to do with the air conditioning. The engine has to compensate when the air conditioner kicks on or stall. It is likely that the software has an endless loop that occurs when the AC kicks on under just the right circumstances. Or it could be an integrator problem.  When trying to regulate speed electronically, oftentimes a PID loop is used.

PID stands for Proportional Integral Derivative.  To put it simply, an equation would look at the speed command for the engine, see how far off it is which is basically the proportion, and then use integration to consider prior responses and use derivative to offset the integration and proportion.  That is an extremely simplified explanation of PID.  If you understand mathematics pretty well, look up PID equation on Wolfram Alpha to help understand the relationship between the P the I and the D.

The problem that can occur is called integral windup.  What happens is that each new addition to integral becomes progressively larger until derivative is no longer able to offset the integral.  To put it simply, it's like dividing one by zero.  Of course it is undefined but if you instead divide by a number as close to zero as you can possibly get, such as 10 raised to the minus one million, then the result of the equation is enormous.  Just imagine that number being applied to the accelerator of your car!

I used to always include a safety clamp in software for the PID result just in case of integral windup.  Some people frown on such practice and are of the opinion that if the PID loop is setup properly then there's no need for a clamp.  I strongly suspect that the software used in our 2007 Nissan Sentra and in many other cares is the result of such debates and probably lacks and software clamp for the PID loop.

At least Nissan has an override, although scary. I wonder about the other car companies...

Basic Atom Pro Timer Interrupt

While working on obstacle avoidance code for the autonomous mode, it became desirable to have a way to detect the amount of time that has expired. This is especially useful for detecting how long the robot has been stopped and how long it has been walking in a given direction.

Adding a timer interrupt in Basic Atom Pro code is actually quite easy - there is an example in the Basic Atom Pro manual.

The following two commands configure a timer interrupt on the Basic Atom Pro:
ONINTERRUPT TIMERAINT,handle_timerA
TMA= (TMA & 0xF0) 0x4 ;sets timera to increment once every 256 clock cycles

Here is the code that will run each time the interrupt is triggered:
handle_timerA
currenttimerval = currenttimerval + 1
resume

In the code listed above, TIMERAINT is an overflow interrupt and when this interrupt occurs, handle_timerA routine is executed and returned from by the resume command - the routine just counts 256 clock cycle clumps as one interval called currenttimerval.

Here is the code that starts the timer timing:
ENABLE TIMERAINT

Simple stuff. Stopping the timer is just as easy:
DISABLE TIMERAINT

So, we now have an easy to use timer that we just enable to start it ticking and disable to stop it. By the way, there is no explanation in the Basic Atom Pro manual regarding TMA other than a comment in a code listing. For an explanation on TMA, it is necessary to look in the h83664 manual. At first glance, it was a little challenging to understand but as with many things it was just a matter of staring at it long enough until the picture became clear, so to speak. There is also a comprehensive tutorial on the Lynxmotion forums that helped.

It wasn't until I stumbled upon the interrupts tuturial posted by a user in the Lynxmotion forums at http://www.lynxmotion.net/viewtopic.php?t=3496 that I found a caveat about using interrupts on the Basic Atom Pro. It seems that serout commands on the Basic Atom Pro are not always reliable when using interrupts. I confirmed this to be true after watching the Midnight Prowlerbot spasm and twitch in a random fit instead of walking as programmed. At first, I thought that maybe I had done something wrong in my code. After putting DISABLE TIMERAINT before every serout command and ENABLE TIMERAINT after each serout command, I found that everything worked fine. The robot walked as expected. The timer worked.

Unfortunately, enabling and disabling the timer interrupt before each serout command really affects accuracy of the timing. For instance, if the robot is instructed to perform a command that isn't executed each loop, such as an attack sequence, then the amount of time that the timer has been disabled has been changed when compared to just a walking sequence. Although this is not a crucial problem for things such as telling the robot to stop for a few seconds, it could be a problem if more accurate timing was needed.

Since I found the enable/disable interrupts before and after each serout to be an annoyance, I decided that it would be best to simply not use the interrupt. Instead, the Midnight Prowlerbot now counts the number of steps that it has taken when attempting to avoid an obstacle. For instance, this allows the robot to walk left three steps when any forward obstacle is detected instead of attempting to walk left for two seconds. In the future, more complex avoidance sequences than the left turn algorithm will be attempted.

CMUCam2+ with Basic Atom Pro continued...

After initializing, calibrating, and configuring the CMUCam2+, it is now ready for service to do object tracking, motion sensing, or even histogram capture. The code samples provided use the CMUCam in polled mode so that the CMUCam is not continuously dumping information the Basic Atom Pro. This allows the Basic Atom Pro to request the data when ready, rather than using interrupt code.

Since the CMUCam does not work with the hardware serial port functions (hserin,hserout) on the Basic Atom Pro, it could be a little tricky using an interrupt and using the software serial port functions to get data that is being sent as fast as the CMUCam can send it. Since the Midnight Prowlerbot is now using a connection to a laptop from the CMUCam instead, data is no longer polled, but is sent as fast as possible and the laptop buffers it up. The code presented is code that was used on the Midnight Prowlerbot when the CMUCam2+ was connected to the Basic Atom Pro instead of a laptop.


To get a color using the following code, the Midnight Prowlerbot generated a sound which permitted the user up to 10 seconds to place the object directly in front of the CMUCam. After the ten seconds expired, a sound was generated to let the user know that the color was being obtained. A final sound occurs to let the user know that the color was obtained. Here is the code:



The tracking code is very simple but is in a seperate subroutine for convenience. Note that since raw mode on the CMUCam2+ was configured for raw data that the data obtained through tracking will not be readable. The benefit of the raw data mode is that the TC response length will always be the same, whereas in non-raw mode, or readable mode, the response length varies depending on whether the values returned are single digit, two digit, or three digit. here is the code:


And finally, here is the main code that was used. Please note that functions such as searching for the object being tracked and other functions have been removed because this code is just showing how the previously posted subroutines are being used together to make the CMUCam2+ usable with the Basic Atom Pro. Besides, I found that using the CMUCam2+ built in tracking was much faster and more reliable than trying to respond quickly enough to overcome the communications delays between the CMUCam2+ and Basic Atom Pro and track reliably.

Instead, I eventually just used the built in tracking to automatically move the pan and tilt servos and acquired the values through the TC responses. This allowed tracking to be responsive and allowed the Basic Atom Pro to also be responsive since it wasn't bogged down trying to do tracking, which required even more communication. Here is the code:

Using Basic Atom Pro with CMUCam2+

Since formatting program code within the blog editor is such a challenge, I'm just including snapshots of the code. I would prefer otherwise so that it would be easy to copy-and-paste the code, but formatting the code properly for display just does not seem to be possible. Note that all of the code snippets were developed and tested on version 8.0.1.0 of the IDE for the Basic Atom Pro. Click on the code snippets to see the printout full-sized.

Here is the code that I used to initialize the CMUCam2+:

Next is calibration of the CMUCam2+ and here is the code for it:

Next, the CMUCam2+ is configured as follows:

At this point, the CMUCam2+ is ready to do things such as color tracking, motion tracking, histogram and other functions. The next posting will cover color tracking.