Good morning Peter! Thanks for the offer of help. Depending on how this next couple of weeks go, will help me decide how much help I need. With all the development, debugging, and changes happening right now, it is very hard to see what is around the corner. At present, I am still fighting what are problems with localisation that are seemingly impossible to fix - it is like playing the "whack-a-mole" game. Thanks very much for offering a helping hand and I will keep you posted. Cheers Chris
I have an MQTT broker running on an RPi 2. I just checked it with htop and it's been running for 535 days without a reboot. I tend to forget it's there.
Good morning William, I am the same as you, I had one running and completely forgot about it for over a year. It was just sitting there running on my desk that I used to film at. It certainly is nice when something just runs without needing attention! Cheers! Chris
Hey Chris ... so you are going to programm each and every route by hand??? But that's what Dijkstra's Algorithm (also known as A-Star or A* Algorithm) is for. You just need to setup the roads and "costs" once and thats it. It can calculate ANY route in zoomtown - no need to program all of them by hand. Another benefit: if you "close down" a road for maintenance reason, all handmade routes will fail but the algorithm still works and finds the 2nd best route (avoiding the closed down road of the best route). I am pretty sure there are ready-to-use versions of Dijkstra's for python.
the setup will need 1. all the "knots" (=points where you have several possible ways to go). a knot would be each parking lot and each crossing 2. for each knot it needs the "neighbours" = other knots that could be reached from the current knot. note: knot a could lead to knot b but knot b NOT to knot a -> one-way-road 3. for each neighbour it needs the "cost" of travelling. this is usually the distance between the two knots multiplied with a factor (which could be < 1 for the roads AROUND the city and > 1 for those THROUGH the city ... or all have factor 1 the use the shortest way regardless where it goes along) So the workload for setup is not too big (especially since zoomtown is very symmetric). For sure less work and more flexible than hard-coding all routes :) If I counted correctly, zoomtown has 52 knots and each knots leads to 1-3 other knots, most of them with same cost as many others due to the symmetry.
Good morning Tomek! I actually had written the software originally to use Dijkstra's algorithm and only decided to not use it recently. These algorithms all work on the principle of "Shortest Path" which is great for shipping, and even for navigation for non-commercial vehicles. However, even navigation systems have options to choose from Shortest Path or No Highways, or Use Highways. The reason I decided against using it was specifically "Shortest Path" as that would direct ALL traffic through the "city center" creating a LOT more traffic in that area. ZoomTown was designed with the outer bypass "highway" to alleviate congestion in the center areas. To make the traffic flow more "natural" I decided against those routines in hopes that a human "most likely me" will be able to add randomness to the flow of traffic, thus mimicking how people actually drive. Once the trips are created, they are saved so it is essentially a one-and-done process. During the last week or so I have been able to get all the marker tape on the guidelines, and get all the magnets into the roads and get all the parking barriers back up again. Yesterday morning I started to expand all my trip testing beyond the area seen in last weeks video. So far it is working pretty good. Programming each trip to test takes about 15 seconds, with the primitive graphic simulation so it isn't that difficult of a task either. I was hoping to take of the USB cable this weekend as there is very little interaction I have with the Zoomie anymore. Once I do that, testing gets easier as I won't need to make sure the cable doesn't snag on something. As Steve Woodgate mentioned regarding the QR sensor, perhaps for ZoomTown version 2, this could be yet a follow on experiment. There are different algorithms that all accomplish the same result (get from A to B) but they do it differently. You also indicated that there is a means of adding "weight" to one road over another, that would be interesting to see as well. We could be having a lot more fun with this well beyond the original experiment :-) Cheers! Chris
@@MakingStuffwithChrisDeHut do you still have the code for your Dijkstra's adaptation? I guess you used the knot-to-knot distance to have it calculate the best route? Then please try increasing these values for the inner-city-ways drastically (say multiply by 100 or so ... we pretend these road segments to be longer than they really are so they get a lot more unattractive for Dijkstra). In that case these roads will only be used if *no other possibilty* is found (e.g. if you want to reach a parking lot in the city you have to go to the city, it's not possible without) ...
@@tomek3633 Darn it, I hit the wrong button and just deleted my response... You described the routine in a way that I had not heard (seen) before and I just realized the power of this routine. I am really tired right now after working in a very hot customer shop today (100 degrees F). I will respond with a email message tomorrow morning. This is spawning a whole new idea that will be AWESOME - I think. Cheers! Chris
Hi Chris, always happy to help if required. The way you are going is good. 😊
Good morning Peter!
Thanks for the offer of help. Depending on how this next couple of weeks go, will help me decide how much help I need.
With all the development, debugging, and changes happening right now, it is very hard to see what is around the corner. At present, I am still fighting what are problems with localisation that are seemingly impossible to fix - it is like playing the "whack-a-mole" game.
Thanks very much for offering a helping hand and I will keep you posted.
Cheers
Chris
More very impressive progress. ATB 😊
Thank you! Cheers!
I have an MQTT broker running on an RPi 2. I just checked it with htop and it's been running for 535 days without a reboot. I tend to forget it's there.
Good morning William,
I am the same as you, I had one running and completely forgot about it for over a year. It was just sitting there running on my desk that I used to film at. It certainly is nice when something just runs without needing attention!
Cheers!
Chris
Hey Chris ... so you are going to programm each and every route by hand??? But that's what Dijkstra's Algorithm (also known as A-Star or A* Algorithm) is for. You just need to setup the roads and "costs" once and thats it. It can calculate ANY route in zoomtown - no need to program all of them by hand. Another benefit: if you "close down" a road for maintenance reason, all handmade routes will fail but the algorithm still works and finds the 2nd best route (avoiding the closed down road of the best route).
I am pretty sure there are ready-to-use versions of Dijkstra's for python.
the setup will need
1. all the "knots" (=points where you have several possible ways to go). a knot would be each parking lot and each crossing
2. for each knot it needs the "neighbours" = other knots that could be reached from the current knot. note: knot a could lead to knot b but knot b NOT to knot a -> one-way-road
3. for each neighbour it needs the "cost" of travelling. this is usually the distance between the two knots multiplied with a factor (which could be < 1 for the roads AROUND the city and > 1 for those THROUGH the city ... or all have factor 1 the use the shortest way regardless where it goes along)
So the workload for setup is not too big (especially since zoomtown is very symmetric). For sure less work and more flexible than hard-coding all routes :)
If I counted correctly, zoomtown has 52 knots and each knots leads to 1-3 other knots, most of them with same cost as many others due to the symmetry.
Good morning Tomek!
I actually had written the software originally to use Dijkstra's algorithm and only decided to not use it recently.
These algorithms all work on the principle of "Shortest Path" which is great for shipping, and even for navigation for non-commercial vehicles. However, even navigation systems have options to choose from Shortest Path or No Highways, or Use Highways.
The reason I decided against using it was specifically "Shortest Path" as that would direct ALL traffic through the "city center" creating a LOT more traffic in that area.
ZoomTown was designed with the outer bypass "highway" to alleviate congestion in the center areas. To make the traffic flow more "natural" I decided against those routines in hopes that a human "most likely me" will be able to add randomness to the flow of traffic, thus mimicking how people actually drive.
Once the trips are created, they are saved so it is essentially a one-and-done process.
During the last week or so I have been able to get all the marker tape on the guidelines, and get all the magnets into the roads and get all the parking barriers back up again. Yesterday morning I started to expand all my trip testing beyond the area seen in last weeks video. So far it is working pretty good. Programming each trip to test takes about 15 seconds, with the primitive graphic simulation so it isn't that difficult of a task either.
I was hoping to take of the USB cable this weekend as there is very little interaction I have with the Zoomie anymore. Once I do that, testing gets easier as I won't need to make sure the cable doesn't snag on something.
As Steve Woodgate mentioned regarding the QR sensor, perhaps for ZoomTown version 2, this could be yet a follow on experiment. There are different algorithms that all accomplish the same result (get from A to B) but they do it differently. You also indicated that there is a means of adding "weight" to one road over another, that would be interesting to see as well. We could be having a lot more fun with this well beyond the original experiment :-)
Cheers!
Chris
@@MakingStuffwithChrisDeHut do you still have the code for your Dijkstra's adaptation? I guess you used the knot-to-knot distance to have it calculate the best route? Then please try increasing these values for the inner-city-ways drastically (say multiply by 100 or so ... we pretend these road segments to be longer than they really are so they get a lot more unattractive for Dijkstra). In that case these roads will only be used if *no other possibilty* is found (e.g. if you want to reach a parking lot in the city you have to go to the city, it's not possible without) ...
@@tomek3633 Darn it, I hit the wrong button and just deleted my response...
You described the routine in a way that I had not heard (seen) before and I just realized the power of this routine. I am really tired right now after working in a very hot customer shop today (100 degrees F). I will respond with a email message tomorrow morning. This is spawning a whole new idea that will be AWESOME - I think.
Cheers!
Chris
@@MakingStuffwithChrisDeHut always a pleasure to give a little nudge :) I am looking forward to the results!