Building robots
 
Notifications
Clear all

Building robots

42 Posts
7 Users
19 Likes
1,147 Views
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2035
Topic starter  

@byron

Here is a thread by @thrandell using a pico.
https://forum.dronebotworkshop.com/raspberry-pi/pico-robotics-straight-line-motion/

 

@byron wrote:
How are you thinking of tackling the brains programming? If you've started on it how large has your program grown?

Here is an exchange we had earlier,
https://forum.dronebotworkshop.com/user-robot-projects/robot-navigation/

My first serious attempt at a robot you can see as my icon.  When one of the 24v window wiper motors failed I gave up in despair.  It was going to do some heavy duty work including mowing the lawn 🙂  Its brain was a laptop connected to the motor/sensory hardware using a K8055 as back then the Arduino option wasn't available.  I used the k8055 in a small robot but ultimately want to replace it with an Arduino.

https://forum.dronebotworkshop.com/user-robot-projects/k8055-robot/

Although there appears to be some here interested in building a "real" robot, including Bill, past behavior is the best indicator of future behavior so for me it probably will not go far.  It is just a fun project when I am in the mood and have some spare time. If it goes anywhere it will be a visually guided robot.

https://forum.dronebotworkshop.com/user-robot-projects/visual-input-for-robot/

https://forum.dronebotworkshop.com/ai/robot-vision/

As for ChatGpt I have spent some time trying to get an understanding of how it works and its limits. I thought this one was a good start.


   
DaveE reacted
Quote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1111
 

@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 😀 


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 3 years ago
Posts: 6549
 

@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?

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1111
 

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?

 


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 3 years ago
Posts: 6549
 

@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.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1111
 

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.


   
ReplyQuote
THRandell
(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 217
 

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 

To err is human.
To really foul up, use a computer.


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1111
 

@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 👍 


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1553
 

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


   
Inq reacted
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1111
 

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. 


   
DaveE reacted
ReplyQuote
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2035
Topic starter  

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.

 


   
ReplyQuote
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2035
Topic starter  

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 ...

 

 

 

 


   
ReplyQuote
THRandell
(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 217
 

Posted by: @byron

Do keep on posting your progress 👍

So Byron I think that I owe you an update.

I have been able to build out a robot like the one I described above using two RPi Picos.  The MCUs communicate via I2C, with the sensor board refreshing obstacle distance data from 8 IR sensors in about 90ms.  It’s been a few months now and it’s still working!  One positive from adding the second Pico is that it freed up some GPIO pins.   I now have 4 interrupts hanging off of the two motor encoders for 12 clicks per revolution of the motor shaft.

Both boards are powered by the same 3.7V Lithium Ion battery.  I did wire up two schottky diodes so that I can flash program updates via a USB connection without back charging the battery.  Other then that it was all pretty straight forward.

Tom

To err is human.
To really foul up, use a computer.


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
 

@thrandell 

Do you have a video?  

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1111
 

@thrandell

Thanks for the update.  My understanding is that you have found that using two rpi pico boards in a bot and communicating via i2c to work well and have not (yet?) found the need to use both the pico cpu cores and the PIO abilities of the pico.  Thats all very good info and thinking of delving into using multiple cores or using the assembly language necessary to make use of the PIO seems a bit daunting to me.

I've not got any further with my bot and deliberation as to what and how many processors to base it on as summer time project not related to the electronics hobby have been to the fore. 

Re reading the post thread, I give a nod to @robotbuilder in his recommended use of a laptop computer to be the brains of a bot, communicating with on bot microcontrollers. The relatively cheap mini 'desktop' computers that one can buy these day that can run the likes of window 11 and of course a variety of Linux op's  is very compelling.  I see Adafruit produce some boards designed to be linked to desktop computers to provide GPIO pins, and this coupled with, say, a refurbished mini pc, one can get a mighty little beast for under £100.   The rpi 4 has real competition these days.


   
ReplyQuote
Page 1 / 3