Unable to get griparm working

[Marc Vieleers]

Hi,

I've recently build the Vorpal Hexapod with my son as a fun to do experiment during the covid period.

We have a well functioning robot, however when we connect the griparm we run into an issue. We are following the manual. We've tested that the servo's (elbow and grip) move to the correct starting position. Now we want to operate the griparm. As soon as we turn the dial back from RC until the beep and "then a bit further", all the legs contract and move to the left (it's almost like the robot has a cramp).

We are using release V3 for gamepad and hexapod. 

Any ideas what might be the issue?

Also one other question. It appears that google chrome has finally discontinued the support for flash as per January 21st 2021. Therefor we cannot use scratch anymore. Is there a workaround known to get this working again?

Regards,

Marc

[vorpalrobotics]

Hello,

You should try disconnecting one grip arm servo at a time. See if either one works by itself.

The curling up thing is a sign that something is drawing too much power. This could be because one of the servos is bad in a way that causes it to short circuit, or it could be a wiring issue (for example if the servo extension wire was damaged and shorted out the red and black wires, or if the servo driver was defective in some way or had pins touching each other.)

Another possible cause would be if the batteries are too weak to handle the extra two servo motors that the grip arm provides. You will be able to tell this using the "one motor at a time" test. Try first the claw motor, disconnecting the elbow. Let's say that works. Now try disconnecting the claw and connecting the elbow. Let's say that also works. However, let's say it doesn't work when BOTH are connected. Since either servo works on its own, that shows that the servos themselves are ok. But since both together fail, that shows that some how there is not enough power for both at the same time.

Regarding scratch, MIT continues to insist they will be supporting 3rd party extensions for scratch 3 (which doesn't require flash) "soon". I am working on a python extension now to get people up and running in the interium. They have been promising since early 2020 and I think covid has delayed things.

Hope this helps,

-Steve P.

[Marc Vieleers]

Hi,

Thanks for the response!

I've had issues with a first version of a UBEC. It didn't pass correctly through demo mode even, so I replaced the UBEC and now the bot easily completes the demo and is much more responsive. So I have the feeling, this UBEC is actually ok, but I might be wrong...

I did the test you suggested all with FULL batteries:

* connected elbow servo to the accessory port, connected to position 12 of the driver board

* connected elbow servo to the accessory port, connected to position 13 of the driver board

* connected grip servo to the accessory port, connected to position 12 of the driver board

* connected grip servo to the accessory port, connected to position 13 of the driver board

All outcomes are the same.

* When I turn the dial back from RC, I hear two beeps and all legs contract and turn left

* If I only turn the dial a little bit back from RC, this doesn't happen immediately, they curl up a little and turn left a little, but when I press F2 they contract completely and move left completely.

I also tested with NO servo's connected at all. I can put the dial in griparm mode. But as soon as I press F2, it contracts and turns left again.

It works fine when in RC mode with the 12 servo's of the legs connected, so it couldn't be a power issue when no other servo's are connected, right?

Any other ideas?

Regards,

Marc

Op maandag 8 februari 2021 om 16:34:12 UTC+1 schreef vorpalrobotics:

[vorpalrobotics]

Yes this is a very odd problem if it doesn't work in griparm RC mode even with no servos connected for the grip arm, but it works fine in normal RC mode.

I am thinking either a defective servo driver or the nano should be reflashed. The theory behind reflashing the nano would be if there is a bad spot in the program memory then maybe the grip arm mode is going haywire and crashing the nano.

I would start by reflashing the nano since that doesn't cost anything. If that doesn't work, try a new servo driver.

Did you buy a kit or parts from us? If so we would send you a new servo driver under warranty.

[Marc Vieleers]

So the update is that I refreshed both the nano in the gamepad as well as the nano in the hexapod. Issue still the same.

Next step will be to try a different servo driver. Will take a while before I can test that. Will let you know how it went.

I've self sourced the parts, so need to te replace it by myself ;-) But thanks for asking.

Regards,

Marc

Op dinsdag 9 februari 2021 om 16:04:22 UTC+1 schreef vorpalrobotics:

[Marc Vieleers]

Today I received a couple of new servo driver boards. Installed the new one in the hexapod, but to no resolve.

I also finished building my sons hexapod. Exactly the same issue.

I've now tried several servo driver boards and different Ubecs. All with the same outcome, flawless operation in normal mode, but as soon as the hexapod is in griparm mode, even without servos actually connected, the legs all cramp together and turn counterclockwise.

I'm out of options... any ideas?

Regards,

Marc

Op zondag 14 februari 2021 om 16:27:10 UTC+1 schreef Marc Vieleers:

[vorpalrobotics]

Well this is a tough one, I've never seen it before.

The only final thing I could suggest is that maybe one of your libraries is corrupted or not a version that we've tested with. If you go to http://tinyurl.com/vorpalfiles and go to the hexapod folder and the libraries folder, and make reinstall all of the libraries from the versions we have there, that might fix any corruption or version issues.

[Marc Vieleers]

Hi Steve,

I already used the libraries from the dropbox folder after I saw during the build that using a more up to date Sdfat library did not compile correctly.

As you indicated they might have been corrupted, I went ahead andI removed all library files from the Arduino library directory. Copied the libraries from the dropbox folder, used the V3 ino files for both gamepad and hexapod (also straight from the dropbox folder) and uploaded to both the hexapod and the gamepad.

Unfortunately, same issues remain.

I've made a quick video that shows that all operations function as normal and then what happens in griparm mode.

The video can be downloaded here: https://forysta.nl:2000/sharing/lUiUHmvuk

00:03: ADJ mode

00:07: TST mode

00:26: DEMO mode

00:57: STOP mode

01:02: switching OFF

01:03: RC mode

01:08: switching ON

01:17: using some mode buttons on gamepad and directional buttons. All working normal, including F2

01:44: turning to A mode

when it’s just barely in A mode you can see the legs starting to contract with every beep

02:04: switch mode button to Demo and back to RC, normal operation restores

02:09: switching to A mode and a bit beyond that. Now you see that the legs fully contract immediately

There seems to be a relationship with the speed in which the legs contract and the resistance from the 10K potentiometer.

Does this give you any other ideas of the issue? Would it make sense to test with an older version of the software? Since what version was the griparm introduced?

Regards,

Marc

Op zaterdag 20 februari 2021 om 17:21:08 UTC+1 schreef vorpalrobotics:

[vorpalrobotics]

This indicates to me that there might be something wrong with the potentiometer. In the code, the potentiometer exact value doesn't matter, all that matters is whether it's within ranges for each mode.

Mechanically, the pot has a "wiper" that is moved by turning the dial. It might be possible that the wiper somehow is shorting out +5v against GND when it hits a certain range.

A quick way to test this without swapping pots is to simply change the code so that "RC" mode is the same as "A" mode. This would disable the ability to go into pure RC mode, but it would quickly test if everything other than the pot is good.

To make this change, go to line 3220 of the hexapod code, and it looks like this:

} else if (p < 950) {

    Dialmode = DIALMODE_RC_GRIPARM;

  } else {

    Dialmode = DIALMODE_RC;

  }

Just change that last line to also run the griparm code, in other words it would look like this:

} else if (p < 950) {

    Dialmode = DIALMODE_RC_GRIPARM;

  } else {

    Dialmode = DIALMODE_GRIPARM;   // NOTE: FOR TESTING, WAS DIALMODE_RC

  }

If that code now correctly controls the griparm in RC mode (full clockwise on the dial) then that proves all hardware is good EXCEPT the potentiometer. It would rule out battery, servo driver, etc. as problems. That would prove that the pot is shorting out +5V vs GND right around the "A" (accessory) setting.

In that case, either just keep using the changed code, or swap out the pot. Personally, if the pot is bad, you can't be sure it won't get worse eventually and just short the entire robot out, so I would replace it at some point.

NOTE: Although I've never seen a pot damaged in this specific way, I have seen them damaged and made nonfunctional because the soldering iron was touching the lead just a little too long. You shouldn't touch it more than 5 seconds and use the lowest temperature setting that works on the soldering iron.

[Marc Vieleers]

Hi Steve,

I've made the quick patch, however I changed it a little bit.

} else if (p < 950) {

    Dialmode = DIALMODE_RC_GRIPARM;

  } else {

    Dialmode = DIALMODE_GRIPARM;   // NOTE: FOR TESTING, WAS DIALMODE_RC

  }

Gave an error that DIALMODE_GRIPARM was not declared...obviously.

So I changed to:

} else if (p < 950) {

    Dialmode = DIALMODE_RC_GRIPARM;

  } else {

    Dialmode = DIALMODE_RC_GRIPARM;   // NOTE: FOR TESTING, WAS DIALMODE_RC

  }

All goes well powering up in RC mode.

Then when I hit F2, same issue again.

As soon as I go out of that mode, for instance by pressing W1 contraction stops again.

Made a video again: https://forysta.nl:2000/sharing/j8501pR6a

Did you also get the email from John Vroom, that he is actually experiencing the same issue? Apparently, I'm not the only one experiencing this.

I'm open to other things to test...

Regards,

Marc

Op maandag 22 februari 2021 om 16:02:27 UTC+1 schreef vorpalrobotics:

[Marc Vieleers]

Checked the serial monitor a few moments ago.

The output when in RC mode and pressing F2 and then W1 is in RC Mode.jpg

The outspent when in Griparm mode and pressing F2 is in Griparm Mode.jpg

You can see that after pressing F2 it produces a lot of empty lines in the serial monitor, not sure why...

Op dinsdag 23 februari 2021 om 14:15:58 UTC+1 schreef Marc Vieleers:

[vorpalrobotics]

Hello,

After reviewing the code, I found that a bug seems to have crept in that was causing this issue. Very sorry for the problem. Apparently I had pushed out a slightly older version of code to the VORPAL_FILES than I had been testing with.

The new version with the fix is now posted in tinyurl.com/vorpalfiles under the SOFTWARE_HEXAPOD/SOFTWARE_HEXAPOD_CURRENT_RELEASE_V3r1c folder.

Very sorry for the issue. Part of the problem is that much of my beta testing occurred at maker faires where I would run new versions of code on six or seven robots with lots of little kids randomly pushing buttons all day. That would turn up issues really fast. With covid, we've had no events in over a year now.

I'm very surprised at how long it took someone to report the issue, since we've sold lots of grip arm kits in the last few months since the bug was present. It's possible most of those kits had the prior version of code, but there are definitely numerous people who most likely have the broken code. I will be sending a notice to all the people who bought griparm kits in the last month or so indicating that they need to reflash the robot.

-Steve P.

[Marc Vieleers]

Hi Steve,

VICTORY!!!!

You did it. This bug fix fixed it. Griparm is working like a charm now.

So glad you found the issue. Guess I have a few spare driver boards now. LOL.

Just out of curiosity...what was the bug that caused the legs to contract?

Thanks again for staying on the issue.

Regards,

Marc

Op donderdag 25 februari 2021 om 16:29:51 UTC+1 schreef vorpalrobotics:

[vorpalrobotics]

It was kind of complicated. In V3 there was a new feature called "smooth move" that makes the F3 F4 movement modes much smoother than they were before by interpolating tiny movements between receives of packets from the gamepad (which only come once every 100 milliseconds so previously the F3 and F4 modes were very jerky). That feature was always in the grip arm code, but in V3 it was generalized so that any "state retaining" positioning mode (like F3, F4, and a few of the new double-click modes have) would also move smoothly. There was a logic bug such that when going into RC_GRIPARM mode the target positions of all the leg servos would essentially be zero. (In this case the targets are supposed to be set to the current position so the legs don't move, just the grip arm).

That all may or may not make sense to you ;)

Sorry again for the error.

[Marc Vieleers]

It actually makes sense, and it explains the legs all moving to that zero position, what I called contracting.

Don't worry about the error. Glad it's fixed.

Hopefully you'll be able to finalise that workaround for the scratch issue soon.

Cheers,

Marc

Op vrijdag 26 februari 2021 om 13:40:59 UTC+1 schreef vorpalrobotics:

[vorpalrobotics]

The weird coincidence that really caused the trouble is that it is very common for all the legs to seek zero position when there is a low power problem.  That's why I initially focused on hardware issues.