Loading ...
Sorry, an error occurred while loading the content.

New project under way

Expand Messages
  • winglabs_inc
    So I just got my first Arduino board out of the box! The Arduino micro board. Along with that I was able to afford one ultrasonic distance sensor, and a micro
    Message 1 of 8 , Dec 29, 2013
    View Source
    • 0 Attachment
      So I just got my first Arduino board out of the box! The Arduino micro board. Along with that I was able to afford one ultrasonic distance sensor, and a micro servo(which appears to be analog). I also got a new 40w soldering iron recently, so I can finally start experimenting once again! My itinerary for these items is to construct a uniwalker style creature. All I still need is a small PCB, a wheel pot(I already have two lying around somewhere), two photodiodes(ditto, already conjoined), a battery holder, and something to fashion a wheel out of. I also have a 6V solar panel lying around, so that may come in handy for both keeping the robot charged and adding structural robustness. Which means I also need a few more parts for power management, but I can get those easily.
       I may add a BEAM core to interface between the uC and the servo. If power becomes too low, the bot cuts power to the Arduino, seeks out the nearest power source, and slows to charge. This core also monitors leg angle so that it can free itself from obstacles[that the range sensor would otherwise detect]. Also, the core may overpower the Arduino's commands if it senses danger. This way, I make it nearly impossible to program the bot in such a way that causes it harm, eliminating the "robot banging itself to death on a table" stage of AI development that many roboticists must be familiar with, and more notably, preserving my precious creation in the field. So don't tell me that BEAM has no place in serious robotics!

      Enjoy, Connor
    • winglabs_inc
      Actually, I think I ll instead use the servo to rotate the ultrasonic sensor, since I actually have two GM7 gearmotors lying around already. So the final
      Message 2 of 8 , Dec 31, 2013
      View Source
      • 0 Attachment
        Actually, I think I'll instead use the servo to rotate the ultrasonic sensor, since I actually have two GM7 gearmotors lying around already. So the final concept, I suppose, is a two-motor uniwalker style droid, with a third servomotor in the head. The body structure will probably consist of a metal frame built around the PCB, with the solar panel mounted on top of that. The sensory array should consist of: 1)an ultrasonic distance sensor(head-mounted), 2)two photodiode "eyes"(head-mounted), two wheel pots for angle measurement (motor-mounted), and two IR sensors(body-mounted) for surface detection.

        I still may implement an enslaved BEAM core behind each leg motor, as a reflexive fail-safe against any suicidal tendencies in the machine's programming, either accidental or intentional(I don't want to lose a $100 project). I guess the way the bot could sense danger would be to monitor the IR sensors. They will override the controller's commands in 2 cases: 1)a sensor detects nothing, meaning there is a drop in that direction, or 2)a sensor detects a higher IR level than the emitter outputs, meaning that there either a dangerous heat source to avoid, or too much ambient light to safely navigate in that direction. Also, if battery level becomes too low, the charging circuit switches control from the Arduino to a photo-bicore wired to the photodiodes in the head, which directs the bot toward the nearest light source, but can still be overridden just the same. The controller is only brought back online when the charge is full. The slave bicores also use the wheel pots on their motor as the ground resistor for each Nv; when the leg goes out of synch or gets stuck, the bicore responds and also communicates with the opposite core.

         Some of you might argue that none of this is necessary when I can just program the Arduino to perform all of these functions. But the purpose of implementing them in hardware is to prevent faulty coding from causing physical damage to the robot, in other words, to protect it from my coding noobishness. Also, the controller doesn't have to be made aware of physical problems; the body solves these issues on its own to ensure that the controller can carry out its goal. Not to say that the controller doesn't take input from these sources, it just doesn't need to be responsible for every iterative motion.

        A fun side note: the bot could potentially get "trapped" inside a shape drawn on the ground, like a line follower. Which is why I may add a white LED aside the IR emitter, controlled by the Arduino, so that bot can tell the difference between a dark surface and a hole, but only if the program activates the LED upon such an instance. Otherwise, the bot can be guided along by drawing a path to follow. So depending on the robot's goal, either is a valid option.

        Enjoy, Connor(I mean, to myself, since I'm obviously alone again...)
      • Martin McKee
        Not entirely alone! Though I m still far too rushed off my feet to do any sort of BEAM work besides the odd daydream while behind the wheel somewhere else.
        Message 3 of 8 , Dec 31, 2013
        View Source
        • 0 Attachment
          Not entirely alone!  Though I'm still far too rushed off my feet to do any sort of BEAM work besides the odd daydream while behind the wheel somewhere else.  The project sounds good to me, it really sounds very much like a horse-and-rider style of control system.  What I "might" do ( and I do mean might, I'd say it's equally probable that I wouldn't ) is to implement the same sort of system with a processor in place of the low-level BEAM "protective" system.  Of course, I've also considered the BEAM + processor approach as well and like it for several reasons.  Given that I have so much experience with programming, I would feel quite comfortable being able to write the firmware for the low-level control and feel that it would be able to be trusted in all cases ( even if that weren't the case with more complex control algorithms ).  Either way I suppose.  But I do like the structure of multi-layer control systems.  Simple systems connected to the hardware directly to handle reflexive actions and more complex systems stacked on top to influence the lower systems.  The modularity makes it much easier to ensure that basic behaviors are working before more difficult ones are tackled and, as you say, it allows one to protect the robot from programming flubs.

          Sounds interesting,
          Martin Jay McKee


          On Tue, Dec 31, 2013 at 7:27 PM, <connor_ramsey@...> wrote:
           

          Actually, I think I'll instead use the servo to rotate the ultrasonic sensor, since I actually have two GM7 gearmotors lying around already. So the final concept, I suppose, is a two-motor uniwalker style droid, with a third servomotor in the head. The body structure will probably consist of a metal frame built around the PCB, with the solar panel mounted on top of that. The sensory array should consist of: 1)an ultrasonic distance sensor(head-mounted), 2)two photodiode "eyes"(head-mounted), two wheel pots for angle measurement (motor-mounted), and two IR sensors(body-mounted) for surface detection.

          I still may implement an enslaved BEAM core behind each leg motor, as a reflexive fail-safe against any suicidal tendencies in the machine's programming, either accidental or intentional(I don't want to lose a $100 project). I guess the way the bot could sense danger would be to monitor the IR sensors. They will override the controller's commands in 2 cases: 1)a sensor detects nothing, meaning there is a drop in that direction, or 2)a sensor detects a higher IR level than the emitter outputs, meaning that there either a dangerous heat source to avoid, or too much ambient light to safely navigate in that direction. Also, if battery level becomes too low, the charging circuit switches control from the Arduino to a photo-bicore wired to the photodiodes in the head, which directs the bot toward the nearest light source, but can still be overridden just the same. The controller is only brought back online when the charge is full. The slave bicores also use the wheel pots on their motor as the ground resistor for each Nv; when the leg goes out of synch or gets stuck, the bicore responds and also communicates with the opposite core.

           Some of you might argue that none of this is necessary when I can just program the Arduino to perform all of these functions. But the purpose of implementing them in hardware is to prevent faulty coding from causing physical damage to the robot, in other words, to protect it from my coding noobishness. Also, the controller doesn't have to be made aware of physical problems; the body solves these issues on its own to ensure that the controller can carry out its goal. Not to say that the controller doesn't take input from these sources, it just doesn't need to be responsible for every iterative motion.

          A fun side note: the bot could potentially get "trapped" inside a shape drawn on the ground, like a line follower. Which is why I may add a white LED aside the IR emitter, controlled by the Arduino, so that bot can tell the difference between a dark surface and a hole, but only if the program activates the LED upon such an instance. Otherwise, the bot can be guided along by drawing a path to follow. So depending on the robot's goal, either is a valid option.

          Enjoy, Connor(I mean, to myself, since I'm obviously alone again...)


        • winglabs_inc
          Thanks, it is precisely a horse-and-rider configuration. I like the multilevel structure because it can actually make complex behaviors simpler to encode. In
          Message 4 of 8 , Jan 1
          View Source
          • 0 Attachment
            Thanks, it is precisely a horse-and-rider configuration. I like the multilevel structure because it can actually make complex behaviors simpler to encode. In this case, the controller board still has semi-direct influence over the robot's actuation, but the "horse" component can autonomously compensate for physical difficulties, using simple circuitry built right around the motors, and without the AI having to even know. This has the potential to significantly chop down the dimensions of the algorithm, because it doesn't have to include any facilities for environmental compatibility. As far as the AI knows, it exists on a two-dimensional plane filled with one-dimensional objects and lighting, as gathered through it's limited senses. Thus, the algorithm becomes much more straightforward to a less experienced coder like myself, and development can move along faster, because adaptation is implied to occur. Aside from that, I prefer minimalism in my designs, as well as elegance. So it's entirely a matter of choice as whether to use BEAM or a small uC for the "horse" control level, but either way, I think a horse and rider configuration is the most elegant option for environmentally tolerant bots.

            Enjoy, Connor
          • winglabs_inc
            Hey quick question, can I make a Schmidt suspended monocore in the same fashion I would a bicore? This is pretty critical information for me at the moment, and
            Message 5 of 8 , Jan 14
            View Source
            • 0 Attachment
              Hey quick question, can I make a Schmidt suspended monocore in the same fashion I would a bicore? This is pretty critical information for me at the moment, and I need to know if I have to go buy more capacitors.

              Thanks, Connor.
            • winglabs_inc
              Hello?
              Message 6 of 8 , Jan 19
              View Source
              • 0 Attachment

                Hello?

              • Martin McKee
                Wish I could help. Analog was never my strongest suit and, beyond that, I ve not done anything with monocores beyond studying them once every couple of years.
                Message 7 of 8 , Jan 19
                View Source
                • 0 Attachment
                  Wish I could help.  Analog was never my strongest suit and, beyond that, I've not done anything with monocores beyond studying them once every couple of years. Thinking about it, however, I'm not really sure what the question is.  The primary difference between a grounded bicore and a suspended bicore is in lifting the resistors to a connection at a virtual ground ( removing the ground ).  The monocore already is without grounded resistors.  As to the use of schmitt trigger inverters, the waveforms do seem to allow for that though, of course, it will lose some sensitivity to noise and may fail to start reliably as a result.

                  Martin Jay McKee


                  On Sun, Jan 19, 2014 at 9:53 AM, <connor_ramsey@...> wrote:
                   

                  Hello?


                • winglabs_inc
                  A monocore can be grounded, as in the case of the master/slave configuration shown in the diagram. Looking at it, I suppose my question is relatively
                  Message 8 of 8 , Jan 19
                  View Source
                  • 0 Attachment
                    A monocore can be grounded, as in the case of the master/slave configuration shown in the diagram. Looking at it, I suppose my question is relatively unfounded, as the problem with using Schmidt triggers in a suspended bicore is that the process will eventually settle near 1/2 Vcc and kill oscillation. Using unequal caps solves this problem. I was worried that with no larger cap, the monocore will inevitably die, but rather I suppose that it is simply the most exaggerated case of a bicore with unequal caps. So perhaps your right.

                    Thanks, Connor.
                  Your message has been successfully submitted and would be delivered to recipients shortly.