The Hardest Drive System To Program:

[aaronweiss74]

Originally Posted by Katie_UPS

I found that programming penguins to make the robot move was pretty hard. Those buggers are stubborn once you run out of fish!




(couldn't help myself )

I believe 1717 would beg to differ.

[Captaindan]

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

[davidthefat]

Originally Posted by Captaindan

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

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.

[Greg McKaskle]

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

[davidthefat]

Originally Posted by Greg McKaskle

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

Yes, that helps and explains it.

[Ether]

Originally Posted by Captaindan

hardest robot to program as far as drive goes is definitely an omni drive robot that can switch to akermon

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

[davidthefat]

Originally Posted by mobilegamer999

My opinion would be swerve drive.
Theres pre-made code in WPILIB already for Tank, Arcade, Mechanum and one other I believe. But swerve is the only one out there that requires pretty much completely custom code to get working.

Now, keep in mind, I have not used any prewritten code except for theses classes: PWM and Joystick.

[davidthefat]

Originally Posted by basicxman

Any base drive system is not incredibly difficult to program. Programming an effective control system for a drive system is hard.

see:

• Failure checking (state machine, redundancies)
• Human error correction
• Mechanical error correction

I really don't know what to answer your question with, everytime I think of a drive system I think of all the ways I could improve it with pieces of code - would be very difficult to pick a single one, and would require more context.

Can you elaborate on your 3 points a bit more please?

[basicxman]

Originally Posted by davidthefat

Can you elaborate on your 3 points a bit more please?

> Failure checking (state machine, redundancies)
If a sensor relating to your drive system fails, what is going to happen to your robot? A lot of teams run a separate task on the cRio that monitors for failures and then triggers a state change when a failure occurs. For instance let's say a gyro stops reading values, rather than making the robot spin in circles, the drive system would ignore gyro values.

Redundancies being increased reliability of a drive system, http://en.wikipedia.org/wiki/Redundancy_(engineering)

> Human error correction
How much money would you put on the fact that your driver can hold two joysticks at 50% throttle precisely? Probably not a lot.

> Mechanical error correction
Motors aren't made equal. Two motors of the same model will rarely go at the same speed. Using encoders and other techniques to correct this.

[davidthefat]

Originally Posted by basicxman

> Failure checking (state machine, redundancies)
If a sensor relating to your drive system fails, what is going to happen to your robot? A lot of teams run a separate task on the cRio that monitors for failures and then triggers a state change when a failure occurs. For instance let's say a gyro stops reading values, rather than making the robot spin in circles, the drive system would ignore gyro values.

Redundancies being increased reliability of a drive system, http://en.wikipedia.org/wiki/Redundancy_(engineering)


> Human error correction
How much money would you put on the fact that your driver can hold two joysticks at 50% throttle precisely? Probably not a lot.

> Mechanical error correction
Motors aren't made equal. Two motors of the same model will rarely go at the same speed. Using encoders and other techniques to correct this.

"Safe Mode": If triggers, switches to bare bone drive code.
Multiple sensors to "check" each other

We just used dead zones for the human error part

We didn't use the encoders because there was too much noise that I did not trust them enough to use it.

[NickE]

Originally Posted by davidthefat

What is the hardest drive system to program?

http://www.youtube.com/watch?v=vwFrCpYavt4

[davidthefat]

Originally Posted by NickE

http://www.youtube.com/watch?v=vwFrCpYavt4

I would totally be down to do that. *cough*JPL, accept my internship request*cough*

[Chris is me]

Programming a drive so that you CAN control all of its functions is easy.

Programming a swerve drive so that it's intuitive and easy to control those functions is not.

[davidthefat]

Originally Posted by Chris is me

Programming a drive so that you CAN control all of its functions is easy.

Programming a swerve drive so that it's intuitive and easy to control those functions is not.

From your experience, how long does it take for the swerving wheels to actually orient itself to the right angle? What kind of motors are required to be able to rotate the wheels and not stress out the motors?

[buildmaster5000]

Originally Posted by davidthefat

From your experience, how long does it take for the swerving wheels to actually orient itself to the right angle? What kind of motors are required to be able to rotate the wheels and not stress out the motors?

Depending on the gear ratio and the distance required, about .5 second is a reasonable estimate. We used swerve and didnt use PID loops without a visible performance loss. Using window motors and the wildswerve pods, we probably averaged .25 seconds between posisitons using window motors. We also limited the wheel to only have a 180 degree range of rotation.