I am new in the world of freertos, I have to do a project that consists of an automatic alcohol dispenser that measures temperature. The parts/sensors of my project are:
DHT22 for temperature (I know its not ideal but its the only one
that I have).
Hc-sr04 for distance measurement (ultrasound).
I2c display 16x2 to show the temperature.
Buzzer to make sound.
Servo to dispense alcohol.
The idea of the project is that when someone comes within 15 cm of the device, the temperature is displayed on the screen, the servo moves and can dispense alcohol, and the buzzer makes a little sound.
As I understand it, I have to create a task for each activity. One to measure temperature and possibly send that information to a queue, another to read the queue and display it on the screen, another to make the sound with the buzzer, another to measure distance with the ultrasound, and another to move the servo.
This is how I was asked to do it, but my question is what is the best way to organize the tasks?
How do I make it so that ...
first the distance is measured,
then the temperature is measured,
then it is shown on the display,
the servo is moved and the sound is made?
What is the best way to communicate between tasks (when a task measures less than 15 cm, tell another task to measure temperature, and then it is shown on the display, and the servo moves and makes the sound)?
I would like to see how you think about it and it would help me a lot to know.
I’m very new to the subject and I’m having a hard time thinking which is the best way. I would appreciate simple solutions that not involve complicated stuff as I'm having a hard time with freeRTOS.
This seems like a fairly simple system, as all work can be done sequentially (i.e. one thing happens after another). You certainly don't need to use dedicated tasks for activities which are done sequentially. In fact, the simplest architecture by far is to have a single task, running in a loop, doing everything. I strongly suggest you start with that approach and build something that works.
Then after you have something that works sequentially in a single task, re-consider your options. It might be the perfect architecture, it might need minor adjustments. You'll be in a much better position to judge.
Related
i'm developing a 2d game , rts game, is sort of like COC (Clash of Clans). cool mobile game,huh. but i run into some problem with path-finding, as usual,i do path-finding algorithm once every agent was placed somewhere in screen by finger-touch,but in some case, this incur performance penalty, and your mobile phone will be very hot as your agents increase suddenly and simultaneously.
actually,no matter what path-finding i use,e.g a*,dijkstra, or something special(maybe optimal),which is always time-comsuming process throughout the whole game loop ,especially massive agents on less powerfull mobile cpu. as far as i know, some game like this, shortest path is not the focus (will people care about the path agent walk through intentionally?) instead of efficient and naturally path-finding. so my mind come up with some solutions,maybe impractical.
solution 1 : use some cheaper path-finding algorithm, could be graph related or somethingelse because shortest path doesn't matter.
solution 2 : put some limits on ai module to process agent for path-finding, e.g upper limit to path-finding algorithm calls at interval,that is,just one or two agents of the those agents got planning, let rest of them plann after several game frames. as you know ,its drawback is obvious.
the above is what i thougt. hope your game dev disciplined guys give me brilliant idea , tricks, i'll appricate. thank you very much.
EDIT:
here is my related pseudo code,and procedure cresspond to my game logic.
//inside logic thread
procedure putonagent
if (need to put agent on world space)
//do standard a* path-finding for an agent
path_list=do_aStar_path_finding(attacktargetpos,startpos);
and then enqueue path_list;
......
end
the path_list's queue finally used by visual agents for stepping forward. any hints?
Look up "Hierarchical pathfinding" Say you're driving to a city far away, you don't plan the entire path before you get in the car!
Pathfinding is usually done in steps, like it's not one function call, after N iterations it'll return (and indicate it's not complete) so it can be run at the next available time. Basically rather than a function with locals think operator() and state variables as members of a class.
To make it fast you can make the heuristic crap with A* pathfinding, suppose I use a heuristic of 10* the distance-as-the-crow-flies, it may not find the shortest path but it will have a strong preference for heading towards the target rather than "fanning out" and exploring further around the closed region.
There is a crossing sensor at point A for a bicycle. When the bicycle passes point A(the sensor senses the object and then does not), a light turns on for 20 seconds. If the bicycle goes in reverse now and passes through point A again nothing must happen.(Again the sensor only senses something and then it doesn't once the car passes.)
The difficult part of this is that the sensor changes from true to false very quickly because the bicycle moves away. If the bicycle stayed on the sensor; it would be easier. Another difficulty is the way back because it also doesn't stay.
Any propositions? I would appreciate any help. Note My skills in labview are quite mediocre. Though I would like to learn more.
Using two sensors at Point A, one in front of the other, would give you the bicycle direction which would allow you to determine when the bicycle is in reverse. This assumes that the sensors have a read response fast enough to distinguish between the front and back sensor.
I'm not sure it's possible.
The only solution I can think of would require that the reverse and forward speeds of the bicylce are different.
If their speeds are different you can try making a determination based on how long the sensor is activated.
However, you run into the problem where all bicyclists may not pass the sensor at the same speed.
The best solution would be to use two sensors and check what order they are activated in.
I need to build the AI for an opponent in an arcade style fighting game, very similar to Mortal Kombat.
I don't want to use random moves for the computer, but I would like to have an AI that is harder to beat.
Where can I start looking for resources ? Do you know of any implementation of this sort of project ?
Think about how you play the game.
Ask yourself, under what conditions would I perform certain attacks? When would I block? What do I do when I have low health? When my opponent has low health? Do I become more agressive in one situation over the other? When is it best to use long range versus short range?
Etc.
An AI like this usually only follows a bunch of if/else/then statements, with som randomness added in.
You want it to react quickly so much of anything else (A*, alpha-beta, etc) won't be as useful.
There is an algorithm which depends on statistic and count of shoots in each direction. You can put such logic to calculate how many times enemy kicked you in needed direction and predict future attacks.
I'm starting on my first commercial sized application, and I often find myself making a design, but stopping myself from coding and implementing it, because it seems like a huge use of resources. This is especially true when it's on a piece that is peripheral (for example an enable for the output taps of a shift register). It gets even worse when I think about how large the generic implementation can get (4k bits for the taps example). The cleanest implementation would have these, but in my head it adds a great amount of overhead.
Is there any kind of rule I can use to make a quick decision on whether a design option is worth coding and evaluation? In general I worry less about the number of flip-flops, and more when it comes to width of signals. This may just be coming from a CS background where all application boundarys should be as small as possibly feasable to prevent overhead.
Point 1. We learn by playing, so play! Try a couple of things. See what the tools do. Get a feel for the problem. You won't get past this is you don't try something. Often the problems aren't where you think they're going to be.
Point 2. You need to get some context for these decisions. How big is adding an enable to a shift register compared to the capacity of the FPGA / your design?
Point 3. There's two major types of 'resource' to consider :- Cells and Time.
Cells is relatively easy in broad terms. How many flops? How much logic in identifiable blocks (e.g. in an ALU: multipliers, adders, etc)? Often this is defined by the design you're trying to do. You can't build an ALU without registers, a multiplier, an adder, etc.
Time is more subtle, and is invariably traded off against cells. You'll be trying to hit some performance target and recognising the structures that will make that hard are where to experience from point 1 comes in.
Things to look out for include:
A single net driving a large number of things. Large fan-outs cause a heavy load on a single driver which slows it down. The tool will then have to use cells to buffer that signal. Classic time vs cells trade off.
Deep clumps of logic between register stages. Again the tool will have to spend more cells to make logic meet timing if it's close to the edge. Simple logic is fast and small. Sometimes introducing a pipeline stage can decrease the size of a design is it makes the logic either side far easier.
Don't worry so much about large buses, if each bit is low fanout and you've budgeted for the registers. Large buses are often inherent in fast designs because you need high bandwidth. It can be easier to go wide than to go to a higher clock speed. On the other hand, think about the control logic for a wide bus, because it's likely to have a large fan-out.
Different tools and target devices have different characteristics, so you have to play and learn the rules for your set-up. There's always a size vs speed (and these days 'vs power') compromise. You need to understand what moves you along that curve in each direction. That comes with experience.
Is there any kind of rule I can use to make a quick decision on whether a design option is worth coding and evaluation?
Only rule I can come up with is 'Have I got time? or not?'
If I have, I'll explore. If not I better just make something work.
Ahhh, the life of doing design to a deadline!
It's something that comes with experience. Here's some pointers:
adding numbers is fairly cheap
choosing between them (multiplexing) gets big quite quickly if you have a lot of inputs to the multiplexer (the width of each input is a secondary issue also).
Multiplications are free if you have spare multipliers in your chip, they suddenly become expensive when you run out of hard DSP blocks.
memory is also cheap, until you run out. For example, your 4Kbit shift register easily fits within a single Xilinx block RAM, which is fine if you have one to spare. If not it'll take a large number of LUTs (depending on the device - an older Spartan 3 can fit 17 bits into a LUT (including the in-CLB register), so will require ~235 LUTS). And not all LUTs can be shift registers. If you are only worried about the enable for the register, don't. Unless you are pushing the performance of the device, routing that sort of signal to a few hundred LUTs is unlikely to cause major timing issues.
Tried doing a bit of research on the following with no luck. Thought I'd ask here in case someone has come across it before.
I help a volunteer-run radio station with their technology needs. One of the main things that have come up is they would like to schedule their advertising programmatically.
There are a lot of neat and complex rule engines out there for advertising, but all we need is something pretty simple (along with any experience that's worth thinking about).
I would like to write something in SQL if possible to deal with these entities. Ideally if someone has written something like this for other advertising mediums (web, etc.,) it would be really helpful.
Entities:
Ads (consisting of a category, # of plays per day, start date, end date or permanent play)
Ad Category (Restaurant, Health, Food store, etc.)
To over-simplify the problem, this will be a elegant sql statement. Getting there... :)
I would like to be able to generate a playlist per day using the above two entities where:
No two ads in the same category are played within x number of ads of each other.
(nice to have) high promotion ads can be pushed
At this time, there are no "ad slots" to fill. There is no "time of day" considerations.
We queue up the ads for the day and go through them between songs/shows, etc. We know how many per hour we have to fill, etc.
Any thoughts/ideas/links/examples? I'm going to keep on looking and hopefully come across something instead of learning it the long way.
Very interesting question, SMO. Right now it looks like a constraint programming problem because you aren't looking for an optimal solution, just one that satisfies all the constraints you have specified. In response to those who wanted to close the question, I'd say they need to check out constraint programming a bit. It's far closer to stackoverflow that any operations research sites.
Look into constraint programming and scheduling - I'll bet you'll find an analogous problem toot sweet !
Keep us posted on your progress, please.
Ignoring the T-SQL request for the moment since that's unlikely to be the best language to write this in ...
One of my favorites approaches to tough 'layout' problems like this is Simulated Annealing. It's a good approach because you don't need to think HOW to solve the actual problem: all you define is a measure of how good the current layout is (a score if you will) and then you allow random changes that either increase or decrease that score. Over many iterations you gradually reduce the probability of moving to a worse score. This 'simulated annealing' approach reduces the probability of getting stuck in a local minimum.
So in your case the scoring function for a given layout might be based on the distance to the next advert in the same category and the distance to another advert of the same series. If you later have time of day considerations you can easily add them to the score function.
Initially you allocate the adverts sequentially, evenly or randomly within their time window (doesn't really matter which). Now you pick two slots and consider what happens to the score when you switch the contents of those two slots. If either advert moves out of its allowed range you can reject the change immediately. If both are still in range, does it move you to a better overall score? Initially you take changes randomly even if they make it worse but over time you reduce the probability of that happening so that by the end you are moving monotonically towards a better score.
Easy to implement, easy to add new 'rules' that affect score, can easily adjust run-time to accept a 'good enough' answer, ...
Another approach would be to use a genetic algorithm, see this similar question: Best Fit Scheduling Algorithm this is likely harder to program but will probably converge more quickly on a good answer.