Announcement

Collapse
No announcement yet.

Mouse Odometry

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mouse Odometry

    We are considering using a regular optical non-laser computer mouse to track the robot location. It is effectively a camera. I think it's legal for multiple reasons. Not being an illegal part <RG01>. It's USB camera device so legal by the same logic as cameras <RE13>. <RE17> is not applicable since the mouse is covered by these rules and the spirit of this rule seems to be more covering processing devices and less sensors. I also believe this is in the spirit of FIRST because it has been used in FRC in the past. The legality of this device also follows the same logic as the legality of the [URL="https://www.intelrealsense.com/tracking-camera-t265/"]Intel

  • #2
    It would be wired of course.

    Comment


    • #3
      The reason the T265 was ruled legal was because it was supposedly UVC-compatible. That's the constraint in the GM. It has to be UVC-compatible. Now that being said the T265 provides the actual position data through means other than UVC, so I'm not sure if it really should have been allowed......

      For regular sensors, connecting via USB is not allowed. Only connections to the Expansion Hub (CDIM will be illegal next season).

      The other problem using a mouse would present would be that you'd probably have to modify the kernel to prevent the HID driver from claiming the device and thus preventing you from being able to talk to it yourself.

      Comment


      • #4
        Ok, thanks! What if we found a mouse that could connect to the control hub? Or, could we use the sensor itself, like this: https://www.espruino.com/ADNS5050?

        Comment


        • #5
          Originally posted by 10298 Brain Stormz View Post
          What if we found a mouse that could connect to the control hub?
          Being able to connect it directly to the CH instead of needing a USB hub (as with a phone) doesn't change the two points I mentioned earlier, though.

          Originally posted by 10298 Brain Stormz View Post
          Or, could we use the sensor itself, like this: https://www.espruino.com/ADNS5050
          Using the sensor itself, rather than over USB as in a mouse, would probably be perfectly legal if you could interface to it. Interfacing would be the problem. That sensor you linked (and seemingly basically ALL mouse sensors) use SPI, which is not supported with the current FTC platform. Technically you could bitbang it from the DIO pins, but that would be so slow it would be useless, because of how expensive hardware calls are on the FTC platform. (Milliseconds in FTC vs microseconds on a microcontroller)

          Comment


          • #6
            Alright, we'll look into it.

            Comment


            • #7
              Would this be legal? (https://www.ebay.com/itm/OEM-HP-PS-2...1/184347506651) SPI mouse-> (https://www.silabs.com/development-t...evelopment-kit) SPI to I2C bridge -> I2C cable -> Expansion hub.

              Comment


              • #8
                Originally posted by 10298 Brain Stormz View Post
                Would this be legal? (https://www.ebay.com/itm/OEM-HP-PS-2...1/184347506651) SPI mouse-> (https://www.silabs.com/development-t...evelopment-kit) SPI to I2C bridge -> I2C cable -> Expansion hub.
                Note: rule numbers I reference are for the new Ultimate Goal game manual (numbers have changed since SkyStone).

                Using an I2C<-->SPI bridge for connecting to a sensor is definitely not legal (see RE18). They are allowed for controlling addressable LED strips (see RE13-C), but not for sensors.

                Now, that being said, going back to your original idea of using a USB mouse, the new GM seems to allow using any USB sensor with the Control Hub (see RE12-A), but clarification would still be needed because as it's written using USB sensors wouldn't necessarily be allowed with a phone, but it wouldn't make any sense to only allow it for the CH.

                Assuming it's allowed, you're back to the problem of trying to steal control of the mouse away from the kernel HID driver. Contrary to what I said before, it might(?) actually be possible to do this?
                Attached Files

                Comment


                • #9
                  Thanks. I don't quite understand why the bridge wouldn't be allowed.

                  Comment


                  • #10
                    Originally posted by 10298 Brain Stormz View Post
                    Thanks. I don't quite understand why the bridge wouldn't be allowed.
                    See this post. Relevant quote:

                    The allowance for SPI-I2C bridges to control LEDs was rolled into a generic interface module description in RE12.c - explicitly only for control of light sources.

                    Comment


                    • #11
                      Also see this thread.

                      Comment


                      • #12
                        Discussion of legality aside, would the CP2120EK even serve the intended purpose? In user manual, it looks like it would bridge from i2c sensors to a SPI master, but not the reverse.

                        Comment


                        • #13
                          Originally posted by jkenney View Post
                          Discussion of legality aside, would the CP2120EK even serve the intended purpose? In user manual, it looks like it would bridge from i2c sensors to a SPI master, but not the reverse.
                          Hah, I had missed that. That being said there are devices that do the reverse, such as this one that I've used to control addressable LED strips under the exemption for interface modules for controlling light sources.

                          Comment


                          • #14
                            Originally posted by jkenney View Post
                            Discussion of legality aside, would the CP2120EK even serve the intended purpose? In user manual, it looks like it would bridge from i2c sensors to a SPI master, but not the reverse.
                            Yeah sorry I meant the other way around.

                            Comment

                            Working...
                            X