Spinnendings, ein Zwischenstand?

Was für ein Spinnendings? Achso, ja, fangen wir damit an.

Motivation

Vor ein paar Jahren hat sich irgendwann der Wunsch ergeben, einen achtbeinigen Laufroboter zu programmieren - also der Laufalgorithmus war das, was mich interessiert hat. Von Mechanik war ich zu dem Zeitpunkt noch weit weg. Einen ganzen Simulator zu schreiben war mir zu aufwändig, weswegen ich mich auf fertige Umgebungen wie Scrap Mechanic gestürzt habe - was aber sehr regelmäßig sehr einschränkend (oder kompliziert) war. Kurzum: es gab in der Richtung nichts zu holen.

Weiterhin enttäuschend ist die Auswahl an fertiger Hardware: Hexapods (mit sechs Beinen) gibt es wie Sand am Meer (vergleichsweise), "Spiderbots" mit sechs Beinen ebenso, und extrem wenige Modelle mit acht Beinen. Für einen Batzen Geld bekommt man ein Metallgerüst von Lynxmotion3, was mir aber zu groß und zu teuer war.

Auf dem 35C3 habe ich dann "Projekt Hannah"1 kennengelernt. Selbe Motivation, allerdings mit der konsequenten Umsetzung in Hardware (wenngleich auch ein Simulator parallel entwickelt wurde). Die Vielfalt an 3D-Druckern auf dem Kongress war dann damit zusammen der Auslöser für die Bestellung eines Creality Ender 3 und dem Beschluss, damit einen Körper zu drucken.

Vorstellungen werden konkret

Da ich nun alle Freiheiten der Welt hatte (glaubte ich zumindest), begann ich mit der Ausformulierung, was ich tun wollte. Meine Ziele:

  • acht Beine soll es haben
  • einer Spinne zumindest ähneln
  • die richtigen Proportionen dazu haben (keine Leiste mit acht weiteren Leisten dran)
  • nicht viel größer als ein Teller
  • frei programmierbar
  • "3dof"2: drei Motoren pro Bein für Rotation um x1, x2 und z. Eine Neigung um y war nicht geplant.

Die Beine wollte ich schlank halten (nicht so wie die Lynxmotion Teile) und die Motoren aus den Beinen raus, um das zu schaffen. Dazu überlegte ich mir folgendes: wenn der Körper selbst durch Federn gehalten wird, dann muss der dazugehörige Motor nicht mehr die Kraft aufbringen, den Körper zu halten. Die Kraft zum mittleren Beinsegment könnte durch einen Seilzug übertragen werden und dort die Feder anziehen (Denkfehler #1). Ich dachte mir weiterhin, dass ein Schrittmotor mit einer Winde die beste Option ist, um den Seilzug zu implementieren. Mangels Verfügbarkeit eines leichten Schrittmotors habe ich das dann jedoch gelassen und stattdessen einen Servo eingeplant.

Im folgenden Verlauf (über etwa ein halbes Jahr) habe ich viel Theorie über Spinnenanatomie gelernt, ausführliche Daten gesammelt und letztlich mein Modell grob skizziert. Der erste Wurf wurde dann mit 9g-Servos implementiert (nur ein Bein), und die ersten Messungen mit einer Feder haben ergeben, dass ich vermutlich einen stärkeren Servo benötige (Denkfehler #2?). Auf der Basis der mir bekannten Maße und Winkel sowie der Größe des konstruierten Aufbaus einer Hüfte mit zwei Servos vom Typ MG995 und einem SG92R habe ich dann den Körper entworfen/angepasst.

Zu dem Zeitpunkt hätte ich eigentlich schon mit etwas Mathematik aus der Ecke Maschinenbau herausfinden können, dass das Teil zu fett ist. Auch dass die Proportionen nicht mehr gepasst haben, hat mich erstmal nicht ausreichend gestört - ich hatte doch schon fast alles konstruiert und ausgedruckt.

Als die Teile dann (mit vielen kleinen Anpassungen und Rückschlägen) zusammengesetzt waren, war das Teil auf dem Tisch nicht in der Lage, auf seinen Beinen zu stehen.

Kurzer Rückblick auf die Zwischenstände:

  1. ein Bein mit Kniegelenk und einer Feder
  2. ein Hüftgelenk mit drei 9g-Servos
  3. ein Bein mit zwei MG995-Servos und einer Feder
  4. eine Bodenplatte
  5. ein Bein mit zwei MG995-Servos und zwei Federn
  6. eine Pappversion einer Bodenplatte und vier Beinen, fast standfähig
  7. neue Beine mit kleinerem Winkel am Knie (vorher 90°, jetzt etwa 45°)
  8. neue Bodenplatte
  9. Z-Achsengelenk, Stabilisierung oberhalb der Hüftgelenke
  10. Modell zusammengesetzt

Der letzte Stand ließ dann die Motivation unter den Tisch kriechen und in Fötusstellung verharren.

Fazit

Von meinen bisherigen Zielen habe ich kaum eines erreicht. War alles umsonst? Ist nichts mehr zu retten? Ich bin nicht vollständig überzeugt, dass dem so ist, aber ich versuche mich mal an einer Zusammenfassung.

  • die Größe ist eindrucksvoll, aber entspricht nicht dem ursprünglichen Wunsch
  • das Gewicht beträgt mehr als 2kg, und ich kann noch nicht sagen, ob das an den Schrauben liegt, die ich verbaut habe (Hornbach hat gut verdient).
  • die Servos an der Hüfte jaulen unter dem Gewicht auf und frei nach dem schwächsten Glied schaffen sie es nicht, den Körper zu halten.
  • die Beine selbst verdrehen sich leicht unter Last, was die Stabilität zusätzlich belastet
  • die Federn sind möglicherweise stark genug, jeweils 1/8 des Gewichts zu halten, vielleicht auch mehr - aber durch die ungleichmäßige Belastung müssen sie jeweils viel mehr tragen und kollabieren nacheinander genauso wie die Servos.
  • durch die sich verdrehenden Beine müssen die 9g-Servos auf der Achse zuviel Last tragen und schaffen es ebenso wenig.
  • die Stromversorgung wurde mit einem Labornetzteil sichergestellt, und ich kann noch keine Aussage darüber treffen, wie sich das Gewicht für die notwendigen 3-5A auf die Gesamtleistung auswirkt.

Für einige Details gibt es Lösungsansätze:

  • Plastikschrauben verwenden, um das Gewicht zu reduzieren
  • eine starre Verbindung statt des Seillaufs
  • mehr Federn/stärkere Federn
  • kleinerer Winkel zum Aufrichten
  • Bodenplatte ausdünnen

Doch keins davon kommt ohne weitere zu kompensierende Nachteile aus, oder ist einfach nicht effektiv (Bodenplatte zB wiegt kaum etwas).

Ich weiß nicht, ob das der Moment ist, wo ich einsehen muss, dass ich falsch geplant habe oder der, wo ich die Fehler einzeln angehe - letzeres hat mich bisher immer wieder in die Irre geführt, weil ich das Gesamtbild ignoriert habe. Für ein vollständiges Konzept müsste ich viel mehr Zeit investieren, als ich bereit bin.

Aber die Zeit hatte nicht nur Negatives mit sich gebracht.

Gelerntes

War ja ne Menge Zeit, und ich hatte viel Spaß dabei, all meine Mitmenschen mit meinen kleinen Fortschritten und Problemchen vollzuquatschen. Eine unvollständige Liste...

OpenSCAD

Üblicherweise nimmt man irgendein CAD-Tool, FreeCAD4 wäre einer der prominenten Vertreter, AutoCAD vermutlich ein Platzhirsch in der kommerziellen Welt, viele cloud-basierte Tools folgen. Ein Blick auf die eingesetzten Tools auf thingiverse5 gibt eine unverfälschte Statistik. Für Masochisten gibts auch noch blender und sonstige 3D-Modellierer. Nichts für Softwareentwickler, eher für Künstler - zumindest meiner Meinung und Einschätzung nach. Ich wurde damit nicht warm.

Stattdessen habe ich OpenSCAD6 für mich entdeckt und viel gelernt: die eigene Sprache ist recht unkompliziert und sehr schnell gelernt. Die IDE ist verbesserungswürdig, aber in Ordnung und der Aufgabe gut angepasst. Was ich lernen musste, war der Umgang mit einer funktionalen Programmiersprache in einem etwas größeren Projekt. Das hat (nach vielen Workarounds und Frickeleien) dazu geführt, dass es für mich (und andere) viel einfacher wurde, Teile für den Druck vorzubereiten und künstlich zu integrieren. FreeCAD hätte mir hier einiges abgenommen, vielleicht aber auch die Motivation.

Handwerkliches

Die ersten Löcher für Schrauben habe ich erzeugt, indem ich eine Schraube in die Schieblehre gesteckt und das Maß dann mit ein paar umliegenden Zehntel Millimetern gedruckt und vertestet habe. Die Ergebnisse speicherte ich dann als M3_TIGHT_TH und M3_LOOSE_TH. Irgendwann kam ich dann auf den Trichter, dass die Teile genormt sind und ich eigentlich nur nachschauen müsste. So recherchierte ich alle eingesetzten und benötigten Werte und schrieb inkrementell mehr Hilfsfunktionen, um "richtige" Löcher in meine Konstruktionen einzubetten. Außerdem kamen diverse Werkzeuge in meinen Besitz, um Teile passend nachzubearbeiten.

Microcontroller

Hier ist noch viel Spielraum übrig, was ich im Rahmen des Projekt lernen wollte, aber dennoch ist viel hängen geblieben: ein standalone Arduino setup (also ohne die komische IDE, bei der alles irgendwie eingebaut ist) mit relativ nativem C++ Code (die Arduino.h habe ich noch eingebunden) und Ansätzen, den Code auch zu testen, die Ansteuerung der Servos mit einer Hilfsplatine von adafruit, die Ansteuerung von Schrittmotoren mit und ohne Hilfsplatinen (wobei ich das vermutlich nicht ohne Not wiederholen würde) und letztlich eine Umsetzung in python, was mir softwareseitig leicht gefallen ist, aber wieder einige Denkprozesse zur Ansteuerung angestoßen hat. Da war ich in C++ doch zu sehr mit der Sprache selbst beschäftigt (was ich aber definitiv wiederholen möchte! Es hatte mich nur ausgebremst, und eine fertige Iteration war bitter nötig).

3D-Druck

Sicher hätte ich das auch mit allem anderen erreicht, aber so hatte ich eine Motivation für spezifische Formen und Eigenschaften. Manchmal hätte ich sicher mehr lernen können, wenn ich nicht so versteift darauf gewesen wäre, den nächsten achtstündigen Druck vorzubereiten. Da wäre zum Beispiel der Wechsel von cura zu slic3r, oder Materialkunde am praktischen Beispiel (ich habe erst vor kurzem erst eine Kalibrierung der e-Steps ausgeführt, weil die Drucke nicht katastrophal genug waren, das zu ändern). Anfangs habe ich mich viel mit dem bed leveling beschäftigt, was recht offensichtlich die primäre Problemquelle war. Außerdem wollte ich ein Gehäuse für den Drucker bauen, was nie fertig wurde (und ich dachte dabei auch zuerst nur an Temperaturstabilisierung, mittlerweile ist eine offene Frage auch die Notwendigkeit nach Feuerschutz).

Was ich letztlich umgesetzt habe, war der Austausch diverser Komponenten am Drucker. Vielleicht nicht alles notwendig oder zielführend, aber ich finde, es hatte jeweils seine Vorteile. - das Mainboard durch einen duet3d7 ersetzt, weil ich von der deaktivierten thermal runaway protection8 erfahren habe - einen bltouch gekauft, um das bed leveling zu automatisieren - das Mainboard unter dem Drucker entfernt, damit a) nichts reinfällt und b) es außerhalb des geplanten Gehäuses platziert werden kann - den IKEA Lack Aufbau vorbereitet (und nie zu Ende umgesetzt, weil die gedruckten Teile nicht vertrauenswürdig wirkten)

Dokumentation

Letztlich war es nicht viel, und vielleicht auch zu früh. Aber ich hatte die Motivation, das Projekt allen zur Verfügung zu stellen und dazu brauchte ich eine Bauanleitung. Infolgedessen habe ich mich informiert, wie man technische Zeichnungen aus OpenSCAD herauslassen könnte und auch Explosionszeichnungen möglich wären. Das hat sich dann als ziemlich invasiv heraus gestellt, weswegen ich damit erstmal warten wollte, da mein Fokus gerade auf einem Teil lag, bei dessen Aufbau ich mir nicht sicher war und meine Aufmerksamkeit gerade komplett durch Codestrukturierung und Geometrie blockiert war. Für das nächste Projekt wüsste ich zumindest, wo ich anfangen sollte.

Projektstruktur

Angefangen habe ich natürlich mit jedem Ding einzeln - OpenSCAD code hier, OpenSCAD libs dort, Arduinocode in einem Arduino IDE Projekt, ein paar heruntergeladene PDF-Dateien (teils ziemlich riesig), unzähligen Bookmarks in drei verschiedenen Browserprofilen, handschriftliche Notizen, Textdateien irgendwo mit Ideen, diverse Clouddienste für Notizen und Arduino-Simulationen... nicht alles habe ich wieder zusammengezogen - das wäre noch zu tun, würde ich morgen daran weiter arbeiten. Ich würde aber vermutlich wieder so anfangen. Die Restrukturierung nach Bedarf ist sinnvoller als sich vorher Gedanken zu machen, wenn der Aufwand zum Ändern so gering ist. Gegen Ende fand ich Fortschritt und bequeme Zusammenarbeit wichtiger als es "richtig" zu machen, weswegen dann in meinem Git-Repository alle möglichen externen libs gelandet sind. Für eine Veröffentlichung des Quellcodes würde ich das zuerst aufräumen wollen (zumal ich nie eine Lizenz angegeben hatte).

Und jetzt?

Keine Ahnung, vielleicht mache ich mir beim nächsten Mal vorher mehr Gedanken zur Statik. Wenn ich dann weiß, wie ich ein kleines Projekt umsetzen könnte, dann weiß ich auch, was dem großen fehlt. Das kleine Projekt hätte weniger Materialverschleiß und wäre vermutlich der bessere Prototyp. Vielleicht lerne ich auch, was den Preisunterschied zu teuren HiTec Servos ausmacht.


  1. https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9915.html 

  2. https://de.wikipedia.org/wiki/Sechs_Freiheitsgrade 

  3. http://www.lynxmotion.com/c-3-hexapods.aspx 

  4. https://www.freecadweb.org/ 

  5. https://thingiverse.com 

  6. http://openscad.org 

  7. https://www.duet3d.com/ 

  8. https://www.reddit.com/r/ender3/comments/a9q9jk/for_new_ender_3_owners_a_quick_note_on_thermal/ 

projekte

Bevor ich irgendwann vergesse, was ich eigentlich mal irgendwann tun wollte, notier ich das mal hier...und hoffe auf Zeit, wenn die Motivation da ist und umgekehrt. Da wären so verschiedene Projekte, im folgenden:

  • ein kleines Gerät, bevorzugt ARM, welches meinen Router ersetzt und als SIP-Gate dient, um mit Smartphone und PCs an die Haustelefonleitung zu kommen. Pläne dafür gabs schon in Form eines ALIX 2D13, eines Raspberry Pi mit externen USB-Modems und einer Fritzbox, wobei
    • letzteres zwar am kostengünstigsten wäre (weil vorhanden), aber da ein eigenes Linux oder BSD aufzuspielen (bei einer 200Mhz CPU mit 32MB RAM und ~50MB Flash) grenzt schon an Wahnsinn. Das Ding ist auf ADSL und WLAN optimiert und kann kein bisschen mehr vertragen...
    • Raspberry Pi hat eigentlich zu wenig Anschlüsse, aber heute morgen kam auch die Idee, dass man bei sowas auf Konkurrenz zum Pi hoffen kann.
    • ALIX 2D13 kommt mit der gewünschten Ausstattung (abzüglich Telefoniehardware, aber das ist ja bei allen Kandidaten), ist aber auch ziemlich teuer...dafür hat das auch außerordentlich Power unter der Haube. Pläne dazu unter [1]
  • Zweites Projekt, eigentlich älter, ist eine Zusammenstellung von Serverdiensten auf einem debian-System. Mir ging es beim Erstellen des initialen Plans [2] um einen Ersatz für Windows SBS Server. Diese machen ansich gute Arbeit, sind aber meiner Meinung nach schlecht zu administrieren, wenns irgendwo hakt. Vielleicht liegts auch nur an meinem fehlenden MCSE...aber ich bin überzeugt, dass eine Zusammenstellung äquivalenter Dienste unter GNU/debian damit konkurrieren können. Ein wichtiger Punkt bei dem Projekt ist aber, dass ich das System so konzipieren möchte, dass ich keine Ablegerdistribution erstellen will, die nach 1-2 Jahren nicht mehr weitergeführt wird. Das soll auf dem aktuellen stable-System aufbauen und mit Installationsskripten deployt werden. Die müssen natürlich angepasst werden, aber pro Installation sollen nur die Daten fürs Zielsystem angepasst werden. Vom Inhaltlichen verweise ich lieber wieder auf das Dokument [1]. Ich wollte den von unten herauf aufbauen und begann darum mit der Partitionierung, aber die Syntax des parted-Automatismus im debian-installer scheint wohl nicht besonders "stable" im Sinne von debian stable zu sein und tut nicht wirklich das, was die Dokumentation mit ein paar Beispielen zu erklären versucht. Danach ging mir dann auch mal wieder die Zeit flöten...im nächsten Anlauf werde ich das wohl überspringen oder auf FAI oder ähnliches setzen (was ich eigentlich auslassen wollte, um Komplexität einzusparen).

Update: Das mit dem SIP-Gateway wird wohl doch nix. Scheinbar tut ein gewöhnliches Analogmodem nicht den selben Job wie normal eingesetzte Hardware, die jedoch deutlich mehr kostet. Darum lohnt sich das nicht für mich. Ein altes, gebrauchtes Modem hätte ich vermutlich für lau abstauben können...so würde das 50-150€ kosten.

[1] http://blog.aero2k.de/stories/router-planung.html
[2] http://aero2k.de/linux-sbs-features.html

Windows ist doof, Linux funktioniert nicht

Momentan kommen mir im debianforum [1] immer öfter Menschen unter die Nase, die fast, aber nicht ganz auf das Schema linux-ist-nicht-windows [2] passen. Sie wissen, dass Linux anders ist, sie wollen es nicht alle wie Windows bedienen, aber sie haben ihre schlechten Windowsgewohnheiten noch nicht vergessen/abgelegt. Eigentlich schade, denn sie verpassen die Hälfte. Als Hilfesuchende punkten sie auch nicht, denn sie gehen Probleme nach Windows-Art an: Beschreibe das Verhalten, hoffe, dass das jemand kennt und eine Lösung dafür hat. Unter Windows gehts halt nicht anders...hoffentlich ergiebige Fehlermeldung ("Vorgang fehlgeschlagen") mit Vorgeschichte ("Programm XY installiert", "Windows Updates durchgeführt", ..) in Google suchen oder Forum posten und auf Leidensgenossen hoffen, die das Problem gelöst haben.

In den meisten open source Programmen gibt es irgendeine Art von Logging oder (Debug-)Ausgaben. Dazu führt man das Programm auf einem Terminal aus, ruft es anders auf oder schaut in der Logging-Datei der X-Session (ausgehend davon, dass es sich um ein grafisches Programm handelt), in der Regel zu finden in ~/.xsession-errors oder für SLIM in /var/log/slim.log. Dort gibt es dann ganz viele Informationen, die zielführend für eine Lösung sind. Ich behaupte ja nicht, dass da steht "du musst noch libbanana-2.4 installieren", und wenn derjenige mit dem Problem mit den Informationen nichts anfangen kann (weil sie zu technisch sind), dann gibts andere, die es können.

Bis es sich rumgesprochen hat, werd ich wohl öfters darauf hinweisen.

Für die meisten grafischen Programme:
~/.xsession-errors
Für Serverdienste:
/var/log/syslog
Für Kernelfragen und Treiberprobleme:
/var/log/kern.log /var/log/messages

Und die meisten Programme, grafisch als auch nicht grafisch (und letztere besonders) haben eine Ausgabe auf dem Terminal, auf dem sie ausgeführt werden. Es wäre doch durchaus hilfreich, sowohl verursachendes Kommando als auch die Ausgabe dazu (abzüglich empfindlicher Daten, die sind erkennbar als solche zu zensieren) unverfälscht zu sehen.

Und diese Dateien (die in /var/log/ sind übrigens nur als root lesbar, also entweder ein root-Terminal öffnen oder sudo vor den Befehl setzen) werden am besten mit Hilfe von tail -f Datei gelesen (was die Ausgabe weiterlaufen lässt), woraufhin die fehlerverursachende Aktion wiederholt wird oder mit less komplett geöffnet. tail ohne -f zeigt einfach bloß die letzten 10 Zeilen an.

Damit wäre das hoffentlich vom Tisch. Das soll übrigens kein rant sein, sondern ein fester Schubser in die richtige Richtung, in Zukunft selbst Lösungen zu finden. Bei Windows hat man doch auch viel Durchhaltevermögen ;) Und neu installieren muss man bei $linuxdistribution auch nicht sonderlich oft.

Und ein letzter Hinweis: solange man nichts gekauft oder bezahlt hat, gibt es auch keinen "Anspruch". Das schließt auch "schließlich ist das doch ein Hilfeforum, ihr müsst mir helfen" ein. Das ist Freizeit, die wir "opfern", meist, weil es uns Spaß macht zu helfen oder wir dabei selbst noch lernen (gemeinsames Problemlösen). Entsprechend schwach ist die Motivation, eine nur schwach oder garnicht recherchierte Frage zu beantworten oder "Hausaufgaben" zu erledigen, die man wahlweise schnell zusammengesucht oder nachgelesen hat. Da hagelts dann schnell ein genervtes RTFM.

Update: falsche Datei angegeben, danke an up ausm dfde

[1] http://debianforum.de
[2] http://www.felix-schwarz.name/files/opensource/articles/Linux_ist_nicht_Windows/

Neue Blogsoftware

Blogwechsel. Drupal hat auf irgendeine vermutlich winzige Änderung in der PHP-Konfiguration (welche auch immer das war) empfindlich reagiert und bei meinem enormen Durchsatz von Blogposts wäre eine statisch generierte Seite doch garnicht so verkehrt...

Wie auch immer, here it is. Meine alten Beiträge werde ich vielleicht noch importieren. Bislang gefällt mir das hier soweit ganz gut.

Oh, und nein, der Umstieg auf python hat gaaarnichts mit den zig PHP-Rants zu tun :D

proxytool

"Proxy Tool" ist ein Firefox-Addon, welches sich unten rechts im Browser als Eingabefeld und Indikatorbutton platziert. Von da an macht es die Proxy-Einstellungen schnell und einfach zugänglich.

Es beherbergt bereits eine Liste freier Proxies (von http://proxylist.co/) und kann auch eine eigene Liste vorhalten. Unterstützt werden HTTP(S), SOCKS4 und SOCKS5-Proxies, also eigentlich alles, was es so gibt. Ein Klick auf besagten Button färbt ihn von rot zu grün und damit ist der Proxy aktiv. Außerdem lassen sich über das Kontextmenü Referrer, Browser Agent und Cookies bearbeiten/entfernen, womit man eigentlich schon ne ganze Menge Zeug an einer Stelle bekommt.

Link zum Addon: https://addons.mozilla.org/de/firefox/addon/proxy-tool/

requestpolicy

RequestPolicy ist eine Whitelist-Lösung für Firefox. Whitelist bedeutet hier, dass Daten nur von der Domain im Adressfeld geladen werden (und Subdomains). Somit werden Werbeanzeigen blockiert und der Seitenaufbau beschleunigt.

Selbst Webseiten wie das frühere kino.to und ähnliche Seiten bleiben auf diese Art nahezu werbefrei. Adblock wird eigentlich nicht mehr wirklich benötigt, aber man kann es aktiviert lassen, um lokale Werbung anhand des Dateinamens zu blockieren, denn dafür ist RequestPolicy nicht gedacht. Der Nachteil an der Geschichte: auch legitime Inhalte und Weiterleitungen werden desöfteren blockiert, welche man dann freischalten muss.

Regeln zum Freischalten sehen so aus:

  • Quelle → *
  • Quelle → Ziel
  • * → Ziel

Also beispielsweise von amazon.de nach amazon.com, facebook.com nach akamaihd.net (deren Inhalte werden von dieser Domain geliefert) oder die übliche cdn-Domain für statische Inhalte (myspacecdn.com, gstatic.com). Ich habe zB auch generelle Anfragen nach youtube.com aktiviert gehabt, aber dann kurzfristig wieder deaktiviert, weil es mich dann doch genervt hat. Aktive erlaubte Ziele sind bei mir noch zB blogger.com, googleapis.com und recaptcha.net, da diese Anfragen in der Regel erwünscht sind (und es ist äußerst doof, ein Captcha nicht zu sehen ;) ).

Falls erwünscht, werde ich meine (dezent gefilterte) Einstellungen für die Nachwelt exportieren, aber ich empfehle einen frischen Start damit. Es lohnt sich definitiv.

Nachtrag: Ich habe völlig vergessen zu erwähnen, dass sämtliche Regeln auch temporär erstellt werden können. Einen Screenshot davon solls auch geben, siehe [1]. Damit kann man im Zweifelsfall erstmal testen, was man freischalten will.

[1] http://www.jellyneo.net/images/articles/accountsafety_requestpolicy4.png