Building robots

@robotbuilder

A good summary of what we were all at a couple of years ago 😎 .  I did get a quite rudimentary GPS guided bot that can run around my empty field in a guided, but a bit meandering fashion, and I had to bring a wifi router out to the gate post of said field on an extension lead and long ethernet cable to enable the comms to work when testing.   I now have a wifi in a close by outbuilding so the reception in the field is now OK.   The bot is lacking in on board sensors that would enable it to roam autonomously without fear of causing damage to passing legs, and OpenCV has not been used for robot control.  So an interesting start perhaps, but much more to do.  And indeed tracking encoder pulses was ruled out due to earlier trials as mentioned in linked posts. 

So now its time to consider what to build next.  My bot is a 4 wheeled version of the last dronebot six wheeler  bot, which never did get off the ground, or if it did Bills not telling.   I would like to bot to be a bit bigger so I will probably have to construct one myself.  However I want to try out a bot with Ackerman steering instead of skid steering, so another play bot may be obtained first.  Right now consideration as to what boards to use where, and how to program it all in to a coherent whole is where I'm at, hence some of my interest in what you are currently up to 🙂 

Also much to consider as to how the programming / master / slave boards should be done, and I'm in the early re-appraisal stage of this analysis.  As you say all the bot builds thus far have rather faded and have not got very far.  Nevertheless I hope @dronebot-workshop realises we learn as much from our mistakes as our successes.   We learnt from db1 thats is probably not such a good idea to have many boards doing more discrete tasks and communicating via i2c due to the short distances i2c can use, and even with i2c extenders the electronic 'noise' was just too great (and shortly after that db1 was abandoned).  So that seems to indicate a larger and more capable board to control most of the on bot functions rather than a collection of boards may be the way to go. And now with added AI (good ChatGpt video link BTW) maybe success looms 😀 

@byron Just a quick comment: I favour using several boards, but I share your concern regarding communication. Has anyone looked into wired interconnects, USB, Ethernet, or some other protocol?

Posted by: @zander

↑

I favour using several boards

I thought it was a good idea when the DB1 design was first shown.  But when the comms proved a bit tricky (at least the i2c comms was problematic) then I thought that whatever comms is used its still going to be a heck of a lot slower than what different functions, modules, classes or whatever you want to call call them within a program could achieve.  

Do you have any particular rational for preferring several boards over a single but more powerful microprocessor board, such as the Teensy 4.1, or perhaps the new arduino giga board if it could provide enough IO to sensor links etc so as one program could do it all?

@byron Specialization, suited to the task and whatever the original reasons were. During the many years I have been either designing or critiquing systems, the most successful were those with a collection of smaller pieces. The least successful was the monolithic systems that dominated before the modern era. Ironically I made a lot of money troubleshooting those monolithic beasts.

When a real-world system, i.e. the mechanical robot, is a collection of discrete parts, the most obvious and best match is a software system that mimics that. It's basically a network of sensors and actuators.

When troubleshooting, one of the first techniques to be applied is to divide the large piece of software into several smaller units and follow the piece with the problem, i.e. 'divide and conquer.' This works because the human brain can better deal with a smaller chunk of code. The same rationale applies to code creation.

I have experimented with the Arduino IDE and broken a larger sketch into discrete pieces that are saved as .h files and then #included in the main sketch. This way, all the 'modules' are automatically placed in tabs in the IDE so all the code is readily available, but the amount of code I have to look at at once is reduced. This experiment aimed to see what a half-step solution looked like. Eliminating all globals where possible and communicating between modules using pass by value where possible reduced the coupling between modules which is intellectually equal to running those modules on individual boards. I believe @Inq even went the next step with creating external modules that the link step pulls together when creating the executable. Exactly how main frame development worked. I have not done that yet, but I will eventually.

Now the decision can be between a network of physical boards and software or very loosely coupled modules. The topology is almost identical and will map very closely to the physical world, ie the robot.

I hope this gives you an insight into my thought process and decision-making. It is by no means final, good design is an iterative process and the search for perfection is an ongoing process as new thinking and new tools become available.

Posted by: @zander

↑

I hope this gives you an insight into my thought process and decision-making

I most certainly concur with a modular approach where the modules/functions are loosely coupled.  But whether one of the modules resides on your arduino and is # included into the main schetch, or running on a separate board and communication to the arduino sketch, should not have much of an impact on the program logic I would think, and may be more of a consideration as to just what the particular main arduino board is capable of handling.  

As I try to stick with python / micropython where I can I use a similar approach to having many modules that are imported into the main program and also I use asynchronous programming techniques to give a fair round robin look in for all the functions and modules.  (using multi-cores, multi-tasking, multi-processing, interrupts etc of course all have a bearing on the ultimate program design to cater for the situation  where a lot of things are happening simultaneously)

Thank for your good thoughts on this, it does help to see how others are considering approaching this quite complex robot design process.   I expect the choice of one very capable board, or many lesser capable boards in comms links will end up with a suck it and see approach.

Posted by: @byron

↑

Also much to consider as to how the programming / master / slave boards should be done...

@zander @byron

I too am thinking about this topic.  I’ve experimented with a lot of the pieces and now need to pull them together.  I’m using two Picos: one as a main board for control of the actuators, buzzer and LEDs and a second board to gather and store sensor derived information.  The sensor MCU would be responsible for cycling through all the sensors to record distance to obstacles, distance to other robots, bearing to other robots, intensity of ambient light.  I’m going to try to do as much computation on the sensor MCU as I can and lay out the results in a contiguous block of memory.  The main board would then run a cooperative scheduler that will make read requests for specific sensor data via I2C.

I plan to start with just gathering distance to obstacle information first and see how it all plays together.  The sensor MCU will be interrupt driven to respond to a data read request so I’m still pondering the effect of ‘dirty reads’ on the main controller.  I’m hoping to avoid coding for the synchronization of updates and reads.

As things progress I’m also wondering how I can pass messages to other robots and acknowledge receipt of messages.  I also have a small list of low level behaviors that I want the robot to perform and I need figure out what sensor information they may require…

Tom 

@thrandell

Very interesting Tom and I will be following your progress.  I take it you are referring to the rpi Pico and not the UM TinyPico boards (and probably your using rpi PicoW's as I see you want comms between different bots)  Are you using both cores on each of the Pico's residing in a single bot?  And perhaps your making use of the pico's pio for any counting of encoder signals you may be recording?   On one of my rpi Pico's that is attached to a large'ish SPI screen needing a large frame buffer I overclocked it to freq(250_000_000) which made quite a difference to the screen refresh rate and its been running OK for months, so I think you can push the picos a bit if required. 

Have you considered passing MQTT messages over wifi between your bots.  You would need to set up a MQTT broker on one of your computers or maybe a rpi (not a pico).  When set up its lean and mean and the messages are, so I've read (not tested by me), faster than using http comms. 

Do keep on posting your progress 👍 

Hi all,

   Just a comment on general observation of dustributing computing versus central, and more specifically the communications.

Obviously there a a considerable number of 'physical' communications standards and protocols ... one of the things to be aware of is the effect of 'grounding'.

Some buses, e.g SPI and I2C, send their data using a 'data line' and a 'ground' line, so that the receiver input is comparing the incoming voltage on the data line with that of the 'ground' line. This is fine in 'small' systems where the 'ground' is a reasonably consistent and equal potential at both the receiver and the transmitter.

(By the way, SPI and I2C also transmit a 'clock' using a 'clock line' and the same 'ground line' ... from an electrics viewpoint, this is like a second data line, although of course it only carries the timing edges to determine when to to look at the data line, so it doesn't carry any real data ... but electrically it needs to be treated with the same level of care and respect as the data line.)

The problem arises when the same ground wiring etc. is also carrying higher currents, e.g. to drive motors. These higher currents generate voltage drops, and an oscilloscope with a differential input probe will show, at least for transient times, that the potential at one point of the 'ground' is different from another point. If these potential differences approach or exceed the signal levels of the data voltage (compared to ground), then the data is liable to be corrupted.

Historically, such as with RS232, this problem was mitigated by making the data signals relatively high voltage, e.g. typically -9V for '1' and +9V for '0', so ground voltage differences of a volt or two were easily distinguished from the data signals. But this approach is hard to maintain at higher data rates.

Alternatively, systems like RS485 use a pair of data wires, so that instead of comparing the voltage with 'ground', the end receiver input compares the voltages on the two wires, and chooses '1' if wire 'A' is positive with respect to 'wire 'B' and '0' if 'B' is positive with respect to 'A'. The practical receivers and transmitters are still referenced to 'ground', but are designed to cope with the ground varying by up to a few volts with respect to the voltages on the data wires. This makes them much more resilent to ground potential problems, but not completely immune.

Wired Ethernet, such as the common twisted pair 100Mbits/sec standard, extends the RS485 dual wire model, by also 'normally' using transformer coupling at receiver and transmitter, so that even if the 'ground' potential at the ends varied by (say) 50V, the receiver and transmitter would not be aware of it.

Perhaps the 'ultimate', or at least close to 'ultimate' allowing for effects under extreme stress, is fibre optics, in which the data is transmitted along a plastic or glass fibre, which is not electrically conductive.

WiFI, Bluetooth and other radio protocols share the freedom from grounding problems, but of course they are susceptible to interference from other radio signals and can be blocked by screening materials such as metal objects. They are also more susceptible to snooping and jamming.

-------------------------

Obviously, this discussion has proceeded from the most to least susceptible, but it should also be obvious that they also roughly proceed from lowest power, simplest and cheapest, to highest power, most complex and expensive, so there is the 'horses for courses' style trade-off to make.

However, the availability of technologies such as silicon chips costing only a few cents each to manufacture, that can perform at microwave frequencies and beyond obviously distorts the economic curve in ways that would have been unthinkable just a few years ago, so these comparisons can change with time.

--------

There are many aspects to consider when choosing a data communications protocol ... dependence on a ground potential difference-free environment should be one of the main points on the check list.

I realise this will all be 'old hand' to some readers, but I hope it is useful to at least some.

Best wishes, Dave

Posted by: @davee

↑

I hope it is useful to at least some.

A most useful enlightenment on the pitfalls to be found when considering inter board communications on a robot.  Much needed for noobs on this stuff like me, and a good refresher for the more experienced too I think. 

Posted by: @byron

↑

@robotbuilder

Right now consideration as to what boards to use where, and how to program it all in to a coherent whole is where I'm at, hence some of my interest in what you are currently up to 🙂 

I am just using a Mega connected to a PC for my robotics project.

Posted by: @zander

↑

@byron Just a quick comment: I favour using several boards,

My argument for using a single PC in my robotics project instead of lots of hardware modules it that all the modules can be in the form of software modules. The PC itself is a hardware module made out of many hardware modules which are wired up by software.  The PC comes with lots of software tools.

It becomes useful to use a hardware module for speed.  Thus the reason for math, graphic and sound coprocessors.  That is how the old slow computers like the C64 and Amiga were able to run fast games. I used to love using the hardware directly in Assembler to get the fastest code possible. The Amiga did have a multitasking operating system but fortunately you could turn it off and armed with its hardware manual ...