#omnidrive.fullscale

Syren 25Amp Speed Controller Wiring

OmniDrive Completed: Speed Assembly above

 The video shows a 16x Speed Assembly of almost the entire thing. The bloggie battery kept on dying after being on for 3 hours at a time. I did manage to capture some key moments, but otherwise, it does give a general view of how the robot was assembled.

The past 2 weeks have been pretty crazy to say the least. When the parts came in, we started building as fast as possible, and the first run through was completed by Friday of last week. The sample video can be seen here:

As for specific engineering & construction notes, I'll start from where I left off last time. 

Assembling and Wiring

After building the main chassis frame, it was time to mount the electronics and the motors.

Because the wormgearbox motor has a lot of torque, it's very common to use a direct drive. In many cases, this simplifies design and construction a lot.

The best way to show how we mounted the wheels to the motor is using the exploded view from SolidWorks:

Spacer and a 1/4-20 Screw keeps the omni-wheel place. The NPC motor happens to have a 1/4-20 tap hole at the center of the shaft, so this was pretty convenient.

The spacers on the other hand wasn't so convenient. If you've cut spacers before using a hack saw or band saw, you'd know that it's never accurate. On a plus note, it was a bit idiotic for me to purchase spacers that had an EXACT 0.5in Inside Diameter (ID) delrin tube.

  We had to cut the delrin to simulate a C-Clamp, and pretty much force it to work. On the plus side, this gave room to the key of motor so that both wheel and shaft turn in sync. 

After doing one successfully, we just repeated this pain/reward cycle 3 more times:

(guess what the mallet did there? Yup. Forced the ~0.5in ID Delrin to the ~0.5in OD shaft).

After the wheel and motor module was assembled, it's really a matter of putting it all together.

The electronics was also straightforward. I'll give a paint drawing of the schematics, but really it's just:

12V Battery -> Motor Controllers - > Motor.

The 12V battery also powers the Arduino using the female VIN pin header on the board. The arduino has a 5V voltage regulator that can handle around 20V of battery input.

Here's an attempt to demonstrate the wiring through paint:

Anything multiplied by 4x tends to look more complicated than necessary.

Look at the wiring though:

  Messy Christmas lights. (If you have a keen eye, you'll notice there aren't any VICTOR 883 speed controllers. I've explained this below).

Addressing Other Issues

Primarily, there are 2 issues with the design. One was addressed properly without much change, but the other is a bit more difficult.

High PWM Frequency - If you notice during the video testing, the motor has a very loud whining sound. Initially, we tried changing the PWM frequency sent by the arduino using this PWM Library.

This led to unfruitful results. I spent a lot of time trying to figure out why changing the arduino frequency doesn't do anything. When I contacted Shane from MITers, he said that the VICTOR 883 Speed Controllers will receive the standard RC signal from the Arduino, and the VICTOR will use its own 100Hz frequency.

He suggested to change to a different speed controller.

Here's a cool fact. The human hearing range is from 20Hz - 20kHz. All you have to do is put the PWM frequency in the >> 20kHz range and humans won't hear it anymore. It's still there. You just don't hear it. Cool huh?

I ended up just following Shane's recommendation and asked my supervisor to buy Four of these:

It's a Syren 25A Regenerative Motor Controller. EXTREMELY EXPENSIVE! In essence, it acts the same as a VICTOR controller but its transistors switch at a rate of 32kHz. 12,000Hz above the range of human hearing, so there's no way you would be able to hear the PWM frequency.

That did just the trick! 

I have another video of us testing the new motor controllers, but I'll save that for another post.

Addressing Traction/Slipping: If you watch the test run video again, the wheels slip whenever only 2 of the wheels are only functioning. The quick easy fix is to always maneuver using four wheels. But there are some movements where you just want to use 2 of the wheels...

This would've been easily solved using a suspension system. This would've been a bit more complicated and a bit more expensive. My previous design had it, but it did seem overkill and I believe $1000.00 more expensive.

In any case, I've been thinking about how to add a spring system to what we have now, and after a week of doing the problem, there's no easy solution unless I create a new motor module.

So how do you attain traction at all times without using suspensions? There's another design that we've been thinking of doing. Instead of using 4 omni-wheels, we would just use 3.

This is the tri-omni design:

We would've built it this week, but unfortunately the water jet wasn't really available. In addition, I hate dismantling a successful, functioning robot to create an unsure robot.

There's a few issue with the tri-omni design. The Center of Gravity is the most obvious one. 

As for controls, it's a simple linear algebra problem where you only use 2 of the vectors and make the 3rd vector dependent on it.

Anyway, We ended up not building this design, but maybe future UROPs can try this out. I've already figure out the wiring, programming, and mechanical design so all that is needed is manufacturing and assembly.

Other Traction Solutions:

I weigh 140lbs. When I rode the robot, it had a bit more traction than usual, but it's not that great. Putting weight on the robot obviously increases your dynamic friction but it really won't help unless the floor is even.

So how did we solve the traction problem? We didn't. It's sad that it has this critical flaw when it was first addressed from the very beginning of the design stage.

Other Aesthetic Development:

We proceeded to make the robot look more presentable.

Look, Black acrylic sheets:

And look how awesome it is when we mounted it:

I think I've addressed all of the assembly, wiring, and how we addressed all other issues.

Also, here's a quick summary: