HEXAPOD NOT WALKING CONTINIUSLY

[chr s]

Hi from Spain !

I hope you are all safe and healthy.

First a big thanks for making this open source. The project is very well documented and was really exciting and fun to build. We call the Hexapod "Vorpalito" and my kids are already huge fans. 

I have self sourced everything and printed the parts at home, assembled the robot and everything works (demo mode etc) but run into a problem when using rc mode. The bluetooth modules are HC-05 (zs-040), both paired through a USB-AT bridge using a spare nano and baud-rate set to 38400,0,0. I ran into some issues using a 9V battery for the gamepad (the modules where reconnecting all the time and I fried a bluetooth module). When connected to a usb cable the connection is persistent and the robot responds to commands on the gamepad but for some reason when continuously pressing the gamepad the robot walks a few steps, pauses and the continues walking again. This behavior does not occur when using the demo mode so I think the electrical wiring should be fine. 

I have made a short video to show (don´t look at my foot.... ) : https://youtu.be/um49hZSG3is

There is also quite a delay from when a button is pushed and the robot responds. It would be great if somebody could point me to what could be wrong here as Vorpalito´s fans where very dissapointed with daddy not being able to produce a swiftly responding remote.

Big thanks in advance !!!!

Stay safe !!

Chris

[Steve Pendergrast]

Hello,

First, thank you for building our project!

This is very unusual behavior. There is typically almost no lag at all in the controls, and the intermittent cut outs are also not typical.

Let's talk about the 9v battery first. The 9v output should go to GND and Vin on the nano. The HC05 and SD card reader should be taking power from +5V outputs on the nano. In other words, they are using the nano's internal 5v regulator, which can just provide enough power for those two modules. So, carefully check the wiring diagrams and make sure you're not feeding +9v directly to the hc05 and SD reader.

Okay, now the laggy/stopping issue.  I can think of three reasons this might happen:

1) Some 18650 batteries have an aggressive protection circuit that will cut power if there is a surge in amps. When motors start up, there is such a surge. You might have batteries whose protection circuits are cutting out power intermittantly. However, arguing against this possibility is that you're not losing bluetooth connection (it would take longer than a second to reconnect.)

2) A loose wire to the servo driver could cause it t loose power. It would then reboot, and start working again. Check power connections and also the signal connections  (SCL/SDA) to the servo controller. (Arguing agains this is that it works on demo mode, but it's still something to check).

3) The BEC you are using for power conversion might not be able to handle the amps. It might have protection circuitry that cuts it off automatically. It would then reboot and start working again.

None of these theories really explain the laggy behavior, though, I'm scratching my head on that one. But let's see if fixing the drop-out might also fix the lag.

Some questions for you:

1) Send me a picture of your BEC, including any markings or wording or model numbers showing on it.

2) Send me a picture of your battery, showing any labels/markings/model numbers.

3) Did you install a buzzer? If not, it might be helpful to hear the output from the buzzer as there are several situations that cause different kinds of beep that are useful for debugging. I do not hear any beeps which could be either because none of the common error conditions are occurring, or because you didn't install a buzzer.

4) The  video shows you using "scamper mode". Does the same thing happen on slower walking modes like W1?  Scamper mode draws far higher amps than normal walking, so if it only happens in scamper mode that would point to the batteries or the BEC.

Also, a picture of your hc05 would help, perhaps this is a radio issue that I haven't seen before.

Hope this helps,

Steve P.

[chr s]

Wow, thanks for the swift answer !

The bluetooth module probably fried because of a bad unit, the wiring was correct and only cause i can think about might be the 3.3V RXD pin but i have used the same 5v on RXD on other projects and never had to use a voltage regulator for this. The second unit is working fine but as I said the battery was definitely giving me trouble as the modules where loosing connection all the time. Using an usb cable from a USB hub does not give me any of these problems at all.

Demo mode works with no issues at all : https://youtu.be/5jby7W1HhGI

All other walking dancing modes have the same intermittent cuts, sometimes the hexapod also looses "balance" and falls down and immediately goes back up again :  https://youtu.be/llpV3FZMpJw

1) BEC is this one : https://www.banggood.com/External-Brushless-BEC-UBEC-3A-5V2-5S-Receiver-Power-Supply-p-949258.html?rmmds=myorder&cur_warehouse=CN

Description:
Output: 5V/3A
Power input: 5.5-26V(2-6S)
Dimension: 26*12*11mm
Weight: 5g
Ripple: <50mVp-p(2A/12V)

Features:
- Power switch structure, main chip frequency 300KHz, with overheat, overflow protection
- Very small and light weight
- Output cable with magnetic ring to decrease magnetic interference
- With reverse polarity protection

Package Included:
1 X BEC(UBEC) 3A 5V Receiver Power Supply

2: Batteries are : Samsung INR18650-25R, I won´t send you a pic as I had to replace the wraps as they were damaged and you won´t be able to see anything.

3: Buzzer is installed but doesn´t make any sounds during the problem. It makes the normal startup sounds fine and i had a continuous sound when i disconnected the tx and rx wires from the bluetooth module to troubleshoot while pairing. 

I have attached pictures of the bluetooth modules (same one used on both ends).

Very grateful for your help !!!

[chr s]

forgot to mention i checked the wiring on the servo controller board and they seem fine, maybe a faulty cable somewhere ? Only thing I could do here is to rewire the whole thing with new cables.

[Steve Pendergrast]

That hardware all looks fine to me.

So now I'm thinking radio is bad based on your further details. It could be marginal so packets sometimes go through and sometimes do not go through. The battery and bec, on further thought, would also drop out during demo mode of they were bad. But that BEC looks identical to what I use and the hc05 looks very close.  (By the way, almost all modern HC05 modules will accept 5v on the input pin, you can look at the circuit diagram and actually see a diode inserted that makes it 5v tolerant).

Dropped packets would account for laggy controls as well as sudden stops. If a good packet is not received within some period of time (I'd have to look at the code but I think it's half a second) then the robot cuts power to all motors as a failsafe (in RC mode).

However, normally when a bad packet is detected you'll hear little clicking sounds come from the buzzer. Not loud, just little low pitch rumbles to indicate there may have been static.and some packets were dropped. 

So again, I'm kind of scratching my head.  A test you could do for the HC05 radios is set up two terminal emulators and connect both hc05 modules via USB to a computer. Set up one terminal to talk to one module, and a different terminal for the other. Set the terminalsto the right UART baud, etc.  See if typing in one terminal shows up in the other terminal. See how much random garbage you get.  It could be that one module is damaged and intermittently fails. If you're seeing a lot of garbage along with what you're typing, I would swap to a new module.

If that succeeds, i.e. you don't see garbage and typing across the modules works, I guess the next step would be to hook the robot up to USB and look at the arduino serial monitor to see what debugging can tell you. There are several debug modes available in the code, see the comments near the top (after all the copyright info etc.).

On Sunday, May 17, 2020 at 1:21:13 PM UTC-4, chr s wrote:

[chr s]

Thanks for all the support Steve.

I think I´ll get some new modules and swap them as they always come in handy and I´m out right now.

I´ll update the post once I get it working.

Best regards !!

[chr s]

Hi again !

I remembered I had a different brand HC-05 from a different robot so I crippled the poor guy and after changing the BAUD rate to 38400 and finding an app on google play for the robot IT IS WORKING !!!

Once again Steve many thanks for making this amazing project open source and giving me stellar support as a self sourcer. I will recommend your kits to anybody that´s going to be interested after showing Vorpalito off to my kids friends (I´m sure there will be some) and point them to your website. 

Stay safe !!

[Steve Pendergrast]

Great! Glad to hear you got it working. Yeah bad electronic modules can fail in so many different ways, that can be the hardest thing to debug.

I'm happy to support self-sourcers on a time available basis. I want as many people as possible to build it, that's why we made it open source. 

I would ask you to post video of your build to places like facebook, instagram, etc. if you have accounts and mention vorpalrobotics.com in the description. This helps us spread the word.

Take care,

Steve P.

[Rostislav Zboril]

But this is not the solution. I have the same problem and also everything works for me via the Android application, but not via the RC driver. The problem is, I think, in the incorrectly set pairing of the HC-05 module. It is necessary to set: connect only to this second HC-05 module and I have 1-On set there. Is Baudrate 38400 also okay? I don't know what to do anymore. 

Rosťa From Czech republic . 

Dne pondělí 18. května 2020 v 15:51:18 UTC+2 uživatel Steve Pendergrast napsal:

[vorpalrobotics]

Hello,

There are numerous steps required to pair two HC05 modules, its a lot more than just setting the baud rate. Unfortunately there are a lot of differences between firmware versions on commonly  available modules so I cannot offer any one-size-fits-all instructions. This is the reason why we provide pre-paired modules with our kits.  There are numerous tutorials available, though you often have to investigate and slightly change what they say to get it to work, depending on firmware version.

Also, beware that there are now modules using firmware version 3.0-20170601 that will not work no matter what you do, and these are getting more and more common from places like aliexpress and banggood. Make sure you get something with a firmware version that starts with 2.0.  The 3.0 firmware breaks buffering and adds a 2 second time delay between send and receive, which of course will not work at all for this project. There is apparently no spec sheet available from any manufacturer (I've asked several so far) that describes how to turn off this annoying buffering which makes this version of firmware unusable for most applications. (If there even is a way to turn it off).

Hope this helps,

Steve P.

[Rostislav Zboril]

That will be the solution to the problem. I have two modules with firmware version 4! Thank you very much. I'm going to look for version 2. (God, so many Days and Hours ...)  

Rosťa.

Dne sobota 5. září 2020 v 22:06:51 UTC+2 uživatel vorpalrobotics napsal:

[vorpalrobotics]

Well, let's be careful here. I'm not aware of any 4.0 firmware for HC05 modules (it's possible there are some I'm not aware of, if you'd give me the full firmware version that would help me track it down). What you might be referring to is Bluetooth version 4.0, which is also called BLE. There is a difference between the bluetooth protocol version and the module firmware version! (Yes, it's a little confusing).

BLE (bluetooth version 4) is a low power bluetooth, and there are modules for it as well (though I don't think they're called HC05 modules. Every HC05 module I know of uses Bluetooth 2.0 or 2.1). I haven't personally tried programming BLE modules, so can't help you there.

[vorpalrobotics]

Okay I just did another round of internet searches and I found that there is an HC05 firmware version 4.0-20190805 which is bluetooth protocol version 2.1. I also confirmed that, like firmware version 3.0-20170601 it also has the buffering behavior that makes it useless for realtime transmission.  I also confirmed that nobody on the internet can apparently find a spec sheet for this version of firmware, and so nobody can figure out how to turn the buffering off.

I am actually considering writing a program that will systematically try every possible combination of letters for AT commands to see if I can locate the magic command. If the command is 3 or 4 characters long the time it will take is reasonable (a few days). But if the desired command is 5 letters long, that will take a few months of compute time!  But at this point I'm getting desperate, it is getting harder and harder to find the firmware 2.0 version chips and I have about 100 modules with the newer versions that I can't use. The manufacturer won't let me return them because they are functioning as designed.

There is a workaround that might be ok: I could change the code to pad out all protocol commands up to 230 characters, which will overflow the buffer and force the packet to send. This will only work because my packets go out 10 times per second at 38400 baud, meaning I can send about 480 characters within that 100 millisecond time slice. Therefore, I if my protocol sends a 13 byte packet (typical)  could just send out another 217 nulls afterwards to force the packet to send, and there would still be "room".  I could then change the protocol on the robot side to ignore any nulls that fall outside a normal packet header (so it doesn't beep due to a bad packet).

I really don't want to do that because it's such a hack, but I may have no choice because the HC05 2.0 firmware is apparently being discontinued and replaced by the horribly broken versions 3.0 and 4.0.

[Rostislav Zboril]

That's not good news. I wonder what components will come to me. I also tried to adjust some parameters in the Arduino, but without success.  

Dne pondělí 7. září 2020 v 16:16:05 UTC+2 uživatel vorpalrobotics napsal: