We plan to use an RC controller for our robot (connected with USB to the driver station), we will not use any of the wireless capabilities of the controller. Will it pass inspection?
1 Like
R905 *FIELD wireless only.
Other than the system provided by the FIELD, no other form of wireless
communications shall be used to communicate to, from, or within the OPERATOR CONSOLE.
and
R707 *No other wireless allowed. No form of wireless communication shall be used to communicate
to, from, or within the ROBOT, except those required per R702, R706, and tags used for location
detection systems if provided by the event.
It looks like you may be ok**. I recommend seeing if you can turn off or disable the wireless radio in the controller or if the controller automatically stops the communication when the USB is plugged in. This will ensure that both R707 and R905 are objectively being met.
**I’m not a Robot Inspector and there have been instances where teams were prohibited from using similar devices in the past due to the concern of Wireless Interference.
Yep, fundamentally the same thing* as teams that use bluetooth controllers in wired mode from a rules standpoint. Be prepared to demonstrate that all communication is wired if necessary.
Iirc 2767 does this as well?
*If anything, more in the clear as you’re definitely not on the 2.4ghz spectrum.
Do you have a link to the controller you plan on using?
Our controller is in the shape of an RC controller but has no RF section in it. Only a USB interface.
It will probably be a taranis qx7 since our drivers used them for fpv drones.
Realflight?
(for the OP) Some R/C simulators have controllers that are USB-only. You may want to look into those as well. I have an old Interlink Plus for my R/C simulator (though I would strongly suggest getting a newer model than mine).
I hope this is sarcasm… otherwise, you’re one of today’s lucky 10K. The current standard for R/C is 2.4GHz. The older 900MHz controllers are scarcer than color wheel spins were in 2020.
We’ve done the same thing since 2017 and it has passed since that time. No one has given the controller a second glance. Toward the end of the inspection checklist you’ll be asked whether you have any unauthorized wireless communication with the robot. The correct answer is always “no”.
1 Like
Yes, The controller from Realflight (Interlink/Spektrum). We have older versions of this one:
This controller should meet your preferences and all ready has USB. If you figured out the USB part with your controller then it should work.
Apparently I have been too cheap to notice.
1 Like
Triple Helix is using a Radiomaster TX16s, with the transmitter disabled, like for simulator flying. These are the same controllers we use for our quadcopter flying. It turns out that flying a quad in angle mode is remarkably similar to driving a swerve drive train. It affords a great opportunity for students to develop muscle memory and instincts for driving the robot while flying their quadcopters.
We have a pair of Radiomaster Zorro controllers on order, and we’ll be playing with those when they arrive. The drivers might switch if they like the Zorro better.
1 Like
Todd, are you having any issues with the FRC simulation when using your tx16s? About half the time I try to run the simulation, it aborts after it first comes up.
1 Like
We’ve never used the FRC simulation that I know of. No problems using it with the driver station, though. Maybe a prob with the simulator software. You can use a windows utility to make sure the controller is connected properly to Windows.
Hi. I’m one of the programmers for 2363. I’ve used the TX16 with the simulator from within VS Code several times with no significant problems. As Todd mentions, the first step is to ensure it shows up on the USB Gamepad/joystick config utility in Windows. I’ve run it with the simulator on a Mac, too, and had no problems.
You may also want to make sure the TX16 is plugged in and in Joystick mode before launching the simulator. The joystick suddenly appearing on the USB may cause confusion.
Thanks. We’ve had it plugged in and it does show up in the Game Controllers app on windows and everything looks good. We’re also seeing some weirdness on the bot; when we boot the bot and connect, some controls don’t work (e.g., forward axis) while others do (e.g., lateral axis), but if we deploy the same software using VS Code, everything works fine. I may uninstall and reinstall the driver station app to see if that does anything helpful. Getting desperate with 2 days until first event.
Our development path for our controllers has been first to make everything work with a standard gaming controller. Most of the development of the drive base software was done without the TX16s. Then we remapped the TX16s axes so they show up identically to the game controller axes. This requires a custom model profile in the TX16s with some of the axes reassigned and direction flipped. (And the radio transmitter disabled, of course) With matching joystick axes, when we’d get weird behavior (we were working on swerve drive) it was easy to swap between controllers and confirm the problem was in the software, not in the controller.
Once the stick axes were sorted out, we mapped the buttons and switches of the TX16s controller to the game controller button channels in Windows. Because the physical buttons and switches on the TX16s are different than the game controller, there isn’t a direct crossover. The TX16s buttons and switches are assignable in OpenTX, but the game controller is hardware mapped. Plus, different game controllers have different mappings. Our programmers wrote software that recognizes which controller is plugged into the USB port and uses the correct button mapping for that controller. Because we use different controller types for driver and operator, if they ever come unplugged and replugged, the software always knows which is which.
This method of redefining the motion axes in OpenTX to match the game controller axes, then using the robot code (I think) to recognize the controller type for the switch/button mapping allowed us to easily move from the TX16s to the Zorro controller with minimal disruption. Our student drivers prefer the gaming controller ergonomics of the Zorro, while appreciating the high quality RC style joysticks on the motion axes.
Using OpenTX / EdgeTX features allows the driver to dial in the curves of the axes for optimal robot control. On one of the 3 way switches we can adjust the axes scaling for high, medium, and low rates. We use the high rates for most of our teleop driving, switching to low rates for climbing. On another 3 way switch we have 3 different levels of expo. This lets new drivers understand how changing rates and expo effects the handling characteristics of the bot.
For those who doubt the benefits of using RC style controllers over gaming controllers, here’s a video of our highest scoring match.
1 Like
Sadly, in software there are a million different ways to do things.
You’re welcome to look at our joystick config process and joystick detector to see if anything jumps out at you.
You can look at our JoystickDrive, too. But we do a few convoluted things in there - e.g. we call a routine to calculate the stick value rather than just getting the raw value.
We’ve clearly had good success using the RadioMaster controllers, and haven’t found any particular oddities.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.