[Dr_C]

Time to start the design of the anticollision algorithms.

The first version of anti-collision firmware will have the following core parameters:

L1=distance from sensor1 to sensor2

L2=distance from sensor2 to the mid-point of the lane changer zone.

Delta_L = distance from the start of the lane change mechanism to the above mid-point plus any ‘safety’ margin)

V_max = the maximum speed of travel of a vehicle for which lane changing is permitted. This is to avoid overspeed de-slots.

T_hold = actuation/hold time for solenoids

That’s five parameters.

Assuming cars don’t change speed the rest is simple maths … I hope :)

In addition to accurate measurement of speed, the pre-decision sensors (i.e. sensor1) may also provide an early signal to straighten the flipper so long as there are no cars already registered as traversing the lane changer zone. This will help avoid the risk of deslots as per the scenario described of the previous post.

So the above provide the basis for next steps in implementing version 1 of my collision avoidance endeavour.

This experimentation builds on new and fully functioning lane changer firmware which accurately reads ID and LC button status requiring only 2 ID pulse matches to do so. A standard Scalextric lane changer appears to need a minimum of 4 matching pulses. So the new firmware already has performance advantages (e.g. readability at higher vehicle speeds).

c

[Dr_C]

Since the experimentation here is wider than anti-collision, I should also mention that the new lane changer firmware is ‘36ID-ready’. Standard Scalextric firmware was reported elsewhere (a couple of years back) to be compatible with 14 unique IDs. The new firmware extends this compatibility to 36 unique IDs. Hopefully this extended compatibility can be carried through to anti-collision too.

c

[Dr_C]

The experimental lane changers are proving a lot of fun. I now have all four sensors functioning correctly (two per lane - let’s call them SensorA and SensorB). Also I have live serial comms running from the ATtiny3224 via an opto-isolator onto my PC for analysis of vehicles transiting XLC lane changers.

The initial algorithm will use my ‘so called’ A-B-C-D-E-F approach. The letters correspond to:


A = read SensorA
B = read SensorB
C = Calculations
D = Decision time i.e. the point in time when the flipper is to be actuated
E = Entry time - i.e. entering the collision zone
F = Finish time - i.e. exiting the collision zone

So the approach here is that when the vehicle transits SensorA the onboard 24bit clock records the time to 4microsecond accuracy. The same happens at SensorB. LC button status is also determined.

Calculations are then carried out to determine three future points in time, first the latest time for actuating the lane change flipper, second the time when this vehicle enters the zone where collisions may occur and finally the time when the vehicle finishes travelling through this zone. Vehicle speed will also be calculated.

When vehicles are travelling in both lanes the decision on whether to allow a vehicle to change lanes will be determined by whether one car can exit the collision zone before the other car enters the same collision zone. It all comes down to comparing the above calculated time values for the two cars.

That’s the (simple) theory… next to put it to the test. And the serial link will display all the above calculations.

So a nice little project!

c

[Dr_C]

PIC 16F630 launched 2003
ATtiny3224 launched 2021

[Dates based on technical manual release dates]

Question is, what extra lane changer features can the newer tech unlock? and, even more important, what would users most like to see added?

Happy to take responses in public or by private message. Advanced anticollision will for sure be part of the mix.

c

[woodcote]

Very late to the game, we had two of RikoRocket's collision-avoidance XLC-Pros (first developed nearly ten years ago as a collective effort on Slot Forum) in our layout for Saturday's WHO/digital Tin-Top event...

   

The first modified XLC was placed at the end of the longest straight (directly below the driver on left of the picture) and the second at the end of the following straight. They eliminated entirely the couple to maybe half a dozen end-of-straight collisions we'd normally expect in a day's racing. So we will continue with these in future layouts - and maybe add more.

However, I'm not sure we'll get all our XLCs done - the jeopardy of overtaking within technical sections of the track is something that has become part of our digital racing and drivers' skill set. And it's probably more 'realistic' - that is, if digital racing is about simulating real motorsport. Getting nerfed at the end of a 20 foot straight and put on the floor is another matter!

Keeping that realism in mind - and encouraging driver skill and keeping some jeopardy - I'm not keen on some of the neat technical solutions for problems that don't really exist. Like an automatic 'racing line' change - surely the driver already has that choice in their hands? There's also an argument over modifications to eliminate tailgating - where the tailgater is normally forced into the same lane change as the car in front... The standard XLC set-up teaches the driver not to tailgate, which is a good thing rather than a deficiency. True, it's not realistic, but... 

I agree that these features might help less-experienced digital racers in the short-term, I don't think the modifications help them become better drivers in the longer-term. I guess there's a time and a place to use them.

In terms of lane-changing features, one other thing does interest me - and that's a sorting system in a two-lane pit lane. i.e. the first car to enter goes left, the second car goes right, third car left etc etc. Yes, drivers should have this in their skill set - and a pit-lane marshal can sort the cars if necessary - but it would be a neat upgrade for our WHO/digital racing, especially our Wednesday evenings aimed at beginners. Having said that, actively choosing the empty lane to splash-and-dash can be a skill that wins a race - and I wouldn't want to lose that entirely.

[Dr_C]

Very interesting Andy thanks for sharing.

So perhaps anti-collision is more useful for either less experienced drivers or where there are multiple pacer cars in play?

This reassures me in one key aspect - that it it would be useful to have some built in reconfigurability e.g the option to switch anti-collision on or off.

Regarding the pit lane feature you mention, is this a standard ‘pit entry lane changer’ which ignores LC commands and which simply toggles in alternate directions as each car approaches?

Yes the collaborative solution to anti-collision developed about 10 years back looks great and is highly praised by users. Part of my motivation for returning to this subject is to extend features and additionally to extend compatibility with higher numbers of cars on track - perhaps a full F1 start grid.

c

[woodcote]

On-off would be good. But how about ‘sometimes’? That would both be realistic (driver error happens) and ramp up the beginners’ learning-curve - “be careful, it might happen”. Some randomness would also make pace cars a lot of fun!

The pit ‘splitter’ probably needs to be fitted into a pit lane entry rather than XLC. The tracks may be huge, but our pit lanes aren’t. I’m guessing the same chip works for both XLC and pit entry.

Yes, always exciting to think of ‘more than six cars’. At the club, we chose to stay with SSD after seriously flirting with the idea of oXigen. What we have suits our racing and also our racers, for whom a full-price Scalextric car + C8515 chip is a major outlay and anything more would have been a deal-breaker. We’ve created formats so our 18-24 racers are always involved, but sometimes I feel 8 or 9 cars on track at once would be ideal for some formats on our 120-foot layouts.

[Dr_C]

Hi Andy,

I totally respect your point around price-point for new members. I am looking at a potential option where six SSD cars can run alongside additional cars. The extra cars would use a slightly different in-car decoder (similarly priced) and used together with an inexpensive SSD-compatible transponder (known as a smart IR LED). The extra cars would be controlled by ARC throttles so again relatively inexpensive and perhaps something that could be borrowed at club level. I, too, am very interested in getting as many racers onboard as possible at minimum personal financial outlay.

Happy to chat through details in early 2024.

Clive