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.