Human runners telling you to get lost because you're not rich, bald, & fat? Need a way to carry your junk, get video of your running form, pace your workouts, light your path, play music?
When it was introduced in 2013, it was a modified G-buggy no-one cared about. 3 years later, it was still no more than an RC car, but self driving car startups saw their valuations explode & anyone in Silicon Valley who saw this machine suddenly wanted to write a $65 million check. Should have really driven it down Sand Hill Rd & fielded buyout offers.
The key development was the remote control.
The object of the robot is manetaining a constant speed & heading on its own. This is just automated enough for a lion to drive it with 1 paw. The journey began in Jan 2014, with a $40 G-Buggy the lion kingdom got for free:
It was a very poor at setting a pace, couldn't carry cargo, but could carry a camera. There was no easy way to measure speed & the steering was binary. With enough tuning however, the steering could be made proportional enough to hold a heading.
The steering mechanism was an interesting reduction of a servo into a spring that centered the wheels & a clutch plate that applied a steering force proportional to the speed of a motor. The controller it came with could only do binary steering, but with a fast rate sensor & feedback loop, the steering could be made somewhat proportional.
The inner clutch plate & outer ring it pressed against while spinning, but not while stationary.
With a constant voltage applied to the traction motor, it achieved poor speed regulation but infinitely better than lions trying to pace themselves.
The final form of the 1st model.
Several models came afterwards, as budgets increased, culminating in the Tamiya Lunchbox. The steering was finally proportional & the speed could finally be regulated.
Attempts to make it self driving all failed, for reasons startups are too familiar with.
Key to making it all work was a paw controller. Proportional steering & throttle would be nice, but weight & durability dictated binary tact buttons. China simply never made a durable, compact, proportional sensor.
The final design had 2 buttons for slow steering, 2 buttons for fast steering, 1 button for throttle. This was proportional enough for all needs, with the computer automating speed & heading. 1 switch controlled reverse.
After 4 years of water causing the wood to shrink, the battery spacers were expanded to 1/4". Extra space is required to account for battery swelling. Since the days when battery swelling was considered doom, it's become the standard aging process. Products have extra space to account for battery swelling. Unfortunately, this battery is down from 5Ah to 4Ah capacity or only 14 mile range. Over 2400 miles with most of the discharges down to 33% capacity took their tole.
For the 1st time, an ESC blew up from getting wet. All 3 PFETs blew up. They had been flown in rain, flown from wet fields, but never blew up before. Dunking in puddles finally got one wet enough to do the job. Potted it in aquarium sealer. It's not reworkable anymore.
To make the miles more interesting, the decision was made. Originally wanted to discard the ears & just use the antlers, but didn't have the stomach to tear it all apart, despite being $1. The intact antlers are easier to break down. The nose was an LED light bulb with a red LED replacing the white LEDs. The red LED needed a diffusing cover in the form of translucent heat shrink which is no longer made.
Installed the ancient XBee Pro 900's & got instantly perfect results. These were the only true frequency hoppers that really work. The connection time is still a very long 30 seconds & the power consumption is 100mA. They could be reconfigured for lower power, but the 2.4Ghz ran at 100mA for 5 years. The packet rate is only 25Hz.
The ancient XBees are still the same outrageous price as 10 years ago.
The 3DR Radio/HM-TRP/Si1000 modules don't have any GPIOs like the XBee. It was desperately hoped that the XBee could eliminate the need for a companion microcontroller with GPIOs. Making custom Xbee firmware requires the EmberZNet SDK which is only available to owners of the $1000 EM35X-DEV kit. With so much interference at 2.4Ghz, a broken channel changing command & no way to write custom firmware, they're worthless junk now.
The lion kingdom replaced the firmware on its 3DR Radio to optimize it for transporting PPP instead of telemetry. It didn't work because of lockups in the USB to serial adapters but might have worked with custom USB adapters. That firmware is now lost forever & must be reverted.
The stock 3DRRadio ran the SiK firmware. In a testament to the commoditization of quad copters, the SiK firmware no longer compiles on any modern Linux version. It was only ever used for moving quad copter telemetry to a laptop.
The SiK issues were minor compiler errors from evaluating all constants to int instead of uint8_t & the default switch statement overriding all other cases with a the same rule.
How to build & program it is still documented in the README.markdown file. Besides ending every file in .markdown, this author also liked using ~ all over the filenames. The lion kingdom's boards still had the grounding connections required to program the firmware.
Many users got "Verification failed in group at 0x0" errors.
The mane cause of "Verification failed in group at 0x0" is trying to program a file starting in bootloader~. The bootloader can't program itself. You have to program a file starting in radio~. The mane reason for this confusion is the ~ is normally the start of a directory name in Linux so we ignore everything before it.
With the firmware programmed, you have to configure them. This is done in the AT command mode just like the Xbee. ATI5 gives the default settings. The baud rate is limited by the air data rate. The only essential thing is reducing the latency. They don't pass keyboard input through without reducing this.
The goog still manages to find documentation on the ground connection required to enter bootloader mode & the AT commands.
With the 3DRRadios installed, power consumption dropped from over 100mA to 40mA. The update rate remaned stuck at 50hz & jittery. Ideally, the update rate would be 100Hz & even. There's no way to do that without custom firmware, but it's not worth it.
New old radio installed with some effort at keeping the antenna from breaking off.
3DRRadios broken apart.
Stick controller with new old radio.
The 1st 8 miles with this were a total disaster. The 3DRRadio dropped connections randomly & would never reconnect until the vehicle module was power cycled. Some of the problems were brief power glitches on the stick. If the stick radio was power cycled, it would never reconnect until the vehicle radio was power cycled.
At other times, it dropped the connection when stopping the throttle. The radio appeared to die before the stop command reached the vehicle. Fortunately, the vehicle had a 1 second timeout & breaking enabled. The throttle glitches pointed to something more sinister than power glitches, but either way, the stock 3DRRadio was trash.
The next step would be the non frequency hopping XBee 900's from 10 years ago. They would be another bandaid while working on the 3DR's. They would also reveal any interference where the 3DR's failed.
There's definitely fecal material on the underside from dogs. The inside is more mysterious. All food is wrapped up, but 24 hours before the symptoms, the lion kingdom wasn't the most sanitary. It was the worst case of norovirus a lion ever had. It was a reminder that the dirt on the last 10 years of vehicles isn't always dirt.
Having said that, the lion kingdom got norovirus 2 days after an outbreak happened in a Chico evacuation shelter. Humans would have been streaming in from the fires. It may not have been unsanitary lion conditions but other humans. After all those humans wore face masks to avoid the smoke, they really needed to avoid themselves.
The 2.4Ghz XBees were never perfect, as far back as when they were on UAV's. On ground vehicles they were a lot worse, showing growing pains as more powerful wifi routers became widespread. They don't do frequency hopping, even in a mesh network.
The lion kingdom memorized all the places were it would lose connection, but the list grew into large swaths of the streets. Frequency hopping for RC vehicles was introduced over 10 years ago in the Spektrum brand. It's now in every toy quad copter, so it's kind of silly to be having problems. The 3DR radio/SIK radio has an open source implementation, but it's bulky & lions don't want to redo any hardware. Hobbyist efforts to implement frequency hopping have all given way to commercial solutions.
Amazingly, the 2.4Ghz XBee pro is still sold & for the same ridiculous price as 10 years ago. The only explanation is academic use. There is a bootloader which allows it to run custom firmware, but the XBees predated the maker movement by so long, no-one has ever done it or provided source code. They're based on the EM357.
Frequency hopping without new firmware requires the infamous "API mode". It can't hop immediately after packet reception because of a race condition. It has to hop in a timer interrupt which is delayed some time after the expected packet reception time. Then, the hopper interrupt adds a full hopping interval to the timer. A packet reception has to reset the hopper timer to just the delay time to counteract drift.
If a packet comes in too late, it might hop twice for the same packet instead of once. The delay time has to be chosen to allow timing jitter. Frequency hopping does limit the bandwidth utilization.
After much troubleshooting, it became clear that the XBees can only change frequencies once for each power cycling. This is despite a full channel scan being claimed in the Zigbee spec. It would be a bug in the AT command set. Attempt 2 would just be stock 3DR Radios with the carrier boards stripped off.
So paid $30 for 4 new servos, reflowed the QFN's solder joints, & made a servo exerciser to thrash it all night. Naturally, it would never fail on the bench, but the new servos alone stood a good chance of reviving it. The last order of standard servos was 2001. They were $6 Tower Hobby branded, but shipping was much lower. Those hobbyking servos are now $5, but shipping has followed inflation.
Signs started pointing to a glitching battery connector crashing the microcontroller on the servo. The mane CPU also had glitches, but didn't lock up. The servo may just lock up under certain power glitches.
After cleaning all the battery connectors, the Trackstar was revived & didn't crash again for 400 miles. So it's a lot more sensitive to electrical noise than a brushed servo. It must run at a much higher clockspeed.
The rear tires lasted most of the year, but eventually wore down enough to become front tires. Nylon straps have done the best of any material on the front tires, despite the problems getting them on. The nylon has all come from an old camera bag which the lion kingdom twice ran 32 miles with. Old lions wouldn't do such a thing, because there are lighter solutions.
Getting them on has best been done by tacking on a quarter of the strap at a time with high airflow. The high airflow sets it quickly. Then do a 2nd pass sealing the gaps. It still needs 24 hours to cure.
After 2 months, the $60 brushless servo died & it went into the street. The death was intermittent, as it briefly came on again. Back on the bench, it managed to still have a fault. All the voltages were normal, with no voltage going to the MOSFET gates. Power cycling it a few times in the street didn't bring it back, but it did come back after a power cycle on the bench. Nothing that suffered mechanical wear seemed to be worn out. It was a microcontroller that had become flaky.
It's a Silicon Labs F330, 8051 core. Dave would check all the pins & try to fix it.
After all the servos, there's a real need to build a servo from scratch to last forever. The $60 one has enough useful parts to work again with a custom board, but this would be a significant investment in a rare time when the lion kingdom's time is actually worth more than a servo.
Expensive, high performance servos have consistently died much faster than cheap servos. The longest lasting might be the Tower Hobby brand from 20 years ago. Futabas are in the middle. Servos might have too many moving parts, moving too fast, in too little space.
After some hard driving with high speeds & heavy payloads, the transmission was dried out in no time. The mane issue was high power consumption with no payload & high wheel wear, so the last alignment with a full payload didn't work. Another round of 1.4 mile repeats with no payload also failed. Tried charging without the balancer.
Definitely more erratic charging totals when the balancer wasn't used. Temperatures over 93 & the lack of payload could have also done it in. The next step is recording throttle PWM over a smaller route. It should be much easier, but much less sensitive & still require a full charge.
The easiest solution is a serial port interface which allows starting recordings in RAM & dumping the recordings.
Eventually just tweeked it over many 10 mile runs. The range came back to 15 miles on a 4500mAh battery, depending on terrain & payload.
Run with the robot on your left. It drives a lot straighter than a lion can run, so tends to keep the lion on the right & piss off fewer bikers.