Re: The Hardest Drive System To Program:
 

Can someone give me some examples of how swerve drive is controlled via joysticks? :confused:

Re: The Hardest Drive System To Program:
 

There are many ways but two common ways among teams who do it for the first time are
-one joystick with the y axis being speed of the wheels the buttons being rotation of the whole robot and the x being the rotation of the wheels(the easiest)
-one joystick with the rotation based on where the stick is on the joystick and speed is the R vector of the x and y axis and rotation on buttons
but really there are A LOT of ways to control a swerve.

Re: The Hardest Drive System To Program:
 

hardest robot to program as far as drive goes is definitely an omni drive robot that can switch to akermon.... which is similar to a monster truck drive train where the front and back wheels turn all with encoders to exact positions we called it the crazy bot because the watchdogs would go crazy and the r0bot would go plum crazy and head for the nearest programmer for some reason

Re: The Hardest Drive System To Program:
 

I never understood the watchdog, does it starve when a set of instructions took too long? I never had to explicitly feed it. Most of them usually were simple programming errors similar to index out of bounds or segment fragmentation.

Re: The Hardest Drive System To Program:
 

The watchdog monitors one thing and controls another.

In the case of the system watchdog, it monitors incoming control packets and controls the outputs of the robot. The deadline is 100ms, and this means that if the incoming packets take longer than 100ms to arrive, the watchdog shuts down the outputs. As an example, lets say that the driver sets the tethered robot to driving forward, and then the clumsy mentor steps on the enet cable, yanking out out of the laptop. Since this breaks comms, the watchdog notices and will shutdown the outputs. Same situation if your laptop runs out of power, you shut down the radio, you yank the enet from the dlink, you lose power to the dlink, etc. If the cRIO doesn't get incoming packets, you don't want the robot to keep driving, and the system watchdog does that.

For the User watchdog, it observes your code's ability to call the feed function. If your code doesn't call feed, it shuts down the outputs. As an example, lets say that the robot is driving forward, and the forgetful mentor sets a breakpoint in your teleop function. Without the watchdog, the robot will maintain its current course. With the watchdog, it will halt the motors.

The Safety Timers are similar to this, but are I/O specific. They observe the updates to a given output and will shutdown that output if the deadline is missed. Again, this could be due to a breakpoint, delay, infinite loop, dead thread, bad logic, etc.

Does that help?
Greg McKaskle

Re: The Hardest Drive System To Program:
 

Once you've got omni programmed, adding Ackermann is very simple.

Re: The Hardest Drive System To Program:
 

Yes, that helps and explains it.

Re: The Hardest Drive System To Program:
 

Omni wheels.

Re: The Hardest Drive System To Program:
 

I'm trying to understand what you mean by "Ackerman" in the context of an omniwheel vehicle.

Ackermann is a very specific type of front-wheel steering, used by automobiles, in which the vehicle turns around a point lying on the line which is colinear with the axles of the rear wheels.

Since an omni-wheel vehicle is holonomic, you certainly could mimic this behavior, but why would you want to? An omni-wheel vehicle can be given a "car-like" driver interface simple by disabling the strafe command - and using only rotate and fwd/rev commands.

Re: The Hardest Drive System To Program:
 

What we ended up trying to accomplish was a, I guess you'd say, mirrored Ackermann. AKA, the front wheels would turn 45 degrees to the left, and the back wheels would turn 45 degrees to the right. Then, when triggered, the drive sticks would toggle over to omnidrive, with each wheel receiving the same value from the joystick.

Re: The Hardest Drive System To Program:
 

Several comments:

1) I thought you just said you were using omni wheels. Omni wheels aren't usually steered. Can you post a picture of your drivetrain?

2) I wouldn't suggest using the word "Ackermann" to describe what you stated. The whole idea of Ackermann is that the wheels are steered to different angles, not the same angle. The point of this is so that each wheel's axis will point to the center of rotation of the vehicle so that the wheels do not scrub.

3) Not sure I understand what you mean by "omnidrive, with each wheel receiving the same value from the joystick". Each wheel of an omnidirectional vehicle typically receives different commands, not the same commands.

Re: The Hardest Drive System To Program:
 

I apologize. I was confused myself when I was talking. We had standard wheels. In "Ackermann" the wheels turned opposite of each other to make tighter turns. In "Omni", say you pushed the joystick to the left. Each of the four wheels would go left. Up-left, each would go up-left.

Re: The Hardest Drive System To Program:
 

You mentioned in your earlier post that your team encountered a great deal of trouble trying to get this programmed properly.

Have you given up, or is your team going to try to tackle this as an off-season learning project?

Re: The Hardest Drive System To Program:
 

We do still have the original drive train, and we've cycled programmers since then. That sounds like a good summer project, actually.

Re: The Hardest Drive System To Program:
 

Here's a resource that your new programmers might find useful. It discusses swerve and Ackermann programming.