[Dprglist] IRON REIGN robot presentation - Today at Noon

Sun Dec 18 17:35:24 PST 2022

Thanks to all the participants in yesterday's presentation! The team will
strive to implement your suggestions. It's unfortunate they couldn't
present a well-tuned robot - they are at a point where slowing down
progress to stabilize for a presentation is not an option. They needed to
make the move from direct control of the arm's DoF to IK based control and
while they made that move Friday night, you saw that the transition is not
complete from tuning and safeguards standpoints. Hopefully things will be
further along at their next showing.

John, thanks for the in-depth follow up! Yes, the team is working toward
more responsive control over their crane and chassis. It's hopefully within
their reach. One thing about FTC is that the power budget is much more
constrained than for FRC. There is a maximum of 20 amps at 12 volts across
the entire robot and each individual motor can consume 11 amps at stall.
And the allowed battery can't really deliver 20 amps without a significant
voltage drop. So they have to balance available power across the various
subsystems and particularly the shoulder joint on the arm operates at near
stall conditions when the arm is well extended. So they are often working
in the regime where the power available to a specific axis compared to the
momentum of the platform or arm is far from an optimal ratio, while
available battery voltages are swinging a lot.

I think their design is far more vulnerable to these challenges than most
FTC designs. That's a side effect of their strategy to reach far outside of
their robot's center of mass to minimize the amount of driving they'll need
to do. That's a high risk strategy and it remains to be seen if they'll
pull it off. Their mechanical team is trying to reduce the mass of the arm
and add torque while their code team is continuing to work on tuning and
automation.

To answer your question - they are not allowed to "grab" the poles. Only
one point on the robot can come into contact with the pole and any kind of
curved contact surface can be interpreted as violating that rule. So that's
why they are working on that straight "nudge stick."

One thing they need to work on is adding a feed-forward term to their PID.
They haven't done custom PID-F before, but it's pretty clear they need to
at least try that. Then the PID terms can focus on finer-grained and
dynamics adjustments while the F term can focus on the primary fight
against gravity for a given configuration of the arm. While I personally
don't want to be responsible for burdening the group with yet-another PID
discussion at RVNV, I might want to ask for advice about feed-forward
<https://www.controlglobal.com/control/loop-control/article/11296423/a-straightforward-explanation-of-feedforward-control>
characterization next Tuesday.

I have generally advised my teams to avoid automated PID tuning.  When past
teams have tried it, it seemed like they ended up with a poorer intuition
for the dynamics of their systems. I'm sure it's a great option for
professional engineers who have a good number of systems to tune on a
regular basis. My students need to get a feel for the basics of control
theory first. In FTC, the students need to do the designing, building,
coding and debugging. The mentors may only advise.

Again, thanks for your comments and let us know if any else comes to mind,

Karim

On Sat, Dec 17, 2022 at 3:57 PM John Swindle via DPRGlist <
dprglist at lists.dprg.org> wrote:

> Karim and Iron Reign Team,
>
> Thank you very much for the DPRG presentation today. Big competition!
>
> You asked what filter another FIRST team used to make their big robot stop
> on a dime without wobbling. This is the sort of response I was referring to:
>
> https://youtu.be/huRUoGbdIuU
>
> Although the robot is heavy, about 160 pounds, and even though most of the
> weight is in the base, nevertheless it is quite tall and the cargo it
> carries has mass. It accelerates and stops very quickly with very little
> wiggle. It drops its cargo with no residual movement in the cargo.
>
> Another example shows how quickly the platform settles after harsh
> movements with lots of moving metal:
>
> https://youtu.be/bAFA3BCijHI
>
> Along with all the stuff moving at the same time, I like how quickly the
> grappling arm calms down after being flung open at the end of the contest.
>
> Not related to my comments, but I love the whiffle balls in the
> competition at the end of the next video. I saw them compete in Houston.
> Loud cheers when the balls started flying!
>
> https://youtu.be/F_Auxy_ZdAQ
>
> Regarding wiggling towers: I know some of that was determined by giving
> the platform impulses of movement, from the motors, I believe, not from
> hammers as I said, and recording the response of the entire robot.
>
> Then the desired controls are filtered with an inverse of the response
> before being sent to the actuators and motors. I think that can be
> translated to PID instead of using a filter. I think that is what you are
> doing.
>
> I think someone at DPRG showed how to automate the PID tuning by looking
> at the reactions (Might have been you!). You are probably doing that also.
>
> I spoke up because it seems that tuning and tweaking are often done ad-hoc
> or by trial-and-error instead of by knowing the system response. That's
> just an observation. Not trying to comment on what you are or are not
> doing. When you don't know the actual system response, the deconvolution
> can easily makes things worse!
>
> I don't make motive systems. I play with audio. I use the cheapest stuff
> available: 50-cent speakers, 79-cent microphones, cheap consumer-grade
> audio adapters, lousy amplifiers. Then I force those things to act the way
> I want them to act.
>
> So, there are at least two classic way of forcing something to do what you
> want, so long as you don't exceed some limits: transmitter equalization (Tx
> EQ) and receiver equalization (Rx EQ). I have the luxury of doing either of
> these because I don't care how the things behave as long as I get a usable
> result. You don't have that luxury because you can't grab the pole and hold
> it steady while you drop a cone on it (which would be Rx EQ). Hmmm... Can
> you do that?
>
> In my case, Rx EQ puts greater burden on the robot to process the audio
> before using it. I greatly prefer Tx EQ. The pings are not filtered by the
> transmitter: they are simply screwed-up (convolved) before they are stored
> in the wave file. No processing at runtime.
>
> I choose a (not convolved) waveform that I think will give me best
> resolution with minimum ping width and lowest human-audible amplitude, then
> pass that through the system in the arena, note the difference in the
> recorded result, and then start tuning the transmitter.
>
> I put all that stuff away a few years ago, so I don't have a demo to show.
> Maybe I will put it back together again.
>
> Sorry for the long answer, but maybe something will help at some point.
> And sorry if I am repeating stuff I've written before.
>
> Thanks for sharing your development process and your current status today!
>
> Good luck!
>
> John Swindle
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20221218/539bbfd7/attachment.htm>