Ultimate running aid

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.

The firmware update command is:

Firmware/tools/uploader.py --port /dev/ttyUSB1 Firmware/dst/radio~hm_trp.ihx

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.

ATS15=33

AT&W

ATZ

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.

The virus came from eating food with the same paw that handled the underside of the robot & possibly licking a wrapper that was inside the robot.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2878247/

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.

Lion tip:

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.  

The final cruiser swore allegiance to the god emperor & chief.

A test drive didn't reveal any problems.  The phone got better radio reception than the 30 year old FM banger.

The 8 year old glow stick barely lit up.  Either it expired or lion vision has deteriorated too much to see anything since using those as a kid.

The fireworks were pretty minimal.  It was an overcrowded street with limited visibility & humans who were too busy yelling at each other to notice their god emperor.  It was a pretty awful place for a fireworks show.  The speaker wasn't needed, since they had barely audible music & the radio station didn't seem to be broadcasting the soundtrack, anymore.  The FM banger came in a lot better in downtown.  Then, during the 1 mile drive from the show, the $60 steering servo died.  The metal gear came undone from its servo horn.  

This part never got threadlock because of its tendency to crack plastic.  The next idea was to threadlock just a bolt in the metal gear, let it dry, then install the servo horn.  This is why you should never overhaul less than 50 miles before an important mission.

Also, the shoelace strap got ground up a lot faster than last time.  Glued another shoelace around it, but a way to bind a wider strap to this conical section must be found.  Kevlar rope is increasingly tempting.

It's time. Socialism sux, but it's fact everywhere in the world. If the lion kingdom was in Thailand, it would use a Thai flag, but if it was in England, it would use a 13 star US flag.

The $60 TS-940HG was the only one in stock.  They sure made a big deal about the helical gears.  

It's heavy, but fast.  Standby current is no different than normal servos.  

CNC milled case.

A 3 phase motor with 3 hall effect sensors, but not anything you can get separately.  

The servo saver was the only thing which fit & could reach the pushrods.  There were no changes needed in the feedback.

Instead of electrical tape, applied duct tape to the transmission with small electrical tapes just over the holes.  This gave good protection without contaminating the oil.

In other news, the nylon straps were a failure.  They were too wide & inflexible to get around the conical wheel shape.  A conical section from a sheet of fabric would do it.  Back to shoe laces.