[Dprglist] Visualizing data [was: PID]

David Anderson davida at smu.edu
Sun Oct 4 22:00:11 PDT 2020


Murray,

Cool.  Nice library of robot papers you are collecting.  The Thrun book 
is pretty challenging,  but I think it was part of the impetus for the 
whole self-driving car industry, so also a classic.

However you solve the logging-and-graphing situation, you will thank 
yourself later on, when you start implementing more complex behaviors.  
You queried once "Why is this so hard?"  Graphing your data makes it 
easier, because you can better understand what the robot is doing.  
Hominids like pictures.

But, and that's a big but,  I perhaps speak for others as well as myself 
when I say that it's all hard.  Not just driving straight and PID 
controllers.  Robotics is hard.  That's one of the reasons I'm drawn to 
it.   When it becomes easy I'll probably wander off into something 
else.   Although in fairness that hasn't happened yet, going on 3 
decades.   Just saying.  :)

onward

dpa



On 10/3/20 6:26 PM, Murray Altheim via DPRGlist wrote:
> On 4/10/20 11:29 am, David Anderson via DPRGlist wrote:
>> Hey Murray,
>>
>> Sounds like great progress.
>
> Hi David,
>
> Well, it doesn't feel like it quite yet, but as you know sometimes it 
> takes
> a bit of tooling before one actually gets down to the real task. So I'm
> looking at the likes of GnuPlot or Grafana as tools to better see what's
> happening. Staring at console outputs only goes so far.
>
>> I also log robot data on board in real-time and then dump it at the 
>> end of the run.  The command on the PC end that fetches the data also 
>> makes
>> a gnuplot "*.plot" file and invokes gnuplot with that as an argument. 
>> So I type in "get_log" and a graph pops up.
>
> If I can manage to get the Python library to work, at the end of the 
> run it
> will actually do an http POST and upload the CSV directly to 
> Elasticsearch,
> where if I choose the same ID value for the data will deliberately 
> overwrite
> the existing record. Then if I've got Grafana pointing at that record 
> I can
> automatically refresh the visualisation. So if I manage to get that all
> running it will be almost entirely hands-free, apart from hitting F5 to
> refresh the screen (which might not even be necessary, dunno, I think 
> Grafana
> can probably do live updates).
>
>> The graph that Bob Cook sent is exactly what we were looking for. 
>> (thanks Bob!).   A couple of comments. Note that his PID is 
>> responding to a large
>> step function, no slewing at all of the input.  This is the test that 
>> you
>> want to run.   Disable any input slewing.  It just makes the PID 
>> tuning harder.
>
> Yyes, thanks, understood. In my messages here I might be confusing 
> things,
> as my end goal is this "one meter behaviour" where I want to tune the 
> whole
> behaviour. This is distinct from the PID tuning, which is a prerequisite
> for the behaviour. It's just that the first time I ran "One Meter" the 
> robot
> came to rest and then did its fidgety hunting back and forth thing, which
> was when I noticed this.
>
>> It's useful to reflect that the PID controller must be able to react
>> quickly to step changes in the environment, even if the control input
>> itself is correlated and smooth.  So running on a rough surface, or 
>> when a wheel drops into a depression for example, the feed back 
>> velocity > coming from the motor encoders may change a lot, and 
>> change rapidly.
>> That means the proportional error will also change a lot and change 
>> rapidly, even if the control input is smooth.  The PID controller has
>> to be able to react quickly to counter those changes.
>
> Understood. And tuning my PID controller on the bench with the wheels
> unloaded is I'm guessing not going to quite do it, that the robot needs
> to be sitting on the ground and actually moving. I've been doing my
> preliminaries on the bench then putting it on the wood floor to fine
> tune.
>
>> So acceleration and deceleration ramps that present a smoothly changing
>> input to the controller can't be implemented by making the PID 
>> controller
>> itself sluggish overall. Or rather, they can, but it's probably not  
>> > what you want  :)
>
> Understood -- I'm not doing any PID tuning while trying to solve that
> One Meter behaviour.
>
>> Every robot builder should have that Flynn/Jones book on their shelf.
>> A classic.  If you haven't already seen it there is another, later book
>> by Joseph Jones, "Robot Programming: A Practical Guide to Behavior 
>> Based Robotics" which is also excellent, a bit more technical and 
>> focused on subsumption.
>
> Thanks, I've seen that on Amazon but didn't connect it was the same Jones
> as the other book.
>
> I've also collected some references to Rodney Brooks' papers related to
> subsumption and BBS:
>
>   https://service.robots.org.nz/wiki/Wiki.jsp?page=RodneyBrooks
>   https://service.robots.org.nz/wiki/Wiki.jsp?page=References
>
> Maja Mataric was one of Brooks' students at MIT and pioneered what is
> called Socially Assistive Robotics (a sub-field of human-robot 
> interaction)
> and has a few books to her name, "The Robotics Primer (Intelligent
> Robotics and Autonomous Agents series)", which I haven't read but looks
> interesting. It is available as a PDF at:
>
> http://www.ict.griffith.edu.au/~vlad/teaching/robotics.d/RESOURCES/mataric-primer.pdf
>
> She is a co-author of "Embodiment in Socially Interactive Robots 
> (Foundations
> and Trends(r) in Robotics)". That's an $80.00 academic paperback but also
> available again as a PDF:
>
> https://viterbik12.usc.edu/wp-content/uploads/2019/06/Mataric%CC%81_Embodiment-in-Socially-Interactive-Robots.pdf
>
> Finally, there's "Probabilistic Robotics" by Sebastian Thrun, also 
> available as
> an expensive academic hardcover ($65) or as a PDF:
>
>    https://docs.ufpr.br/~danielsantos/ProbabilisticRobotics.pdf
>
> I think I'll copy these over to my Kobo Reader and tackle them on the 
> train
> to work this week... thanks for tickling me to go out and look for these.
>
> There's been quite a lot of research in the "low end", affordable side of
> robotics (compared to what's done by NASA, industry, etc.) and a lot 
> of my
> interest is in seeing (eventually) what I can do with a relatively cheap
> ($500-$1000) robot and access to all this research. It feels like an area
> that still has lots of room for exploration...
>
> Cheers,
>
> Murray
>
> ........................................................................... 
>
> Murray Altheim <murray18 at altheim dot com>                       = 
> =  ===
> http://www.altheim.com/murray/ ===  ===
> = =  ===
>     In the evening
>     The rice leaves in the garden
>     Rustle in the autumn wind
>     That blows through my reed hut.
>            -- Minamoto no Tsunenobu
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org


More information about the DPRGlist mailing list