Greetings,
just joined up. Lots of good work here. had a chance to review the source and I get the system. I have developed some tech I would like to interface to the UI. I have rewritten 'Wiring' so its completely object oriented and all C++ and presents a unified view of resources. Its all interrupt driven vs 'loop'. I have combined 3D printer command processing to have the main command processor respond to M and G codes. The idea is to task robots using 3D printer CAD or solid modeling and generate the codes through Slic3r etc. The codes are mapped to robotics functions rather than 3D printing and coordinates are scaled to real world if desired. So draw your yard in Blender ,generate the fills and have your robot mow that pattern; as an example. The motion planning of the 3D printer firmware is also utilized and mapped to the robot wheels vs printer steppers.
I have a robot that uses 2 BLDC e-bike hubs as a demonstrator. Currently I am building a special power section because BLDC commutation has some nuances when applied to the low speeds and dynamic braking of robotics. The platform I call RoboCore is happily oscillating 12 PWM pins and managing 6 pin change hall interrupts on the Mega2560 to drive the 2 BLDC's. I am working out the Adafruit 10DOF IMU interrupt handling as well. When complete I calculate the 16 inch wheels of the robot will carry it to a theoretical 53mph. I am also looking for large clear indoor space to test the high speed maneuvering when ready.
Hello and Welcome microcaliper
Welcome !
You have an interesting system. Any pictures available?
You say you'd like to ineterface with the UI, what are you imagining? The Arduino service interfaces an Arduino with MRLComm.ino sketch running on it - which basically turns it into a bi-directional slave for something connected to the serial port, if this helps for ideas.
Heh, I just imagined a mower on your system with the Z axis the mower's height - you could do a inverse model, but you'd need a very tall mower and really tall grass :D
Or at least a on / off extrusion for crop circles :)
Thanks
Concept
Heres a pic such as she sits. You can see the latch board I had to construct to change the ratiometric hall sensors to logic level. Its 6 741 op amps 3x3 for the 3 sensors in each hub. Its a modified non inverting schmitt trigger i invented by accident. My idea is to toss out the messy Wiring arduino platform and put mine under your UI so I can do things like use all the timers without giving up 2 for beeps and redundant delay functions. I toss out the bootloader and use JTAG so I dont do things 'the Arduino way'. What can I say, I like real source level hardware debugging, though I hate that Atmel Studio is a VS reskin. oh well. So it might be a fork situation as far as what I want to do but I would like to propose some standardized XML transport for return data packets regardless. It would also be nice if the command processor on the arduino side used M and G codes as I propose. My platform is 2560 specific so thats probably another negative. On the plus side I'm all about Java so if there were some standard object model would could just bind to XML with JAXB that would be great. This would all be stuff the average user would never see. Ultimately I will have the RasPi riding along with the Arduino via USB port and doing real time control with sensor fusion based on my functor colimit work; The Relatrix. i would like to take advantage of all the good work you have done on utilizing all those devices and presenting them as services.
You dont need a tall lawnmower, just a big quadcopter with an extra, large, blade.
Not sure how much MRL source
Not sure how much MRL source you have looked through - but MRL can serialize & encode in a variety of different ways. It is very standardized - in fact there's primarily a single messaging object. A "Message" (even a standard name ;) - it can be encoded into XML, base64, JSON or standard Java binary serialization.
The standard building block of MRL is a "Service". pretty standard too.
MRL currently uses a sketch called MRLComm.ino on Arduino's - this turns the Arduino's into bi-directional slaves at the control of whatever is attached to their usb serial port. I'll probably turn it into a library pretty soon - so instead of interfering with your G code generation - you might find some use including it as another library.
Clarification
Yes. I looked at all that. Thats how I arrived at my conclusions. To illustrate:
instead of this, with its variations in the giant swittch, there is an M and G code giant switch
and instead of this
as a return from the giant switch, there is a standard xml mesage payload returned up the line. What you referred to was the binding of this data into the 'Message' object, and from there to XML or JSON I believe.
the other issue is the manner in which RoboCore actually does its work. Primarily, theres no real 'loop' and I dont use 'sketches' per se. The paradigm differs in that its all interrupt driven and so the workflow in some cases is to create instances of objects which set up the interrupt vectors and then data is asynchronously returned via XML payload prefixed by M code for demultiplexing. The gist is that the 'server' has to be fully asynchronous and ready for payloads to come in out of band of the command processing loop. Not sure if thats a capability. I think the disconnect here is idea that I have rewritten the 'Wiring' platform to work in fundamentally different ways that may not be compatible with the workflow expected in MRL. This is the main question I am trying to answer. Thanks.
Heh
Disregard everything I said about Messaging, I thought the context we were speaking about is "computers" not "micro-controllers". The Messaging I was describing is part of the Java part of MRL which runs on a computer.
Yeah MRLComm.ino has a standard message format and its the way the Arduino service in Java on a computer communicates with back and forth with the Arduino micro-processor
The message format is described as:
MAGIC_NUMBER|NUM_BYTES|FUNCTION|DATA0|DATA1|....|DATA(N)
Its small, relatively robust, and certainly extensible. Its worked well and probably won't be changing. But this represents only the communication between a computer and an Arduino - which is only a single Service.
There are other services which allow any communication. The Serial service is just a raw serial connection - it can write & read "bytes" can't get more loose than that ;) http://myrobotlab.org/service/Serial
Mebbe your interested in creating a Service - in that case you'd pick any protocol you'd want between the Service and your micro-controller. Nothing else (no other Service) would need to know the details of how the communication goes on. At the Service level - they all communicate with the standard Message object I described before - which allows them all to share data easily and effeciently. So once you get to the Service level all of the potential power of all the other Services are available to you (OpenCV, Speech Recognition, Speech Synthesis, Inverse Kinematics, ... etc) http://myrobotlab.org/matrix.php
Ok, thanks, bye
Great, thanks for all your help. Really great work here. I think our missions are completely different though and I dont think I can be of much help here. I am interested in building robots that do things I dont want to or cant in the real world using concepts forces and power levels I beleive are orthogonal to the projects here. I will probably look at the code some more and probably use some of it so thanks again. Good to see people making things!