|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: making a duel driver system
We use two of these to control our robot; I think they have 12 buttons you can check. The driver controls the base of the robot and the minibot deployment system while the operator controls the arm and the pickup.
Programming wise, you need to declare two controllers (not sure if you guys are using WindRiver like us) but Joystick *driver; and Joystick *operator; are declared and motors are controlled based on inputs from these two controllers. Is that enough information? Feel free to ask question! |
|
#2
|
|||||
|
|||||
|
Re: making a duel driver system
Quote:
As for Xbox, as Vikesrocks has mentioned, they're also USB. I've found some of the 3rd-party ones have issues being recognized by Windows/NetBeans/Labview (we've never used Windriver), so if you're going that route, your best bet is using one directly from Microsoft (because they made the OS, too. Ironic!). |
|
#3
|
|||
|
|||
|
Re: making a duel driver system
Those gamepads PriyankP first mentioned are the same gamepads used to control the robot in FTC. They are useful for operation of the robot's features, but watch out for the analog sticks of the gamepads, they hardly ever cause the robot to stay still. The robot still creeps slowly when they become released so for the robot to really stop moving that needs to be programmed by creating a "dead zone".
|
|
#4
|
||||
|
||||
|
Re: making a duel driver system
Quote:
|
|
#5
|
|||||
|
|||||
|
Re: making a duel driver system
Quote:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|