[Dprglist] IRON REIGN robot presentation - Today at Noon

Mon Dec 19 08:11:34 PST 2022

What a cool discussion - prompted by a high school team none-the-less :-)

John -
the convolved/deconvolved command approach you mention reminds me of a
similar thing related to Moore's Law.
As I recall not too many years ago - there were ominous predictions of
Moore's law getting stuck by the laws of physics and the wavelength of
light used in the silicon doping process.
It seems that the wavelength of light was limiting silicon feature size -
because light would diffract around the mask and degrade the doping process.
As I recall, they got around that by creating masks which were
'compensated/corrupted' to account for the diffraction issue -
Which then allowed creating silicon features which were otherwise
impossible due to the wavelength of light used...

Cool stuff...

Carl

On Sun, Dec 18, 2022 at 7:37 PM Karim Virani via DPRGlist <
dprglist at lists.dprg.org> wrote:

> 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
>>
> _______________________________________________
> 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/20221219/9a64e872/attachment.htm>