Decision Making #2

Kernel
1

I am continuing our discussion about remote-controlled toy car project

Main goal is to understand how many tasks needs to creates and which tool required mutex or semaphore or message queue for resources sharing

Please let me know if you need more specific Details.

I have put together a set of hypothetical requirements for a remote-controlled toy car:

  1. Video Data Transmission (High Priority):
  • The car collects and processes data from the front and rear video cameras for real-time position tracking and obstacle avoidance. The collected video data is transmitted to a remote control unit for real-time monitoring and control.
  • Priority: High priority due to its direct impact on real-time user experience and control.
  • Deadline: Video data transmission should have minimal latency to ensure real-time control. It is not acceptable if there is a delay of more than 100 milliseconds, as this would impact the user’s ability to control the car effectively.
  1. Receive Command and Control Car (High Priority):
  • The car collects input from the remote control, translates it into motor control actions, and ensures the car can move left, right, forward, and backward based on the commands received. It also responds accurately to the commands received from the remote control. This task also includes controlling front and rear LED lights for improved visibility and activating a horn for audio alerts.
  • Priority: High priority as it directly relates to user control and functionality.
  • Deadline for Received Command Acceptance and Action: The car must accept received commands from the remote control unit within a maximum time of 50 milliseconds from the moment they are received. Furthermore, the car should respond to accepted commands with actions (movement, lighting control, horn activation) within a maximum time of 100 milliseconds. Quick response times are crucial to ensure a seamless and responsive user experience. If a command is not received within 50 milliseconds or is corrupted, it should not be accepted for action.
  1. Battery Monitoring (Medium Priority):
  • The car continuously monitors the battery to prevent abrupt shutdowns.
  • Priority: Medium priority as it ensures reliable operation but may not directly impact user experience.
  • Deadline: The monitoring of the battery should be continuous and in real-time, ensuring that battery status is checked at intervals no longer than every 5 minutes. Delays in battery monitoring beyond 5 minutes are not acceptable.
  1. Server Transmission (Lower Priority):
  • The car sends data on distance, time, temperature, and humidity to a remote server for analysis and storage.
  • Priority: Lower priority as it’s important for data analysis but not as time-sensitive as real-time control and monitoring.
  • Deadline: Data should be transmitted to the server within a reasonable time frame, aiming for an average delay of no more than 2 minutes for the data to reach the server for analysis. This timeframe ensures that data is available for analysis without significant delays

@richard-damon @ActoryOu

2

Hi there MTech,

my recommendation for you would be to do some development yourself and work your way from trivial towards full-blown via trial-and-error, although it is certainly a good idea to look into architectural aspects in parallel.

A lot of your questions and unclarities will answer themselves while you experiment. Others have provided very useful and competent suggestions (which is typical for this forum), but in my experience it is impossible to implement a system completly top-down without understanding the dirt under your feet, so a number of decisions you may make now will prove impractical under develpment and require revisions. All of that contributes to your experience which is the most important asset you need.

Best of luck!

3 Likes
3

Sorry for the delay in responding, but things have gotten a bit busier for me.

My first impression, and part of the reason this moved to a lower priority for me, is that this is a purely hypothetical project with no plans to actually move forward, and as such, possible that you don’t actually have a subject matter understanding of the details needed in such a project.

Part of this comes from the unrealistic number you have assigned to allowable delay times. Maybe you haven’t had to deal with control systems like you are describing but to have 100 milliseconds of delay in the video you are sending and another 100 milliseconds delay in the response to commands will make your remote-controlled toy car virtually undrivable except at a crawl speed. One fact to think about, why do top gamers want 120 Hz displays, because it can make a difference to the game vs a 60 Hz display, the difference between 8 ms and 16 ms is noticeable to them. While you may not be pushing quite that level of performance, you 100 ms is over a factor of 10 above that.

Now, if the vehicle was autonomous, and the controller was just goal setting, such delays might be tolerable.

The biggest issue with how this question is being framed is that you seem to be looking at what implementation details are going to be needed, but it is unclear if you know how to actually move to implementation of your top-level operations.

In one sense, none of your high-level tasks actually have much need to interact. There is an implied resource, that probably deserves a more explicit mention, of the radio system that is sending the video and monitoring data, and receiving commands. And this is the only thing that seems to interact with any of your other operations. Everything else, at the high level, is independent.

My suggestion is that if you want to learn how to implement something, you choose a something that you are able to implement. IF you do want to try to think about implementing this car, your next step is to think of the hardware needed to actually perform the actions you are talking about.

1 Like
4

Thanks to comeback @richard-damon

Thank you both for your feedback. Both of your suggestions recommend that I should try a practical approach to learning.

I have a few LEDs, Push Buttons, and a Fire sensor. I think I can use them to understand the FreeRTOS API better. But I don’t have any idea how to use them to learn other things

Do you think these components can also helpful to grasp the concept of the resources needed, such as mutex, semaphore, and message queue?

5

You can build a sample project that uses the APIs with those items. It may be harder to come up with an example that NEEDS a careful analysis of priorities. You can create dummy tasks that just “burn” a period of time in some sort of pattern, to play with how they interact.

1 Like
6

I want to share an interesting idea with you.

What are your thoughts on creating a traffic light system with pedestrian crosswalks using a few LEDs and push buttons to simulate the logical behavior of the system I think It could be a fun and educational project!

7

Yes, that could be an interesting project. It is not going to have a lot of “real-time” requirements but it is an interesting problem in design.

8

sure, why not? A lot of us started from a blinky app, of which the suggested project sort of is a logical continuation. Including visuals makes sense, of course, because a lot of embedded stuff takes place “in the dark dungeons of the system, where the light of GUI never shines” (not my wording), so including some kind of perceivable output helps flattening the learning curve.

It is important that you yourself can relate to the project, so if you think that is fun, go for it!

9

It seem complex to design such a system, but I’m presenting a simplified version to start with. No doubt others may have different approaches.

Take a look at the table, which allows only two directions to go at a time for both vehicles and pedestrians.

IMG-20231026-WA0001
IMG-20231026-WA0001771×327 61.8 KB

Any feedback would be appreciated

10

First, your table has East-West going Red → Yellow → Green → Red which isn’t the correct state.

Also, the pedestrian “Ending Walk” period, tends to be much longer than the Automobile “Yellow” period, because it takes people longer to cross. The symbol also isn’t a “Yellow” symbol but a flashing red “Don’t Walk” (either words or the hand).

Your chart will end up with 6 lines (+ 1 if add the all stop line you did here), and the flashing red for the Pedestrians will add a twist to the code to handle.

1 Like
11

The traffic light system has an ‘initialization’ state, which represents the first system state after power on. In this state, the traffic lights for both North-South and East-West directions are ‘Red,’ and the pedestrian signals for both directions show ‘Don’t Walk (Red).’ This initialization state sets the starting point for the system’s operation.

Each traffic should have three RED, GREEN and Yellow for vehicle.

What should be table state for East-west direction according to you ?

12

My first thought would be something like:

Duration. NS VehicleEW VehicleNS PedEW PED
-- (init). Red Red Red. Red
20 Seconds Green Red Green. Red
7 Seconds. Green Red Flashing Red Red
3 Seconds Yellow Red Flashing Red Red
20 Seconds Red Green Red. Green
7 Seconds. Red Green Red Flashing Red
3 Seconds Red Yellow Red Flashing Red
20 Seconds Green Red Green. Red
7 Seconds. Green Red Flashing Red Red
3 Seconds Yellow Red Flashing Red Red
20 Seconds Red Green Red. Green
7 Seconds. Red Green Red Flashing Red
3 Seconds Red Yellow Red Flashing Red
...

Each Vehicle should be in a cycle of Red → Green → Yellow → Red with one side Red when the other is Green or Yellow

Pedestrian is similar but uses Flashing Red for Yellow, and that phase is longer

The EW pattern is just the same as NS, but delayed to be just out of phase.

1 Like
13

Big thanks for you to come up with table

Could you please clarify if the statement ‘The EW pattern is just the same as NS, but delayed to be just out of phase’ refers to the timing of vehicle signals, pedestrian signals, or both?

Why is there only one column for the pedestrian signal in the North-South (NS) direction in the provided table? Is there a specific reason for not having separate columns for both NS and EW pedestrian signals, or is this table intended to represent the behavior of the NS pedestrian signal only?

14

The “phase shift” of EW to NS is that the EW values are the same as the NS lines, just 30 seconds later (3 lines).

Do you not see 5 columns? Period, NS Vehicle, EW Vehicle, NS Ped, EW PED

15

Apologies for the oversight. I couldn’t see the last column on my Android mobile, but when I switched to desktop mode, I am able to view all the columns.

16

Alright, what should be our next step? Are we ready to proceed with the coding step, or do we still need to work on project task design, priorities, and resources selection?

17

This might be a good simple step to program. The simplest program would be a single task handling all the lights.

18

If I were to implement this in a bare metal style, I would set up a 1 ms timer interrupt and create a state machine. I have experience with this approach and can manage the traffic light states effectively.

I have no idea how this would be implemented in an freeRTOS (Real-Time Operating System) style using a single task

19

You can use vTaskDelay (or vTaskDelayUntil to make the current task delay for the specified period (specified in ticks).

Building a state machine would be a good step towards generalizing the program later.

20

Thank you for clarifying! So one task is enough for current requirement of traffic light system

I was actually hoping for a project that involves multiple tasks and challenges us to consider resource-sharing options like mutex, semaphore, and queues. That’s reason I decided " Traffic light system"

Do you any suggestions on, What could be the specific conditions in traffic lights or related scenarios that would necessitate multiple tasks and raise questions about resource sharing?