<div dir="ltr">What a cool discussion - prompted by a high school team none-the-less :-)<div><br></div><div>John - </div><div>the convolved/deconvolved command approach you mention reminds me of a similar thing related to Moore's Law.</div><div>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.</div><div>It seems that the wavelength of light was limiting silicon feature size - because light would diffract around the mask and degrade the doping process.</div><div>As I recall, they got around that by creating masks which were 'compensated/corrupted' to account for the diffraction issue -</div><div>Which then allowed creating silicon features which were otherwise impossible due to the wavelength of light used...</div><div><br></div><div>Cool stuff...</div><div><br></div><div>Carl</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 18, 2022 at 7:37 PM Karim Virani via DPRGlist <<a href="mailto:dprglist@lists.dprg.org">dprglist@lists.dprg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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. <div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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."</div><div><br></div><div>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 <a href="https://www.controlglobal.com/control/loop-control/article/11296423/a-straightforward-explanation-of-feedforward-control" target="_blank">feed-forward</a> characterization next Tuesday.</div><div><br></div><div>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.</div><div><br></div><div>Again, thanks for your comments and let us know if any else comes to mind,</div><div><br></div><div>Karim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 17, 2022 at 3:57 PM John Swindle via DPRGlist <<a href="mailto:dprglist@lists.dprg.org" target="_blank">dprglist@lists.dprg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="color:black;font:10pt Arial,Helvetica,sans-serif">
<div><span style="font-size:13.3333px">Karim and Iron Reign Team,</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">Thank you very much for the DPRG presentation today. Big competition!</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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:</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px"><a href="https://youtu.be/huRUoGbdIuU" target="_blank">https://youtu.be/huRUoGbdIuU</a></span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">Another example shows how quickly the platform settles after harsh movements with lots of moving metal:</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px"><a href="https://youtu.be/bAFA3BCijHI" target="_blank">https://youtu.be/bAFA3BCijHI</a></span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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!</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px"><a href="https://youtu.be/F_Auxy_ZdAQ" target="_blank">https://youtu.be/F_Auxy_ZdAQ</a></span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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!</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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?</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">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.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">Sorry for the long answer, but maybe something will help at some point. And sorry if I am repeating stuff I've written before.</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">Thanks for sharing your development process and your current status today!</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">Good luck!</span></div>
<div><span style="font-size:13.3333px"><br>
</span></div>
<div><span style="font-size:13.3333px">John Swindle</span></div>
<div><br>
</div>
</div>
_______________________________________________<br>
DPRGlist mailing list<br>
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank">DPRGlist@lists.dprg.org</a><br>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" rel="noreferrer" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br>
</blockquote></div></div>
_______________________________________________<br>
DPRGlist mailing list<br>
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank">DPRGlist@lists.dprg.org</a><br>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" rel="noreferrer" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br>
</blockquote></div>