Using USB Sensors?

[GuyM142]

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

[TheHolyHades1]

Originally Posted by GuyM142

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 .

[RyanCahoon]

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.

[z_beeblebrox]

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...

[Dunngeon]

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

[rich2202]

Originally Posted by Dunngeon

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?

[NotInControl]

Originally Posted by RyanCahoon

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.

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/...1/croms-1.html and https://www.google.com/url?q=http://...G4QKjgg6V70BJw

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

[adciv]

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.

[sparkytwd]

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.

[NotInControl]

Originally Posted by sparkytwd

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

[RyanCahoon]

Originally Posted by NotInControl

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.

You don't need a graphical environment to read a mouse.
http://www.linuxquestions.org/questi...8/#post3031622
http://en.wikipedia.org/wiki/GPM_(software)

[NotInControl]

Originally Posted by RyanCahoon

You don't need a graphical environment to read a mouse.
http://www.linuxquestions.org/questi...8/#post3031622
http://en.wikipedia.org/wiki/GPM_(software)

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.

Originally Posted by NotInControl

...It is not impossible to pull something like this off, and many people have already attempted to do what I believe you are suggesting...

Originally Posted by NotInControl

...To pull this off for FRC I am sure will require modification to the driver as well as hardware....

Thanks,
Kevin

[SenorZ]

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.

[jman4747]

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.

[Anthony Galea]

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?