OpenServo.com

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

I have been trying this on windows and linux, running the python scripts and on linux, the Test app will not even find the servo. It find OSIF but will not find the motor and I have checked the power supply and it appears good.

I have compiled the Kernel successfully and installed the Test App and also tried python scripts but the motor will not recognize. However my boss would like me to get them working on Windows before linux.

On windows, the test app works fine and it finds the motor and I can change the P/D values and such, we just have the movement problem from above.

jharvey · Posted: Tue Jun 22, 2010 2:33 pm Post subject:

This is what I get when I run it on my Ubuntu platform. I get the same on a windows machine, however, I feel lsusb is less stable on windows, so I typically use the Ubuntu platform.

jharvey · Posted: Tue Jun 22, 2010 2:47 pm Post subject:

I believe the test GUI on windows will have some troubles. I seem to recall that when you choose the firmware file to upload, it uses / instead of \, and can't find the firmware file because of that. Also the GUI doesn't have those extra registers, so you can't do some things. This is what happens on my XP machine, when I plug it in, and click scan bus.

jharvey · Posted: Tue Jun 22, 2010 3:06 pm Post subject:

A quick check from my end, it appears the only extra complications from the windows end of this, is that the test gui can't command or interpret the OE position. It jitters quite a bit, reports bogus position values and uses a fair bit of power. You can read the voltage, current, send specail commands, turn on and off PWM, ect.

I found with my windows machine, it was common that lsusb would get buggered, and a full PC reboot would bring it back. Perhaps there is a better way to refresh lsusb, plug into a different port, ect, but I didn't figure that out. I moved to a Linux platform and many of those issues went away. When it got buggered, neither the python scripts or the test gui would work. That's why I felt the problem was with lsusb.

Also note, the PWM button doesn't contain feed back, and it's a toggle command. So it can get out of sync, such that PWM on is off and off is on. So it might not work quite as expected, but does typically function for basic testing purposes.

Another way to check the power supply issues is to set your scope trigger at say 6 or 6.5V, then if the scope triggers you know you had a very short drop. I found most of my problems ended up being the power supply. The OSV3, really wants a solid supply.

I found a 9V battery worked well for my power supply. It was one of the ways I confirmed my supply was sluggish. I found a 9V battery would work, but I would get some issues when connected to the supply.

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

I just tried the python scripts on Linux...they work well! That is a relief. We will work on getting them running on Windows later. For me, I have to sudo them rather than just calling the right away. It seems ginge was right in the other thread about the usb libraries being restricted. That explains a lot.

The movement does appear shotty however, and the script will pause for large amounts of time before moving it to the correct position (however it does go in full rotations). I will procure a 9V battery. The voltage is not too strong for the OSV3?

ginge · Posted: Wed Jun 23, 2010 8:22 am Post subject:

jharvey · Posted: Wed Jun 23, 2010 8:41 pm Post subject:

I believe the skipping is less common at lower speeds. Also if it's working now, the 9V probably isn't required. Sounds like potentail supply issues have been worked out.

The large pause, is because the script doesn't have a window, it searchs for an exact position. OE is more accurate than the back lash in the gears will allow. So if you put one of those arms on the servo, then touch it lightly, that will change the OE feed back slightly, typically producing the desired position, then it will move to the next position.

Also the OE in the MG995 has the magnet closer to the sensor. In the MG996, the magnet is slightly farther away. This may change the status registers of the OE on that servo slightly. So the 995 is slightly specail.

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

Well we only have 1 MG995 and 7 MG996s. I have not noticed any differences between the two however.

One of my concerns ties back to the different registers. I've been reading over the python scripts and I've noticed that there appears to be an osv2 file and an osv3 file. The os-move.py script links to osv2 and imports methods, variables and functions from that file. But the register declarations at the beginning of the osv2 and osv3 are different if everything is labeled correctly, it would seem like many methods write to the correct registers for a Version 2 OpenServo board and not the newest OpenServo V3 board which is in the motors you installed.

I'm slightly confused between all the many registers that are implemented in different versions of the firmware whether they are -dev or not -dev. On www.openservo.com/TWIProtocol, there is a list of all the registers. Do you know if those are correct and whether I should use those in my code writing?

ginge · Posted: Fri Jun 25, 2010 8:44 am Post subject:

Hi,

Yes, that page is the current non -dev register layout.

For the definitive reference, you can use the registers file that are part of the core openservo v3 code

http://www.openservo.com/viewcvs/OpenServo/AVR_OpenServo_V3/registers.h?revision=1.2&root=cvs&view=markup

cheers
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/