Panic! (Submit Answer)
Let’s say you are troubleshooting a remote system and have no physical access to the hardware. How would you ensure that you can regain control of the system if/when a kernel panic occurs?
Assume you have serial console access both during POST and after kernel bootstrap. There is more than one correct answer.
I recently acquired an open-box Roomba Discovery SE made by iRobot for $50. It seemed like a good buy, I could always hack it for a robot base if it didn’t work. The only thing missing was the fast charger.
Digging around in the various junk boxes that inhabit the dark corners of my basement yielded an old Gateway laptop adapter. At 19V and 40W it was “close enough for me” to the Roomba’s stated power requirements of 22V and 1.5A. I quickly disassembled the included home base charging unit to check the required polarity (center positive it seems).
After soldering on the appropriate size power plug I plugged in the home base charger. Lo and behold, I got a green power light! The Roomba, however, remained dark and silent. I stuck it on the home base and the docking light came on. Still no response at all from the Roomba.
Much to my delight the power button started pulsing red after about 30 seconds of charge. Yay! I gave it a few minutes and was rewarded with some plaintive beeping when I attempted to power on the Roomba. There was hope! A few hours of charging and the little Roomba was running around proudly cleaning up bits and pieces from my carpet under the workbench.
I have now been using the Roomba for a couple of days and am quite impressed. The navigation logic is bang on and even does a fine job in our living room with a large sectional, coffee table and several other obstacles. The battery life is not too good, 30-45 minutes of cleaning on carpet. It does seem to be improving with every charge, so perhaps the battery just needs some conditioning.
Here are some links I have come across in researching the Roomba series.
I have run into this same problem a few times so I am documenting it here. When using GetOpt::Long and friends I would be mystified when the options were ignored. For example:
#!/usr/bin/perl use strict; use warnings; use Getopt::Long; my $debug = 0; my $result = GetOptions( "debug" => $debug ); print "Debug flag is $debug\\n";
wriley ~/bin> ./getopttest.pl Debug flag is 0 wriley ~/bin> ./getopttest.pl --debug Debug flag is 0 wriley ~/bin>
The options are completely ignored! A short time of googling later and I remembered the solution.
#!/usr/bin/perl use strict; use warnings; use Getopt::Long; my $debug = 0; my $result = GetOptions( "debug" => \\$debug ); print "Debug flag is $debug\\n";
wriley ~/bin> ./getopttest.pl Debug flag is 0 wriley ~/bin> ./getopttest.pl --debug Debug flag is 1 wriley ~/bin>
The key is escaping the $ in the GetOptions() statement. If you don’t escapey, it don’t workey!
Loading ...