No MODE visible through serial monitor on start

[Russell Craft]

Firstly, I like to apologize that I'm one of those cheapskates that sourced all the electronic parts from AliExpress and therefore I haven't economically contributed to this amazing project.

Some might rightly say I deserve these frustrations but I've troubleshooted as far as I can go and hopefully someone here can help me...

When I start up Vorpal, none of the motors move. 

To ensure the PCA9685 driver board was ok,  I uploaded the servo example code from the Arduino IDE and that worked fine.

Therefore the servos, the driver board and the wiring to the nano are functional.

I connected to the nano via the serial monitor, and the only thing it says is the firmware version #RV2r1a and TRIMS:UNSET. 

I should expect to see what MODE the robot is in through the serial monitor.

This led me to think the potentiometer was broken, so I tested the output of the potentiometer with a multimeter when it was powered via A1 and A2 on the nano and the voltage varies as expected. So it appears that is fine,

I switched the input for the potentiometer in the arduino code form A0 to A3 just in case A0 was buggered but that didn't change anything.

Does anyone have any suggestions what I should do next?

Thanks in advance

[vorpalrobotics]

Hello,

First of all, it's perfectly ok for you to self source. That's why we made the project open source. No apologies necessary. Assuming you get the project working and enjoy it, we'd appreciate you spreading the word in lieu of payment... a youtube video post with our URL in the description, a FB post with a picture of your project, an instagram post, tiktok, whatever else, etc. 

Now, on to your issue. You did the right thing by first confirming that the hardware setup is good.  But it seems like the modes are not triggering as expected.

You could uncomment the line of code in loop that says this:

  //Serial.print("Analog0="); Serial.println(p);

A search in the IDE for Analog0 will find it.  Recompile. 

However, that's not quite enough. From what you're saying, it almost sounds like you're never making it out of setup().  There are numerous reasons why this might happen.

One would be a bad buzzer. I've seen it happen that a defective buzzer will basically draw so much power that it browns out the nano. You never mentioned whether you hear any beeps coming out of the robot. If you do, please report what you hear.

You could just unplug the buzzer and see if things start to work.

If that doesn't do the trick, we need to know exactly where in setup() the issue is happening. The only easy way to do this on a microcontroller is stick some debugging messages every few lines, like this:

 ... a few lines of setup code ....

Serial.println("setup: 1");

  a few more lines of setup code ...

Serial.println("setup: 2");

etc.

You can start this a few lines after the TRIMS: unset message since we already know the code got at least that far.

So then you run the program and where the messages suddenly stop coming out.  You could then refine the exact line of code by adding a couple more prints.

If you can isolate the exact line of code where things go sideways, that will give us a major clue where to look.

Hope this helps,

Steve P.

[RADEX]

Hi Russell, I have the same problem. I´ve been testing my hardware and everything seems to be fine.

 I did not tried what steve says but that has to solve the problem without any doubt. In my opinion it could be the version of the PWM-servo library.

 When i have time to try it i will post it to let you know. 

 

Javier N.  

 

[vorpalrobotics]

The Libraries we build and test with are all in a shared dropbox folder at http://tinyurl.com/VORPALFILES

[RADEX]

You were right Steve. I solved the problem and all the software was fine, the problem was i didn´t have the shunt on the VCC-V+ !!!

 When i realize  it i couldn´t believe it !! It took my the entire day to find the problem because i used the console to test the code as you said and it stucked at servoDrive.begin.

 Steve, thank you for your help us even when the forum has a couple of years and congratulations for this amazing project. 

 

[vorpalrobotics]

Oh wow, I should have thought of that!  But wait ... the reason I didn't think of that was that the OP had said the servo driver demo program did work. So I ruled out an electrical issue for the OP and didn't think to ask if you had also tried that.

Oh well, at least you got it working.

(For people who buy kits from us ... the V+/VCC shunt is pre-installed on the kits so you don't have to worry about this issue.)

[Russell Craft]

 Hello,

Thanks for your suggestions, Sorry for the belated reply, so I finally got some time to sit down and try to sort out the vorpal. 

I forgot to mention last time that I'm powering the servo board with bench top power supply, so no issue with the bec.

I did as you suggested, it's not the buzzer, it has the same behavior with or without the buzzer connected.

The buzzer does one one long low-pitched beep followed by two short high pitched beeps and then the arduino resets.

It resets at the following piece of code.

  Serial.println("setup: 6");                 

  // Chirp a number of times equal to FreqMult so we confirm what servo mode is in use

  for (int i = 0; i < FreqMult; i++) {

    beep(800, 50);

    delay(100);

  } 

  Serial.println("setup: 7");  

This is what see from the serial monitor

#RV2r1a

TRIMS:unset

setup: 1

setup: 2

setup: 3

setup: 4

setup: 5

setup: 6

⸮

I can't see why it would reset at the part in the code it does, any ideas?

[vorpalrobotics]

Hi,

It's more likely crashing on the *next* line, the resetServoDriver() call which initializes the servo driver.  The crash happens so fast that the characters don't have time to print from the "setup 7". (The serial io port prints out the characters using a hardware UART which only prints them out as fast as your baud rate setting, which is probably about 1 millisecond per character. The crash is happening in just a few microseconds, too fast for even the first character to print. If you were to put a "delay(200);" call after the "setup 7" that would prove this to be the case).

So the nano browns out as soon as the servo driver starts to draw power. This could be either a bad servo driver or bad wiring to the servo driver (i.e. forgetting to shunt V+ and VCC or a short somewhere) or a bad servo motor that is internally shorted out.

If you disconnect all but one single servo and it works, that would be evidence that one of the other servos is bad. You could reconnect them one by one until you find the culprit.

Another possibility is that you're not using the same servo library we are and there is some incompatibility. The one we use is posted in the library folder of the shared dropbox location here:

http://tinyurl.com/VORPALFILES

Hope this helps,

Steve P.

[Russell Craft]

It was the libraries, it works!!! I wouldn't have been able to figure that out for myself.

Thanks for your help, I'll post something, somewhere, or I'll get my missus to it, as I'm not a social media person. 

My twins are well chuffed, cheers.