FTC 16072-Quantum Quacks Updates

[alan412]

11 Jun (from Alan - coach)

• Have gotten motors to move using Java and Python (expansion hub)
• Have updated firmware on A301s using RHM2 (Love it running on systemcore. Other than the install being noisy, clean and works great. (Would be great if the summary could show what gearbox was attached)
• Would also like it if RHM2 had an "identify" for A301s that would make it's LED light up on the utility page. (this would also be great on the motioncore page)
• Would also be nice, if RHM2 could save the last "custom" firmware you uploaded so you could use it again and again.
• LEDs on Motioncore are leaky (ie, fault LEDs on right side have light spillover from PWR/MODE/STATUS)
• Random thought - if Systemcore had same CAN connectors as Motioncore then you could make an outreach bot with just a Systemcore and 4 A301s. This would also make this part of the device not a "waste" for FTC
• A tooltip over "Emergency Stopped" on the driver station that tells you how to reset the robot would be useful.

[jfabellera]

You can click the sun icon to identify the device (I realize the button is missing a tooltip):

[alan412]

Oh, I didn't realize that. Cool.

[ThadHouse]

Random thought - if Systemcore had same CAN connectors as Motioncore then you could make an outreach bot with just a Systemcore and 4 A301s. This would also make this part of the device not a "waste" for FTC

There'd be power concerns around this. Because then you have to run 4 motors worth of current over 1 microfit power wire.

And then systemcore internals would need to be updated to handle high current.

[alan412]

I didn't calculate the amount of current the A301s pull and see if four of them would fit within the envelope. Trying to think of some way those ports could be used.

[alan412]

23 Jun (from Alan - coach)

• Made adapters for Mecanum wheels (designing 3d printed part was very nice for spline shaft with tapped end. 3d printed hub press fit on and then screwed into tapped ned.)
• Mounted Systemcore and Motioncore
  • Bridge port is on opposite sides for Systemcore and Motioncore when they are both mounted with Logos showing with Systemcore on top. Perhaps move on Motioncore to left side. (Yes, a team could just mount the motioncore upside down)
  • Having a shorter cable for connecting Motioncore and Systemcore would be nice
• Mounted battery dock
  • I don't know a nice way to say this, but the battery dock is awful to mount. It doesn't have enough mounting holes and the M4 ones are only on one side. For something that is this large and this heavy, this needs to be fixed. For an advanced team, they could just design the robot around the battery dock. But we want this to work well for beginner teams as well. Please, please, please redesign this. I am happy to help look at proposed designs.
  • The connector on cable from battery to motioncore can't fit through the holes on GoBilda channel which is going to make wire management of that cable a pain.
• Wired everything up and verified that individual motors work. (Tomorrow will be making the mecanum chassis drive)

[alan412]

One other thing, it would be nice if there was some way to use the Rev Hardware Client utility without having to fire up the driver hub and enable. That feels really hacky.

[ThadHouse]

We’re not doing anything different when there’s no FMS. Field only talks to DS, not to the Robot.

We’ve thought about this problem for Years, this isn’t the first time it’s been brought up. The whole point is that it’s meant to be difficult to work around, because we want the DS to be the source of truth to allow motors to move. Web tech isn’t safe for that, and can easily result in a runaway condition.

An explicit design goal is that it should not be possible to bypass. Any ideas we come up with means there’s a hole that we need to close.

[ThadHouse]

Now we can look into adding a mode to the DS where it can enable actuators without robot code running. That'd make things a little easier, and make it so theres no interference with robot code.

But adding a way to bypass the enable heartbeat purely from the robot (Especially from web) is a massive safety issue.

[Kevin-OConnor]

Agreed with what Jan said. Fundementally, this is a safety issue, and any method that gets added to allow RHC to bypass it would allow arbitrary bypass, which is a big problem at an FRC scale. And since the heartbeat is universal for all motors, there isn't a way to override it for just A301's and nothing else.

I don't think being immediately dismissive of feedback like this without taking the time for the whole group of involved folks to consider, brainstorm, weigh in, etc. is appropriate. Alpha teams are taking the time to write up and provide feedback about what they believe would make the system easier to understand/use/etc. from their perspective and we need to be considerate in how we may be able to accomplish those things without being overly anchored on the way things are today.

Yes, we believe web technology does not afford sufficient safeguards for enabling powerful motors on an FRC robot. Yes, currently the A301 is using the same universal heartbeat as those motors. No, that does not mean that it is impossible to create a world where only A301s could be enabled by the web based RHC2. We may decide that the necessary tradeoffs are not worth it, but this is valid feedback that shouldn't be dismissed so readily.

[ThadHouse]

I actually had been thinking about this for a while (because I was trying to solve it too, as I agree its annoying). Essentially the only way to do this would be to have an entirely separate heartbeat just for A301. That means sending 2 heartbeat messages out every frame, and that results in doubling the amount of CAN bandwidth taken over each bus for heartbeats (As each bus would always need both). I don't know if thats a worthwile tradeoff.

[alan412]

Now we can look into adding a mode to the DS where it can enable actuators without robot code running. That'd make things a little easier, and make it so theres no interference with robot code.

That seems like a good idea to me. That way you won't have robot code fighting utilities and you could go to that mode without having robot code loaded.

[alan412]

24 June (from Alan - coach)

I now have a driving mecanum chassis. Code was done with Blocks!!

[alan412]

25 June (from Alan - coach)

SmartIO checks

• Rev Magnetic Limit switch works
• Rev Touch sensor does not (Submitted Issue REV touch sensor does not work in SmartIO port #311 )
• Rev Potentiometer works
  • Would be nice if you could change the type of SmartIO from the Hardware Snapshot. Changing it in code does update it here. (Submitted issue Should be able to set IO type from Hardware Snapshot #312 )

I2C

• 2M distance sensor detected on bus (haven't written code for yet)

Realizations

• REV LED ( https://www.revrobotics.com/rev-31-2010/ ) will not work without a special cable because it needs 2 signal pins.

Random thought

• I wonder if the converter board should have fewer than 6 slots so that teams can start migrating to not needing them. Or maybe a short cable instead of a board - that way you could use them when needed.

[alan412]

25 June (from Alan - coach)

A301 thoughts

• Could you please put some M4 screws on the opposite side? With them only on one side, we have to mount the A301s where we can't see the LEDs.
• Can you make the not enabled a solid color so it is easier to tell when you press identify on a particular motor?

[gearsincorg]

Hi Alan :)

I'm Just sayin'... "Not enabled" being a blinking LED is woven deeply into the fabric of FIRST through FRC (and just about all motor controlers.) I'm not sure I could live in a world where disabled didn't blink.... ::))

Perhaps "Identify" needs to be more obvious.

Mr. Phil.

[alan412]

31 July (from Alan - coach)

Putting in a Gobilda camera - everything seems to work (although clicking on the camera replaces the current tab with no way to get back. I might suggest making a tab like is done when you go to RHC2). The view did seem much darker than I would expect but we could play with the settings to get it to work.

However, putting in a Logitech C270 (arguably the most common camera in FTC) and it gives a completely black screen. I plugged the camera into a computer and it worked fine there. (removing the camera from the equation)

On the computer, the led on the C270 front stayed solid green while being used but it flickered on and off when it was on systemcore (in case that helps diagnose the problem)

Also, plugging in a limelight 3A did not get recognized as a camera. (I guess this makes sense since it isn't just a camera.)

For systemcore, we were on version
Active OS Release:
limelightosr-2027.0.0-beta13
Active OS Hash:
656f3d585d86d015e0f5a23252a5046e8eef2771

[Kevin-OConnor]

The C270 is expected to work per https://github.com/wpilibsuite/SystemcoreTesting/blob/main/LimelightVision.md

The 3A should work as well but needs to be updated to 2027 firmware

[Kevin-OConnor]

I would make an issue for you trouble with the C270 and tag Brandon to see if there is additional diagnostics he would want to look at to figure out what's going on there.

[alan412]

Ok, I'll make an issue

[alan412]

Done - Issue #350

[alan412]

We also noticed that there was an FRC field as default, but no pre-loaded FTC field.

[alan412]

We also used RHC2 to update the A301s. Pretty consistently (whether doing 1 motor or up to 3 at a time), it failed on the first time and did its own retry and succeeded on the second.

[alan412]

Another interesting thing is that on the Motioncore page, Motioncore reports about .5V higher than Systemcore and the driver station.

[Kevin-OConnor]

That one is being tracked in #306

[alan412]

@bhjelstrom - I went through our webcam box and tested the following:

All seem to work out of the box... I only looked at the viewfinder image, no additional testing

• UC60 / goBILDA Rolling
• Logitech C270 (720P Model B)
• Logitech C270 (960p variant - 5x)
• LL3A

Pixy - identifies correctly, correctly doesn't try to use it (since it isn't a UVC)

[bhjelstrom]

Thanks @alan412! I think I see why there are multiple variants of the c270 now too. The first iteration has some mjpeg bugs that we now warn about in release 14. They seem to be mostly harmless.