Communications Between MCUs Progress

Ok so I had a breakthrough on communications networking within my robot. Originally I planned to have the main brains PC in the chest of the robot connect by USB to a "chest arduino" which would connect by single wire communication to a right arm arduino, left arm arduino, right leg arduino, left leg arduino, head arduino. So the chest arduino is forking out to all of those with each of those on a separate digital IO line connection with the chest arduino. This means the chest arduino was acting as a relay station to forward all the commands out to each of the main branches. Then those main branch hubs may then fork out to their various additional arduinos or ESCs as necessary. However, I recently had a lot of concerns about electromagnetic noise or static interference with this single wire communication which is something that setups like CAN bus addresses. However, I did not want to introduce additional chips and hardware. A very easy solution then occurred to me: CUT OUT THE MIDDLE MAN! Instead of a single USB to the chest arduino, I could have 6 or so USB lines coming right off the main brains mini itx motherboard pc and those can go directly to the left arm arduino, right arm arduino, left leg arduino, right leg arduino, chest arduino, head arduino, etc. This would be made possible by a USB expander port enabling that forking out capability since I don't think that mini itx motherboards come with that many usb ports natively as they are a very small motherboard with bear bones connectors and stuff to cut down on size. By going with USB I get a VERY high bandwidth VERY fast and VERY reliable from a electromagnetic interference standpoint data transmission system that is off the shelf. The USB cords themselves already have ferrite rings on them and have shielded wire as well. So they have a ton of protection. And the USB protocol itself is already very fast and high bandwidth so all the commands I would need both upstream and downstream will be very instant and cause me no headaches at all this way. And that cuts out the longest distance transmissions noise issues and speed issues. Remember that when the main brains PC wants a motor to brake or accelerate forward or w/e we want VERY VERY low latency on those commands both downstream and any upstream responses that let the main brains pc know what is going on. So a sort of hacky DIY single wire communications method with a DIY communications protocol made by me is NOT ideal AT ALL for that with all the noise it will face. HOWEVER, the single wire DIY communications protocol IS fine when going from right arm arduino to right arm ESC #7 or w/e which is just a very short distance of say 5-6" max. As long as we keep the signal line as a twisted wire pair with the ground return line and we keep it away from all the power lines when doing the wire routing and stuff like that we should be ok at such a short distance from a electromagnetic interference standpoint. So that resolution brings me some needed clarity.

That said, for the single wire communications protocol that will be used to communicate from the right arm arduino to the right arm ESC #5 we have had some great success. With chatgpt's help I think I have managed to initiate the microcontroller in code, wake it up and get it configured so to speak, and get its internal clock setup and running and defined in software so its accessible for timing, and also setup an interrupt function that reads the signal wire and anytime it goes from a 1 to a 0 or a 0 to a 1 it calls that interrupt function and that function takes note of what has occurred. Namely, when it goes from 1 to 0 it marks the timestamp of that transition to 0 and when it goes back up to 1 it marks that timestamp as well. It then calculates the duration between those two timestamps to see how long 0 pulse was held down. If it was a normal shorter duration 0 count, it marks a 0 in its buffer memory array. If it was a double duration 0 pulse that was held down, then it marks a 1 in its buffer memory array. In this way its able to decipher a message that comes sort of like Morse code in the form of 1s and 0s where the 0s have different durations that signify a 1 or 0 respectively. And then the main while loop main part of the program has a regular job of reading from this buffer memory array that the interrupt function is regularly populating and it gets this sequence of 1s and 0s and grabs 8 of them at a time and uses that sequence of eight 1's and 0s to consider that to be a byte/char. A char can be an A-z, a-z, 0-9, and several keyboard symbols. They all have a default char/byte representation in 0's and 1's that represent them. So in this way it can convert the 0's and 1's into plain text English. From there it then will determine whether it is reading just noise or a valid message format. My list of valid messages and their format so far is [Forward Nudge 5 5 5], [FORWARD 5 5 5], [Reverse 5 5 5], [Brake 5 5]. In each of these, note that they are enclosed in a opening and closing bracket. This is how my code determines if it is dealing with a potentially valid message or just random noise. If it sees that opening bracket it reads the 0s and 1's till it finds the closing bracket and then feeds the contents into a new memory buffer array and evaluates it further from there. If it finds a known command like like Forward Nudge # # # or FORWARD # # # etc then it considers it valid as long as that # is from 0 to 9. The 5 5 5 here is just a example figure of the parameters that come with the command. it can be any number 0-9 for each of these 3 parameters. I just chose 5 for all three for the sake of an example. So FORWARD 5 5 5 will mean turn the motor in forward direction (clockwise) at acceleration level 5 (or 50% acceleration), until you hit a coasting speed of 50% speed then remain coasting indefinitely. Also while doing all of this use 50% power (which correlates to 50% duty cycle). So this way it controls how forcefully it will advance the motor, how much acceleration and how much overall coasting speed once it hits its full intended speed. Forward nudge will have the understanding that it is to nudge forward by 5 commutation steps (6 commutation steps is a 360 turn of the motor), and it is to do that at 50% speed and 50% power/duty cycle. So the forward/backward nudge command is for very fine movements of high precision and it is to stop and hold by default after a nudge. Whereas with forward command it attempts to rotate forward indefinitely until it receives the brake command. The brake command just tells it brake at 50% deceleration and 50% power/duty cycle. So this determines how fast it brakes and how powerfully it attempts that breaking. Once it has finished breaking it holds in place. So these commands enable the main brains PC to have tremendous control over the motors behavior and the fluidity and force of the motions of each joint. I still need to now test the code I have so far that implements all of this and debug it and then we can do live testing as well soon. I have NOT yet implemented in the firmware the actual movement code only the communications code for receiving these custom messages and the code that searches for these messages and validates them and breaks them down into commands to later execute on. Also I can always add more of these commands as needed which is quite nice. I know for example that I will need to setup commands for the ESC to report back if it runs into some kind of issues perhaps. We'll see on that though. Most issues will probably be picked up by a arduino that is going to be monitoring a shunt resistor and reading by that means the current being pulled by the motor and thereby know if the joint has collided with something due to current spikes that would happen in that case. Which is a type of collision detection system. It would also get clues from strain gauges which measure pressure put onto finger tips. It can also get clues from the potentiometers that will be connected to each finger joint that will tell the arduino the joint angle of that finger joint in real time as it changes. So with all of those feedback means, the ESC may not have to report back much of anything. I consider it just a blind and dumb electromagnetic field rotator. However one way it might answer back is that after getting a message and if that message contains a command to respond back, then it would respond back that it received the command perhaps. This would be a sort of heartbeat check the Arduino responsible for that ESC could use to make sure it got a message. However this may be overkill and not needed I think. We'll see.