![]() My thought is to do as much of the processing as possible in on the Linux side, and use the sketch to only do the actual hardware I/O operations. ![]() There are quite still some details to work out, but that's the way I would approach it. This method lightens the load on the bridge a bit, only polling one value most of the time rather than five. If the "new" key is "T", it puts a value of "F" to the "new" key, and then processes the five servo positions. The sketch only reads the "new" key, and if it isn't "T" it does nothing else. When the Linux updates any of the motor positions, it sets the "new" key to "T". One is to keep track of the last known position of the servos in the sketch, and only write to the Servo output if the value has actually changed.Īnother optimization is to have a single "new" key. There are lots of optimizations that can be done. If you do have an encoder or other feedback method, then you could read the value and put the value to another set of Bridge variables. We just assume it's where we told it to go. The sketch doesn't write the current servo position back out, since the servo is open loop and we don't really know it's position. ![]() Servo.write(position) // Output the servo position ![]() Int position = value.toInt() // Convert to integer String value = Bridge.get(key) // Read the position Void processServo(string key, Servo servo) Or do other processing at this time if you have more to do. Some skeleton code for the sketch: (lots of details left out) void setup()ĭelay(50) // Give a little delay so the Bridge isn't swamped with communications. Note that the bridge only works with strings, you will need to do the conversions back and forth from string to integer. In Python, to use the bridge, you must have this at the beginning of your script: (0, '/usr/lib/python2.7/bridge/')įrom bridgeclient import BridgeClient as bridgeclientĪfter that, you can put a value to the shared store using: bc.put('m1', '123')Īnd you can read a value using: value = bc.get('m1') will return the value of all keys stored in the Bridge.will store the value 123 under the key "m1".One advantage of the Bridge is that it is easy to debug using a standard web browser: The Linux side code can read that value and format up the data for the web page. The last known position of the servo is always accessible from the Bridge shared data store. In the loop() function, it steps through each servo: for each one, it calls Bridge.get() to read the servo position from the bridge, and write it to the servo output. The Linux side reads and parses the JSON, extracts out the 5 servo positions, and "puts" those values to the shared Bridge storage, using a unique key for each motor ("m1", "m2", etc?) There are some pros and cons to the Bridge library, but I think this application is a reasonable use of the Bridge.put() and Bridge.get() mechanism. This will require some communications between the sketch and Linux sides of the Yun. Then there's the matter of sending/reading the servo positions. I can't help you with the JSON part of it, other than to say that it's best handled on the Linux side of things, and I'm sure someone versed in that aspect will be along to give you some hints.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |