[Dprglist] IRON REIGN robot presentation - Today at Noon

Sun Dec 18 20:59:23 PST 2022

Karim,
Thanks for the explanation about power and implementation limitations, and the difference in FRC vs. FTC mentoring..
I misunderstood the nudge stick. I thought it was applying recoil or something to stabilize the arm when it rotates, kinda like a long balance bar on a wirewalker.

Good stuff.
John Swindle

-----Original Message-----
From: Karim Virani <pondersome64 at gmail.com>
To: John Swindle <swindle at compuserve.com>
Cc: dprglist at lists.dprg.org <dprglist at lists.dprg.org>
Sent: Sun, Dec 18, 2022 7:35 pm
Subject: Re: [Dprglist] IRON REIGN robot presentation - Today at Noon

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 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/20221219/ced78a18/attachment.htm>