InqSpeedRacer - HotWheels Speed Trap and Finish Line
Posted: Tue Mar 22, 2022 12:14 pmInqSpeedRacer is a web-based electronic speed-trap for HotWheels®. The project was created for an 8th Grade Science class studying Physics of Motion topics.
The full InqSpeedRacer server and client source code is available as an Example in the InqPortal library available as of version 5.2.2. A full write up is available at https://InqOnThat.com/Inq-Speed-Racer/ however, I need to flesh it out with a Fritzing wiring schematic and maybe need to add Usage Instructions.
The Highlights
The hardware is simple (Total outlay about $4 per InqSpeedRacer server.
The server-side software uses InqPortal so the developer doesn't have to mess with any WiFi, WebServer logic. They only have to focus on the job at hand - A speed trap. Website write-up is more for someone who wants to build them, but doesn't really need to understand the development details. This forum is different... you all want to know why.
The client side has two Apps (web pages) and the JavaScript coding is actually longer than the server-side coding at 105 and 240 lines respectively. The first page simply reports a running tally of all the speeds of cars going through. It shows the actual speed and the scale speed. It also does a little Physics and estimates the original height of the dropped car using K.E. = P.E.
The second page is technically more interesting from a developers standpoint and in a Home Automation standpoint. InqPortal has the ability to write a client that can talk to multiple InqPortal servers. The servers do not have to be the same project. The advantage in Home Automation is simple... you can have a single dashboard that hooks up to all of your various devices and retrieves and controls all from one client... AND since it is browser based, it runs on Windows, Android, Apple and Linux. In this example we set it up to connect to several InqSpeedRacer servers to act as a finish... like a Pinewood Derby. The code is a little more complex, not because of the multi-server access, but because the client has to normalized all the server clocks so that it can compare times when cars cross the individual servers "finish lines".
The full InqSpeedRacer server and client source code is available as an Example in the InqPortal library available as of version 5.2.2. A full write up is available at https://InqOnThat.com/Inq-Speed-Racer/ however, I need to flesh it out with a Fritzing wiring schematic and maybe need to add Usage Instructions.
The Highlights
The hardware is simple (Total outlay about $4 per InqSpeedRacer server.
- WeMos D1 Mini
- (2) Infrared Photo Diodes / Photo Transistors?
- (2) Infrared LEDs
- (3) Resistors
- Some wire
- Some plastic for the 3D printer
The server-side software uses InqPortal so the developer doesn't have to mess with any WiFi, WebServer logic. They only have to focus on the job at hand - A speed trap. Website write-up is more for someone who wants to build them, but doesn't really need to understand the development details. This forum is different... you all want to know why.
- The line count of the fully commented, fully WiFi web based server Sketch is only 140 lines.
- After a car passes and the speed is reported out to the clients, it automatically resets and is ready for the next car passing.
- Unlike the other InqPortal examples, this one actually does something in the loop() method. It takes advantage that the loop frequency when fully running is about 100kHz. I use this to check to see if the light beams are blocked for a car coming through. I originally did an Interrupt version, but the code complexity didn't really pan out to be any better. This one gives a timing resolution of 1/100,000 of a second. This is far better than the millisecond resolution we report out to the client.
- We use one of the publishing overloads to return a value from a function instead of a variable.
- We disable the automatic updating of the client, in favor of manually sending out the results immediately.
The client side has two Apps (web pages) and the JavaScript coding is actually longer than the server-side coding at 105 and 240 lines respectively. The first page simply reports a running tally of all the speeds of cars going through. It shows the actual speed and the scale speed. It also does a little Physics and estimates the original height of the dropped car using K.E. = P.E.
The second page is technically more interesting from a developers standpoint and in a Home Automation standpoint. InqPortal has the ability to write a client that can talk to multiple InqPortal servers. The servers do not have to be the same project. The advantage in Home Automation is simple... you can have a single dashboard that hooks up to all of your various devices and retrieves and controls all from one client... AND since it is browser based, it runs on Windows, Android, Apple and Linux. In this example we set it up to connect to several InqSpeedRacer servers to act as a finish... like a Pinewood Derby. The code is a little more complex, not because of the multi-server access, but because the client has to normalized all the server clocks so that it can compare times when cars cross the individual servers "finish lines".