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.