complete newbie with a big problem
complete newbie with a big problem
by Dunktank
Sat Dec 06, 2014 11:33 pm
I don't know if anyone still uses this forum but here goes.
I have two Robonova-1 robots from a community college I attend. My project is to fix them and set up a lab for others to follow. One of them worked fine until I sent it some bad code I guess. I was experimenting and I do not know what program I sent it but It locked up. It will not communicate with PC at all. error code 4 exceeded communication time. over and over. Nothing works not zero, not real time, no download of new program, nothing.
So I gave up on that one and switched to the other. It had a few mechanical problems but I fixed them and I used the same usb to serial connection and laptop to experiment with writing code. It worked fine for weeks then while I was experimenting with the AD ports and some after market Gyros (already installed not by me) It too locked up. It is doing the same thing as the first. No communications with PC. It seems to be stuck in a loop and will not stop when I press the stop program button. (because it has no comms?)
This is what I know it is not the laptop or the serial connection if it were then it would not have worked on the 2nd robot after the exact problem with the first. Every time I power him on it makes a tone and moves 1 or 2 servos a fraction and then nothing. Its not the power my batteries are fully charged and it happens with an AC adapter that plugs in in-place of battery(not a charger on with battery at the same time)
I have tried to stop the program, reset the controller, clear the memory, (However I have no idea how these commands work) load a new program, use robo script, set zero point, and use real-time control. Nothing.
I am convinced it was something in my code however shouldn't the stop and reset commands over-ride these types of problems?
What do those buttons do anyway? what does clear memory do? I have searched the web and this site in particular and don't seem to find anybody who has had this problem or I don't know how to frame the question. I can't believe nobody has experienced this but me.
I hope somebody out there still monitors this site I would appreciate any help that you could give
thank you in advance
I have two Robonova-1 robots from a community college I attend. My project is to fix them and set up a lab for others to follow. One of them worked fine until I sent it some bad code I guess. I was experimenting and I do not know what program I sent it but It locked up. It will not communicate with PC at all. error code 4 exceeded communication time. over and over. Nothing works not zero, not real time, no download of new program, nothing.
So I gave up on that one and switched to the other. It had a few mechanical problems but I fixed them and I used the same usb to serial connection and laptop to experiment with writing code. It worked fine for weeks then while I was experimenting with the AD ports and some after market Gyros (already installed not by me) It too locked up. It is doing the same thing as the first. No communications with PC. It seems to be stuck in a loop and will not stop when I press the stop program button. (because it has no comms?)
This is what I know it is not the laptop or the serial connection if it were then it would not have worked on the 2nd robot after the exact problem with the first. Every time I power him on it makes a tone and moves 1 or 2 servos a fraction and then nothing. Its not the power my batteries are fully charged and it happens with an AC adapter that plugs in in-place of battery(not a charger on with battery at the same time)
I have tried to stop the program, reset the controller, clear the memory, (However I have no idea how these commands work) load a new program, use robo script, set zero point, and use real-time control. Nothing.
I am convinced it was something in my code however shouldn't the stop and reset commands over-ride these types of problems?
What do those buttons do anyway? what does clear memory do? I have searched the web and this site in particular and don't seem to find anybody who has had this problem or I don't know how to frame the question. I can't believe nobody has experienced this but me.
I hope somebody out there still monitors this site I would appreciate any help that you could give
thank you in advance
Re: complete newbie with a big problem
by PaulL
Thu Dec 11, 2014 12:30 pm
I own a few RN-1's. I would disconnect all of the servos, paying attention to where the connections go and how they're oriented (they can be plugged in wrong, pay attention to the tab on the body of the plug), then plug in AC power without the battery connected, and try to program again.
You shouldn't be able to "brick" the controller by sending it programs from RoboBasic, the bootloader should always be available no matter how bad the script code is.
If these are the stock batteries, they must be weak by now. My original batteries are shot, without a whole lot of use. The stock batteries are NiMh, and NiMh don't like to be "deep discharged" by, for example, sitting for a long time without being used - they will self-discharge, which causes permanent damage.
These servos cause a large surge of current when setting initial position. When using a Roboard RB-100 with a stock RN-1 battery, this surge was large enough to reboot the Roboard every time. I ended up staggering the PWM signals to power on more gently.
If the batteries are weak, then just powering on the robot and setting first servo positions is enough to potentially glitch the board to where it won't take a download. This would explain why you get the beeps (servos not yet on), then lock after servo bump. The AC adapter isn't enough to power the bot's servos.
You shouldn't be able to "brick" the controller by sending it programs from RoboBasic, the bootloader should always be available no matter how bad the script code is.
If these are the stock batteries, they must be weak by now. My original batteries are shot, without a whole lot of use. The stock batteries are NiMh, and NiMh don't like to be "deep discharged" by, for example, sitting for a long time without being used - they will self-discharge, which causes permanent damage.
These servos cause a large surge of current when setting initial position. When using a Roboard RB-100 with a stock RN-1 battery, this surge was large enough to reboot the Roboard every time. I ended up staggering the PWM signals to power on more gently.
If the batteries are weak, then just powering on the robot and setting first servo positions is enough to potentially glitch the board to where it won't take a download. This would explain why you get the beeps (servos not yet on), then lock after servo bump. The AC adapter isn't enough to power the bot's servos.
Re: complete newbie with a big problem
by Dunktank
Wed Dec 17, 2014 5:40 am
Thank you paull for responding.
I'll respond first to some of your comments. The battery packs have all been repackaged with new cells as of last school year and I have several to choos from. Also I have an AC to DC power supply that plugs in where the battery shoul to allow for extended programming time so I am fairly certain that power is not the issue.
I am not sure what the term "brick" however I Believe I have fixed the problem for now. I took IBots reflash program and continously reflased the firmware while turning the power switch on and off untill I got a download. Then I did the same thing with Robobasic while trying to download a template program and finally got it to download completely. Now all is better. Both robots are fully functional again and acecpting programs. However I still have to download the programs sometimes 3 or 4 times before it makes it all the way with no errors. Also When I flashed the firmware I believe I reset the controller to version 2.5. eventually I will have to upgrade to the 2.7 again I suspect but for now I am getting things accomplished.
Anyway thank you again
I'll respond first to some of your comments. The battery packs have all been repackaged with new cells as of last school year and I have several to choos from. Also I have an AC to DC power supply that plugs in where the battery shoul to allow for extended programming time so I am fairly certain that power is not the issue.
I am not sure what the term "brick" however I Believe I have fixed the problem for now. I took IBots reflash program and continously reflased the firmware while turning the power switch on and off untill I got a download. Then I did the same thing with Robobasic while trying to download a template program and finally got it to download completely. Now all is better. Both robots are fully functional again and acecpting programs. However I still have to download the programs sometimes 3 or 4 times before it makes it all the way with no errors. Also When I flashed the firmware I believe I reset the controller to version 2.5. eventually I will have to upgrade to the 2.7 again I suspect but for now I am getting things accomplished.
Anyway thank you again
Re: complete newbie with a big problem
by ozfiddler
Fri Jan 02, 2015 6:43 am
Hi Dunktank,
I managed to do something similar to my Robo many years ago... iBot came to the rescue. Sounds like you have it sorted now though. Just wanted to let you know that I have set up a resource page at:
http://simplycomputing.com.au/robots/robonova-resources
Might be useful for you, or if you get anything new and interesting please send it to me and I'll add it in.
Cheers,
Alan
I managed to do something similar to my Robo many years ago... iBot came to the rescue. Sounds like you have it sorted now though. Just wanted to let you know that I have set up a resource page at:
http://simplycomputing.com.au/robots/robonova-resources
Might be useful for you, or if you get anything new and interesting please send it to me and I'll add it in.
Cheers,
Alan
Re: complete newbie with a big problem
by PaulL
Mon Jan 05, 2015 12:25 am
For fun: To Brick (verb): to render as if to change into a brick; to render, for example, an electronic device, the technological functionality of a brick. Often used in the context of closed systems (embedded, mobile, etc) that cannot be easily repaired. "Bricking" a device can be permanent, or permanent in the sense that it is beyond one's resources / abilities to correct (ex, flash is fried, device is unrelentingly locked, board is physically damaged, etc).
About the glitchy behavior:
You mentioned a few interesting things there - the seperate "as a battery" power supply, the repackaged cells - I'd still put an oscilloscope on the power to see if there's a dip or noise in the power supply - can you get access to one at college? How many amps is the power supply rated for?
There are only a few things that can mess with serial communication: either end of the connections, or the something in the middle. Device-wise, the RN-1's serial hardware shouldn't be flaky (it could be, but I haven't seen it). The same should also be true PC-side, though an external USB to serial adapter could have its own issues if you're using one (some just don't work very well). If you're using one, I'd recommend trying a different make / model.
What may be more of the problem is the connection. If there is a grounding problem, you could see this kind of issue (if, for example, the ground on the power supply or the PC is different). I recommended same power strip for PC / modem issues when I did that kind of work a couple decades ago, same kind of thing here.
If the battery has the power (and from what you mention, it should - what was the Amp Hour rating of the cells?), then it is a communication issue. Still, I would remove the servo connections for testing, if only to reduce the chance that they're interfering with communications in any way.
The connection could also be bad on the small plugin jack at the RN-1, there aren't a lot of ways to fix this. There could be debris or a film on the contacts in the jack, contact cleaner may help, or may not do much - replacement is possible, if a similar jack can be found. Typically if you have a jack issue, it would work better if you put pressure on it from some direction. Could also be cold solder joints on the connector, or that the jack is still attached, but broken loose of its solder joints to where the connection isn't consistent (this should be visible under a magnifying glass, but I doubt that's the case here). An oscilloscope would be helpful as you could check the signals at the RN-1 (ex, make sure they aren't dropping out or are otherwise noisy). If the connection is physically good at both ends, a bad wire could be the issue, or there could be an electrical interference problem (ex, try a different location, different cable).
PC-wise, have you tried a different computer? If the serial port is native (built into the board and not a seperate USB to serial), there could be some problem with the port or with the OS (ex, IRQ conflict, though those should be a thing of the past). Could be port drivers, could be some other OS problem, easiest to try a different PC.
Of course, as a last, and perhaps most difficult means of testing, try another RN-1 board. In re-reading your post, you have a 2nd RN-1, so this leans back towards the PC and the cable (unless you've got two programming cables, then it's back on the PC or a grounding problem or noise issue).
About the glitchy behavior:
You mentioned a few interesting things there - the seperate "as a battery" power supply, the repackaged cells - I'd still put an oscilloscope on the power to see if there's a dip or noise in the power supply - can you get access to one at college? How many amps is the power supply rated for?
There are only a few things that can mess with serial communication: either end of the connections, or the something in the middle. Device-wise, the RN-1's serial hardware shouldn't be flaky (it could be, but I haven't seen it). The same should also be true PC-side, though an external USB to serial adapter could have its own issues if you're using one (some just don't work very well). If you're using one, I'd recommend trying a different make / model.
What may be more of the problem is the connection. If there is a grounding problem, you could see this kind of issue (if, for example, the ground on the power supply or the PC is different). I recommended same power strip for PC / modem issues when I did that kind of work a couple decades ago, same kind of thing here.
If the battery has the power (and from what you mention, it should - what was the Amp Hour rating of the cells?), then it is a communication issue. Still, I would remove the servo connections for testing, if only to reduce the chance that they're interfering with communications in any way.
The connection could also be bad on the small plugin jack at the RN-1, there aren't a lot of ways to fix this. There could be debris or a film on the contacts in the jack, contact cleaner may help, or may not do much - replacement is possible, if a similar jack can be found. Typically if you have a jack issue, it would work better if you put pressure on it from some direction. Could also be cold solder joints on the connector, or that the jack is still attached, but broken loose of its solder joints to where the connection isn't consistent (this should be visible under a magnifying glass, but I doubt that's the case here). An oscilloscope would be helpful as you could check the signals at the RN-1 (ex, make sure they aren't dropping out or are otherwise noisy). If the connection is physically good at both ends, a bad wire could be the issue, or there could be an electrical interference problem (ex, try a different location, different cable).
PC-wise, have you tried a different computer? If the serial port is native (built into the board and not a seperate USB to serial), there could be some problem with the port or with the OS (ex, IRQ conflict, though those should be a thing of the past). Could be port drivers, could be some other OS problem, easiest to try a different PC.
Of course, as a last, and perhaps most difficult means of testing, try another RN-1 board. In re-reading your post, you have a 2nd RN-1, so this leans back towards the PC and the cable (unless you've got two programming cables, then it's back on the PC or a grounding problem or noise issue).