Ever wondered how Santa brings around and organizes so many gifts in so little time? But with robots, of course! And here we can see a busy little helper with a Lego body and a M5Stack brain scuttling around trying to help...
The robot parts come from an old NXT Mindstorm kit, of which two motors are used for driving around, and the third one for the gripper actuation. The structure of the base is very common, usually referred as "Castor Bot" (see http://www.nxtprograms.com/castor_bot/). The battery pack is actually custom made, and contains 2x18650 batteries connected to the NXT brick by a common barrel jack.
The program logic is shared, as a first step, between the NXT, the M5Stack core and an ATTiny85, as to demonstrate the "proof of concept" of the overall operation. But the final version (or at least the upgraded one) of this project will actually feature the BaseX base from M5Stack to completely replace the need for the NXT brick, which shows more and more its obsolescence and the need for something more powerful, contained and flexible; I would have started the project with that part already, but I still have to get my shipment of parts.
Well, for Santa of course... but mostly for fun, and also because it's been years since I last played properly with the NXT, and I always wanted to use it for robotics instead of letting it rot in a box. Discovering the BaseX was the starting step for this project, even though I had to arrange things a little bit differently than what I had in mind, although fortunately just for the first stage of this project.
How?The system for now is quite simple, and will get more advanced with the next steps.
The M5Stack Core creates an AP for the user, and provides a simple web interface to "wake up" the robot, or put it to sleep.
The Core then must communicate to the robot the new state, and it does it via I2C (doing so by Bluetooth was extremely unreliable, after some experimentation). Here comes an actually very peculiar part of the project: in all programming frameworks (that I know of) used for the NXT, the brick can never be configured a "slave" of an I2C bus. But, I didn't want to make the Core a slave, for 3 reasons:
- logical fallacy (just a pet peeve though, not actually very important)
- when I'll use the BaseX for the job, I will have to configure the Core as a master anyway
- in Arduino environment, it's quite a mess to configure the ESP32 as a slave, so I figured out that another solution was in order.
So in the end I took an additional AtTiny85, configured it as a slave of the I2C bus, and used both the NXT and the Core as masters. The role of the Attiny is actually quite simple, it just has to receive and parse commands, and store additional data contained in the transaction, or write it to the bus to whoever made the request: it effectively just becomes a "messagebox" for the 2 brains on the bus.
Finally, the NXT only has to check periodically what's new on the messagebox, and activate and perform certain trajectories or return to home. This has been made with either simple odometry + angle values from the Core, but without additional sensors, or with predefined "timed" trajectory. The experimentation with the second approach worked, but I will not keep it in the following version, because it's a very simple robot that way.
What I will do with the BaseX is use the first approach, adding an ultrasonic sensor to detect the distance of the object to grasp, preventing any crash into it.
At the same time, the attiny messagebox will also go, and the web interface will see more options added to it, for example go to Point 1 for pickup, and Point 2 to drop, then repeat for P1 and P3, and so on... the possibilities are vast.
Therefore, in the upcoming days I will update this page with polished code for the first stage, and as soon as I get the BaseX, add new material for the upgrade!
Stay tuned!
Comments