On the 2015 season we will have the new RoboRIO which has a usb input,
Does it mean we will be able to use USB sensors with it?
Like an optic mouse for positioning during auton and so on.
Is it even possible to use an optic mouse as a sensor? (in theory)
What kind of output does it have and how can it be used?
Thank you 
Without knowing too much about either the RoboRIO or mice, my guess would be that you could, but it wouldn’t net you very much useful data. I think the RoboRIO just provides a USB interface like any other USB interface, so USB sensors should be possible in theory. You may need some custom drivers/software though. As for the mouse, I think the laser from the mouse isn’t strong enough to travel any significant distance without dispersing; that’s why you can’t use your mouse more than a couple inches from the table.
Again, take this with a grain of salt. I’m not a programmer nor do I claim to be :D.
The RoboRIO is reported to run Linux on an Arm processor, so any USB device that has drivers for that platform should be usable. There seems a good chance that this will include mice.
I’ve heard of mice being used on robots in the past in the same way that follower wheels are currently used on FRC robots. The standard problem with this is many mice can’t read linear speeds fast enough to keep up with many FRC robots, though some of the newer gaming mice look like they may be up to the task. For autonomous, where drive speeds are typically kept lower to make the robots more controllable, this would be a much more viable approach.
The data output would presumably be the same as for a standard mouse: X-Y movement coordinates, either as deltas or accumulated measurements.
Razer claims that its high-end gaming mice track up to 200in/s or 16 feet/s. That’s fast enough to track most FRC robots.
I’m curious how hard it will be to implement this sort of tracking and how well it will work. Keep Chief Delphi posted…
It could prove very useful for tracking the robot in a 3d-space, something we want to do if we ever build a Swerve again
I’d love to see that Swerve Drive that can elevate the robot. BTW: How do you measure the Z axis with a mouse?
The 2015 control system does run Linux, however it is a custom RT Embedded Linux produced by NI and it is headless (No desktop graphic environment like other popular linux distros). While I am sure there is a mouse driver included I doubt plugging a mouse in will do anything useful. I will plug in an optical mouse into the roboRio tonight to see what happens and report back.
However, with that said, it sounds like the original poster is trying to use the mouse as a sensor to perform robot navigation. The user should note that the mouse is not the best sensor to do this without modification. The optical mouse is just a camera that takes approximately 1500 pics per second of the surface it is on. It uses a Digital Signal Processor on board to calculate heading and distance traveled by comparing images. The current Diode diffuser in most optical mouses won’t work if moved a few centimeters off the surface.
It is not impossible to pull something like this off, and many people have already attempted to do what I believe you are suggesting. See: http://home.roadrunner.com/~maccody/robotics/croms-1/croms-1.html and Redirect Notice
To pull this off for FRC I am sure will require modification to the driver as well hardware. If the user wants to have a sensor which tracks actual robot motion, a more FRC robust idea would be to build an enclosure with two omniwheels mounted perpendicular to each other, and have an encoder reading each wheel. This would be more inline with a trackball mouse, however made using more reliable parts for FRC. As the robot moves these wheels will contact the ground, and because they are omnis, wont add too much drag to the normal robot motion. Having two of these position a known distance from each other can also help the user calculate yaw about the robot center. Some FRC teams have done similar in the past.
Hope this helps,
Kevin
This is sounding interesting. I think we’ll need to write a linux app to read what the mouse is doing, but I think this is possible. The only two issues I know are the max distance from the surface (as noted) and the maximum tracking speed of the mouse (which you seem to have taken care of).
How far above a surface can you hold the mouse and still have it track? I’ve seen different ones with different distances over the years.
I think your best bet is to use encoders on the drive wheels. The optical sensors in mice don’t have to have super low error accumulation. 2 years ago, my team had good luck with differential steer drive dead reckoning. I think we worked out that accumulated error over an aggressive 2 minute match would be less than a foot.
It depends on what the original poster is trying to achieve which determines if encoders on the drivetrain will meet their needs or not.
Encoders on the drivetrain will spin if the wheel slips, so the sensor will indicate motion even when the robot base is not moving. I.e when the robot is stalled against the wall or another robot or when slipping during a rotation.
Most of the time if your just focused on auto this usually isn’t a concern for many teams in Autonomous, but if the user is after true position of the robot base, encoders on the drivetrain won’t work. A global sensor is required.
There are only only a limited number of gobal sensors available to the FRC environment, because were indoors, on carpet, high EMI, etc, and even then each case has their pros and cons. No soluton is an end all be all solution. It just depends on what the OP is trying to achieve.
As a control engineer you want to find the sensor which tells you the information you need, or can deduce rather quickly, and fully understand when the sensor information provided is invalid. Becuase there will be times its invalid
Regards,
Kevin
You don’t need a graphical environment to read a mouse.
http://www.linuxquestions.org/questions/linux-newbie-8/reading-mouse-device-615178/#post3031622
I never stated or suggested you need a graphical environment to use a mouse. I just suggested what the OP was asking would not be native behavior and software/hardware modification is likely.
Please see the below quotes. Even as such, reading the mouse values is only 1/2 the battle, understanding how to modify sensor so that it is appliacable to the FRC environment is the other, in my opinion, more challenging half. This is why I proposed a omni-wheel approach.
If you have a different solution please suggest it.
Thanks,
Kevin
This thread seems to have died out. Either folks gave up or they’re working on some top secret implementations… 
One of our mentors just bought a mouse that can read up to 3.3m/s and 2ms data updates. The major issue is very limited proximity. Only has a 1.5mm lift-off distance.
I was looking into this as well. However my thought was to plug the mouse into a single board linux computer (RPi, Beagle Bone, Jetson TK1) and UART/RS-232 to the roborio. Then mount the mouse to an apparatus that holds it to the floor via a light spring and can also retract it up into the robot.
Does anyone know how hard connecting an arduino with the native usb connector and communicating using serial 9600 would be in order to replace using an ethernet shield, or would it be easier to simply use the shield?
Beta testing team here. The RoboRIO has some support for USB<->Serial devices, like the Arduino and other FTDI devices. You should not need an ethernet shield to do this. Be careful about powering the Arduino over the USB on the RoboRIO though. I don’t think it will let you pull more than 500mA (USB Spec) so no massively long blinky LED chains.
You can install additional drivers on the RoboRIO (provided it supports Linux) so software is generally not an issue. For USB, National Instruments does have a “durable” USB cable they were showing at St. Louis this year.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/210962
Additionally, you could try using direct RS-232 or I2C with the arduino.
You could always attempt something similar using a camera pointed at the floor. NI provides some pretty easy to use optical flow VIs.
You could always attempt something similar using a camera pointed at the floor. NI provides some pretty easy to use optical flow VIs.
Alas a standard webcam won’t have nearly the frame rate necessary to keep up with a robot moving at 15ft/s. That’s why mice have always been interesting since the new gaming mice have some pretty significant specialized processing power on-board. It is the case that some optics magic will need to take place in order to not have the mouse dragging on the carpet.
500 mA is the USB 2.0 spec’d max current for Vbus. You should not generally expect more than that from that standard.
That said, the roboRIO is designed to be able to operate with USB 3.0 cameras (at USB 2.0 data rates), but that means roboRIO can source 900 mA per host port so that those cameras function reliably.