Author
Topic: VRbot is flaky, doesn't always work (Read 2366 times)

The problem: Sometimes VRbot works, sometimes it doesn't do anything at all, and it appears to be entirely random. To try and narrow the problem down, I tried two entirely different setups.

Setup #1I have it plugged in to a USB to 5V TTL adapter. USB power to Vcc, ground to ground, rx to tx and tx to rx. I'm running Hyperterminal on the correct port, and 9600 baud.

I send the character 'b', and it responds with either the 'w' character, or 'o'. If I get 'w' and then transmit 'b' again, it'll always give me 'o'.

But sometimes after plugging it in, it'll never respond no matter what. I'm keeping the setup exactly the same, but it seems so random.

Setup #2In this setup I'm using an Axon microcontroller. Its running off a battery, regulated to 5V (I measured the battery, its fine), transmitting at 9600. I'm forwarding the response of the VRbot module to a separate USB so I can view it.

Now I turn power on. My mcu is programmed to wait 2 seconds after power up before trying to communicate with the VRbot module. Sometimes the module responds correctly with 'o'. Sometimes nothing. It's entirely random, and I'm changing nothing!

TheoryI have a theory . . . I then keep VRbot unpowered while turning everything else on. Then I plug in VRbot. It then almost always works! I get a very similar effect with my USB setup, too. This makes me think that it requires a very sharp/straight edge power up voltage signal, ie if power up is too slow it won't work.

Solution?If my theory is correct, and it might not be, this means I have two possible solutions, A) a separate regulated battery which would be annoying, or B) modify the VRbot module by adding/removing components.

I've decided on B, but I can't find any schematics. Most components are SMD without part numbers. One part is labeled PaE7Q, but no replies here:

i presume the module uses some sort of microcontroller or other processor.rather than modify the regulator circuit it would be nice if you could identify a reset pin on the microcontroller then just reset after the voltages have stabilised.

i presume the module uses some sort of microcontroller or other processor.rather than modify the regulator circuit it would be nice if you could identify a reset pin on the microcontroller then just reset after the voltages have stabilised.

I want to bury the thing inside my robot, where I won't be able to reach it.

If what dunk suggest just doesn't work, why a seperate battery than a mosfet switch for power....

It only uses < 20mA, so a bit silly for a second battery. And of course I could add in another switch, which is pretty easy, but I'm looking for a more permanent 100% reliable solution.

Quote

But I really doubt it can be rising time... How slow is your raising time for this to happen?

Well, it rises fast enough for an ATmega to run fine . . . I did notice that if I plugged it into my original Axon it'll cause a quick power reset of the Axon, which tells me it's draining quite a lot of power to fill up capacitors.

From what I get this module is designed to run under serious noise. As biped robots carry lot's of servos...

So noisy power supply shouldn't be a problem... But from what you tell me it would be a could start to try remove some of the biggest capacitors at from the circuit...

Still again... Those capacitors should have a very low self resistance to cause a serious voltage drop at the power supply... What is the current the regulator can supply... Theoretically it's like connecting a zero volts power supply (short circuit) when powering up a capacitor... Remove the "big" capacitors from the power supply rail from the module as a first step...

An other solution to see if these caps drain such big currents at charging up is to power the module from a low ohm resistor and see the voltage drop across the resistor with a digital scope...

Then you can measure ESR of the capacitor to see if it fits removing it... Solutions many... But you have trial and error in front of you...

Best Regards, LefterisGreece

Logged

For whom the interrupts toll...

P.S. I've been inactive for almost a year... Don't give promises but I'll try to complete my tutorials. I'll let you know when..

i presume the module uses some sort of microcontroller or other processor.rather than modify the regulator circuit it would be nice if you could identify a reset pin on the microcontroller then just reset after the voltages have stabilised.

I want to bury the thing inside my robot, where I won't be able to reach it.

i didn't mean manually reset it.

either use an I/O pin on your main MCU to reset itor use a capacitor to hold the VRbot in reset until voltages have stabilised.

TrickyNekro's solution wouldn't need a separate battery. if you were willing to switch the VRbot on using a mosfet you could have your main MCU just keep power cycling it until it works.

It turns out that it has a huge power drain during power up, randomly knocking out the Sparkfun FTDI USB adapter. The VRbot datasheet only specifies average current, but max current is at least 5x higher. I'm lucky it didn't fry my adapter!

So if you use the FTDI USB adapter with VRbot, make sure you don't use 3.3V, but instead take power directly from the USB 5V line.

But it's not yet resolved for setup #2, still working on testing that . . .

if you were willing to switch the VRbot on using a mosfet you could have your main MCU just keep power cycling it until it works.

I've found that if I manually turn it on and off about 20+ times it'll usually work sooner or later . . . this might be my only solution, although it feels like hiding the symptoms instead of finding a cure . . .

I also found that for some reason it's randomly deleting Indexes in Groups, randomly mixing up the training between the Indexes, and even moving trained Index numbers from one Group to another Group (ie randomly swapping/deleting/adding pre-trained voice data) - yet I'm not even commanding it to do anything like that.

Perhaps random noise during microcontroller bootup sent through UART would send commands like this? I already have the Axon wait for two seconds after bootup before it even sends a command . . . (I don't have an oscope on me right now to check)

The creator won't tell me anything about his circuit, so I have to reverse engineer it and guess what unlabeled chips do. As such t's very hard to figure out how it's negatively affecting my circuit . . . it'll work for ~10 seconds after unpowering it, and power it from my original Axon causes the Axon to power reset - suggesting it has unnecessarily large caps on it . . .

Disabling the TransmitterThe disabling of the Transmitter (setting the TXEN to zero) will not become effective until ongo-ing and pending transmissions are completed, that is, when the Transmit Shift Register andTransmit Buffer Register do not contain data to be transmitted. When disabled, the Transmitterwill no longer override the TxDn pin.

So if the buffer keeps the data, on power down that means... It will send them no matter what...You should check if data received empty is 1 to see if all the data are transmitted before issuing new send... ;-)So flashing the buffer before initiating the transmitter is the good idea... :-p

Logged

For whom the interrupts toll...

P.S. I've been inactive for almost a year... Don't give promises but I'll try to complete my tutorials. I'll let you know when..

I also found that for some reason it's randomly deleting Indexes in Groups, randomly mixing up the training between the Indexes, and even moving trained Index numbers from one Group to another Group (ie randomly swapping/deleting/adding pre-trained voice data) - yet I'm not even commanding it to do anything like that.

It basically requires wiping the memory using the GUI, doing a power reset for 5+ seconds, then re-configuring it from scratch.

If you're interested, this is the robot I quickly threw together. It was just a basic ghetto demonstration before I add it to my ERP. I noticed that I'm significantly more likely to yell profanities at my robot when it has a voice recognition module that isn't working all the time lol . . .